CVE-2026-97689

What it actually does

Vulnerable urllib3 versions (1.10.3 through before 2.8.0) parse HTTP chunked transfer encoding without bounding the chunk-size line. HTTPResponse.read_chunked and HTTPResponse.stream buffer that field until a newline or EOF, so a remote peer that sends Transfer-Encoding: chunked plus an arbitrarily long unterminated chunk-size line can force unbounded heap growth in the client process until memory is exhausted and the process is killed or becomes unresponsive. Confidentiality and integrity of data are not affected; availability of the Python process (and any service sharing that process) is.

Why it matters to the business

Any application, job, or service that uses urllib3 to fetch HTTP content can be crashed or starved of memory by a hostile or compromised origin it is configured to contact. Impact is process-level denial of service: worker restarts, failed integrations, stalled pipelines, and possible host-level pressure if many clients are hit at once. The issue was published only days ago, is not in KEV, has no known in-the-wild exploitation, and has a low, flat EPSS (~0.0029). Urgency is still real for internet-facing crawlers, webhooks, package/API clients, and Red Hat python-urllib3-main deployments until they are on the fixed package.

How an attack unfolds

The attacker does not need credentials on the client. They only need the victim process to perform an HTTP request to an endpoint they control (malicious site, poisoned redirect, compromised upstream, or attacker-in-the-middle on an untrusted network). The server answers with a chunked response whose chunk-size field never ends with a newline, causing the client parser to keep buffering. Memory grows until the interpreter is OOM-killed or the host becomes unstable. No code execution or data theft is implied. Named threat-actor use is not reported; exploit maturity is none.

How to fix it

Upgrade urllib3 to 2.8.0 or later. On Red Hat python-urllib3-main, apply RHSA-2026:69612 and install python-urllib3-main 2.8.0-1.hum1 (or newer). Rebuild or redeploy every image, virtualenv, and lockfile that pins urllib3 below 2.8.0. Until patched, avoid fetching untrusted URLs with stream() or read_chunked(), prefer known-good origins, enforce response size and time limits at the proxy or HTTP gateway, and isolate high-volume HTTP clients so an OOM cannot take down unrelated workloads. Do not rely on application-level retries alone; they can amplify memory pressure.

How to confirm the fix worked

Confirm installed urllib3 is 2.8.0 or newer (pip show urllib3, rpm/dnf for python-urllib3-main 2.8.0-1.hum1, and lockfiles such as requirements.txt, poetry.lock, Pipfile.lock, uv.lock). Scan images and SBOMs for urllib3<2.8.0. After upgrade, exercise normal streaming downloads against a benign chunked origin and confirm the process RSS stays bounded. Do not validate by sending unbounded chunk-size lines in production. Review that HTTP clients still apply timeouts and max body sizes.

Typical attack path

1. Identify a client or service that uses urllib3 1.10.3–<2.8.0 to retrieve HTTP resources.
2. Cause that client to request a URL the attacker controls (direct URL, redirect, dependency, or webhook target).
3. Return HTTP with Transfer-Encoding: chunked and a chunk-size line that is extremely long and never terminated by a newline.
4. Keep the connection open so the client continues buffering the unterminated field.
5. Wait for the client process to exhaust memory, crash, or be killed by the OOM killer, disrupting the dependent service.

How to detect it

There is no public exploit campaign or named actor to hunt. Look for already-occurred abuse as sudden Python process memory spikes and OOM kills correlated with outbound HTTP to unusual hosts, especially responses advertised as chunked. Review application and container logs around urllib3/HTTPResponse streaming, journald/dmesg OOM killer records for python or app workers, APM/RSS charts, and proxy logs showing Transfer-Encoding: chunked with abnormally large or never-completed first lines. Network captures of unterminated chunk-size data to internal clients are relevant only if retained. Absence of these artifacts does not prove non-exploitation if logging was insufficient.

• OOM killer logs naming python, gunicorn, uvicorn, celery, or other app workers shortly after outbound HTTP
• urllib3 HTTPResponse.read_chunked or HTTPResponse.stream in crash/traceback logs coincident with memory exhaustion
• HTTP response headers containing Transfer-Encoding: chunked followed by a chunk-size field with no CRLF and extreme length
• Sustained client connections to a single origin with monotonically growing Python RSS and no completed response body
• rpm/dnf evidence of python-urllib3-main older than 2.8.0-1.hum1 still running at time of crash

What your security team should do

• Patch python-urllib3-main to 2.8.0-1.hum1 via RHSA-2026:69612 and upgrade all other urllib3 pins to >=2.8.0 immediately.
• Inventory runtime, containers, CI, and serverless functions for urllib3 1.10.3–<2.8.0, including transitive dependencies.
• Prioritize internet-facing fetchers, scrapers, webhook consumers, and jobs that follow redirects to untrusted hosts.
• Enforce outbound HTTP timeouts, response size caps, and process memory limits so a single bad origin cannot OOM the host.
• Monitor Python process OOMs and urllib3-related crashes for the first weeks after disclosure even though EPSS is low and KEV is false.