CVE-2026-97689: 
Python Análisis y mitigación de vulnerabilidades

CVE-2026-97689 is a Denial of Service vulnerability in the Python urllib3 HTTP client library caused by unbounded memory allocation in the chunked transfer encoding parser. The HTTPResponse.read_chunked() and HTTPResponse.stream() methods buffer the chunk-size field without a length limit, waiting for a newline or EOF, allowing a malicious HTTP server to exhaust client process memory. Affected versions span from 1.10.3 through 2.7.x (i.e., >= 1.10.3, < 2.8.0). The vulnerability was published on September 29, 2026, and carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.9 (High) (Github Advisory, Red Hat).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the streaming chunked-transfer path in response.py called readline() without a size argument, unlike the non-streaming read() path which delegates to Python's http.client module with its _MAXLINE-capped reader. When a server responds with Transfer-Encoding: chunked and then streams a very long sequence of bytes with no newline terminating the chunk-size line, urllib3 buffers the entire run in memory before it can reject the value as invalid. The fix (commit cd770b0) caps chunk-size line reads at _MAX_CHUNK_LINE_LENGTH (65,536 bytes, matching http.client._MAXLINE) and raises a ProtocolError if exceeded; testing confirmed that a 200 MiB unterminated size line previously grew RSS by ~530 MB, while the patched version stays at ~1 MB and fails fast (GitHub Commit, Github Advisory). The vulnerability also affects the requests library's streaming API, which uses urllib3 under the hood (Github Advisory).

Successful exploitation causes unbounded memory allocation in the urllib3 client process, which can exhaust available memory and crash or render the process unresponsive — a pure Denial of Service outcome with no confidentiality or integrity impact. Any application or library that streams chunked HTTP responses from untrusted servers using HTTPResponse.stream() or HTTPResponse.read_chunked() is at risk, including those using the requests library's streaming API. The scope is limited to the vulnerable client process; there is no evidence of lateral movement potential or data exposure (Github Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of publication (Github Advisory). The EPSS score is approximately 0.292% (20th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been identified. Exploitation requires the attacker to control or compromise an HTTP server that the victim client connects to, which is noted as an attack requirement (AT:P) in the CVSS v4.0 scoring (Github Advisory).

1. Set up a malicious HTTP server: The attacker operates or compromises an HTTP server that victim applications connect to — this could be via DNS hijacking, a man-in-the-middle position, a supply chain compromise, or a server the victim is explicitly configured to contact.
2. Trigger a streaming request: Wait for or induce the victim application to make an HTTP request using urllib3's streaming API (e.g., requests.get(url, stream=True) or direct use of HTTPResponse.stream() / read_chunked()).
3. Send a malicious chunked response: Respond with HTTP headers including Transfer-Encoding: chunked, followed by a very long sequence of bytes (e.g., millions of f characters) with no newline terminating the chunk-size line — for example: HTTP/1.1 200 OK\r\nTransfer-Encoding: chunked\r\n\r\n followed by ffffffff... (no \n).
4. Exhaust client memory: The vulnerable urllib3 client buffers the entire unterminated chunk-size line into memory. Sending a sufficiently large payload (e.g., hundreds of MiB) causes the client process's RSS to grow proportionally, eventually exhausting available memory and crashing or hanging the process (GitHub Commit, Github Advisory).

• Process: Sudden and sustained growth in RSS/memory usage of a Python process using urllib3 or requests, particularly during HTTP response streaming operations; process crash or OOM-kill events associated with HTTP client activity.
• Logs: Application-level errors or unhandled exceptions related to urllib3.exceptions.ProtocolError with the message "Response chunk size line exceeded maximum allowed length" (on patched versions that detect the attack); OOM killer log entries (oom-kill in /var/log/kern.log or dmesg) referencing the Python process.
• Network: Outbound HTTP connections to external servers that return responses with Transfer-Encoding: chunked headers but never complete (long-lived connections with sustained inbound data flow and no newline in the initial response body bytes); unusually large amounts of data received from a server before a connection closes or the client crashes.

The primary remediation is to upgrade urllib3 to version 2.8.0 or later, which caps chunk-size line reads at 65,536 bytes and raises a ProtocolError if exceeded (urllib3 Release). If immediate upgrading is not possible, a workaround is to avoid streaming responses from untrusted servers by using HTTPResponse.read() instead of stream() or read_chunked(), as the non-streaming path already had the length bound via Python's standard library (Github Advisory). Additionally, restricting urllib3 connections to trusted, known-good servers reduces exposure until patching is feasible.

Red Hat tracked the vulnerability as high severity in their Bugzilla system and assigned it to their Product Security DevOps Team for triage across affected Red Hat products (Red Hat Bugzilla). Microsoft also acknowledged the vulnerability in their Security Response Center update guide. The urllib3 maintainers (credited: pquentin as coordinator and illia-v as remediation reviewer) addressed the issue promptly alongside two other security fixes in the 2.8.0 release (urllib3 Release). No notable independent researcher commentary or significant social media discussion has been identified beyond standard CVE tracking and advisory aggregation.