CVE-2026-97689 in urllib3
Summary
by MITRE • 09/29/2026
urllib3 is an HTTP client library for Python. From 1.10.3 until 2.8.0, the HTTPResponse.read_chunked and HTTPResponse.stream methods can allocate unbounded memory because the streaming chunk parser buffers the chunk-size field until newline or EOF without a length bound. The trigger is that a malicious server returns Transfer-Encoding: chunked followed by a very long run of bytes without a newline. The attack mechanism is that a malicious HTTP server sends a very long unterminated chunk-size line. The impact is that unbounded memory allocation can exhaust the client process. This issue is fixed in version 2.8.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified within urllib3, specifically affecting versions from 1.10.3 through 2.8.0, represents a critical resource exhaustion flaw rooted in the handling of HTTP chunked transfer encoding. Urllib3 is a widely adopted Python library for making HTTP requests, and its robustness relies heavily on correctly parsing responses from various servers. The core technical defect lies within the implementation of the read_chunked and stream methods used to process data streams where the content length is not known in advance but is instead broken into chunks with size headers. In a compliant HTTP/1.1 response using chunked encoding, each chunk begins with a hexadecimal line indicating its size, followed by the actual data bytes, and terminated by a newline character. The vulnerability arises because the parser buffers this initial chunk-size field indefinitely until it encounters either a newline or an end-of-file marker, without imposing any maximum length constraint on that buffer.
This design oversight allows for a specific attack vector where a malicious HTTP server can exploit the unbounded memory allocation behavior. By sending a response header with Transfer-Encoding: chunked followed by an extremely long sequence of bytes that does not contain a newline character until near the end or never, the attacker forces the client-side parser to continuously allocate memory to store this malformed chunk-size field. Since there is no limit on how many characters can be buffered for the size indicator, the Python process handling the request will consume increasing amounts of RAM as it reads through the malicious data stream. This behavior effectively transforms a standard network interaction into a Denial of Service scenario against the client application rather than the server.
The operational impact of this vulnerability is significant, particularly in environments where urllib3 is used to fetch content from untrusted or semi-trusted sources such as web scraping applications, API clients interacting with external services, or automated security scanning tools. An attacker who controls a malicious HTTP endpoint can trigger an Out-of-Memory condition on the victim's system. This leads to process crashes, application instability, and potential service disruption for dependent systems that rely on the affected Python application. In cloud-native environments or containerized deployments where memory limits are strictly enforced, this could result in automatic pod termination or instance restarts, causing availability issues even if the underlying infrastructure has substantial resources available.
From a classification perspective, this flaw aligns with CWE-400, which describes uncontrolled resource consumption, and more specifically CWE-789 regarding memory allocation without limits on size. In terms of adversarial tactics, this technique corresponds to ATT&CK T1499, Endpoint Denial of Service, where the attacker aims to exhaust system resources rather than compromise confidentiality or integrity directly. The lack of input validation for the length of metadata fields in network protocols is a common source of such vulnerabilities, highlighting the importance of strict parsing rules even when dealing with standard-compliant but potentially malicious inputs.
The issue was resolved in version 2.8.0 by implementing bounds checking on the chunk-size field buffer. Developers upgrading to this fixed version will find that the parser now enforces a maximum length for the metadata read during chunked decoding, thereby preventing excessive memory allocation regardless of how long an attacker attempts to make the malformed header line. For organizations still running older versions of urllib3, immediate mitigation involves updating the library dependency in all affected projects. Additionally, until an upgrade is feasible, implementing network-level controls such as rate limiting or deep packet inspection at a reverse proxy can help detect and block responses with abnormally large headers before they reach the application layer. It is also advisable to review any custom wrappers around urllib3 that might bypass standard parsing logic, ensuring that all HTTP response streams are handled by the patched library components.