CVE-2026-111066 in AIOHTTP
Summary
by MITRE • 10/19/2026
AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. From 2.0.0 until 3.14.4, multipart request processing can retain an unbounded number of open file descriptors. An unauthenticated attacker can consequently exhaust file descriptors with specially crafted multipart requests when a handler uses Request.post(). This issue is fixed in version 3.14.4.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified within the AIOHTTP library, specifically affecting versions from 2.0.0 through 3.14.4, represents a significant resource management flaw rooted in how asynchronous HTTP servers handle multipart form data submissions. As an asynchronous framework built on Python's asyncio event loop, AIOHTTP is designed to handle high-concurrency network operations efficiently. However, the implementation of its multipart request processing logic contains a critical defect where file descriptors associated with uploaded files or temporary buffers are not properly released after use. This oversight allows for the accumulation of open file descriptor handles that persist beyond their intended lifecycle within the request handling context.
From a technical perspective, the flaw manifests when an application handler utilizes the Request.post() method to process incoming multipart requests. The underlying code fails to ensure that all temporary files or streams created during the parsing and processing of these multi-part payloads are explicitly closed by the framework before the request object is discarded. In operating systems with limited file descriptor limits per process, such as Linux which typically imposes a default limit on open files for user processes, this behavior leads to a gradual but steady consumption of available descriptors. Since AIOHTTP operates asynchronously, it can accept and begin processing multiple requests concurrently without blocking threads, thereby accelerating the rate at which these unreleased resources accumulate compared to synchronous frameworks that might naturally serialize or manage thread-local resource cleanup more predictably.
The operational impact of this vulnerability is severe, primarily categorized as a Denial of Service (DoS) condition resulting from Resource Exhaustion. An unauthenticated attacker can exploit this flaw by sending specially crafted multipart requests at a sustained rate. Each request contributes to the pool of unclosed file descriptors until the operating system rejects new connections or operations due to exceeding the process's open file limit. Once this threshold is reached, the server becomes unable to accept new incoming connections or perform necessary I/O operations for legitimate traffic, effectively rendering the service unavailable. This type of attack does not require authentication credentials, making it particularly dangerous in public-facing applications that do not enforce strict access controls on endpoints accepting multipart data.
This vulnerability aligns with CWE-775: Missing Release of File Descriptor or Handle after Effective Lifetime, as the application fails to release a system resource during its lifecycle. Furthermore, from an offensive security perspective such as the MITRE ATT&CK framework, this behavior facilitates Resource Hijacking and Denial of Service via consumption of non-cached resources (T1496). The attacker leverages legitimate functionality—multipart file uploads—to degrade service availability without necessarily compromising data confidentiality or integrity initially.
Mitigation for this issue requires an immediate upgrade to AIOHTTP version 3.14.4 or later, where the developers have addressed the resource leak by ensuring proper closure of temporary files and streams associated with multipart processing. For organizations unable to patch immediately due to dependency constraints, defensive coding practices should be implemented within application handlers. Developers can manually manage file descriptors by wrapping request processing in context managers that guarantee cleanup, although this is a workaround rather than a complete fix since the underlying framework behavior remains flawed at lower levels. Additionally, implementing rate limiting on endpoints that accept multipart uploads and configuring operating system-level limits for open files per process can provide partial mitigation against rapid exhaustion attacks while longer-term remediation strategies are deployed. Monitoring file descriptor usage metrics in production environments is also recommended to detect anomalous spikes indicative of such exploitation attempts.