CVE-2026-44432

What it actually does

urllib3 versions 2.6.0 through 2.6.x before 2.7.0 can perform unbounded or unexpectedly large decompression when handling certain compressed HTTP responses. The flaw occurs when a caller uses HTTPResponse.read(amt=N) on Brotli-compressed content for a second partial read, or when HTTPResponse.drain_conn() is invoked after partially reading and decompressing a response. Instead of limiting decompression to the requested portion or safely discarding remaining content, urllib3 may decode the full compressed response in one operation. A malicious or compromised HTTP server can send a small, highly compressed response that expands to very large data, causing excessive client-side CPU consumption and memory allocation. The primary security impact is denial of service against applications, workers, agents, crawlers, integrations, or services that fetch attacker-controlled or untrusted URLs using affected urllib3 versions.

Why it matters to the business

Applications and services that use affected urllib3 versions to retrieve external or user-influenced URLs can be crashed, slowed, or made unavailable by a malicious HTTP response. This can disrupt background jobs, API integrations, web crawlers, monitoring agents, automation pipelines, or customer-facing services that depend on outbound HTTP requests. Because urllib3 is widely used across the Python ecosystem, exposure may exist indirectly through higher-level libraries and packaged applications. The CVSS availability impact is high, but the current EPSS score is low, the issue is not in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized for internet-facing, high-volume, or untrusted-URL-fetching workloads rather than treated as known active exploitation.

How an attack unfolds

An attacker positions or controls an HTTP endpoint that the vulnerable Python application will request. This may be a directly supplied URL, an upstream API, a feed, a package mirror, a webhook target, a redirect destination, or any external resource fetched by the application. The attacker returns a compressed HTTP response with a very high compression ratio, such as a small Brotli payload that expands into a large body. If the application reads the response in partial chunks using HTTPResponse.read(amt=N), the second partial read of a Brotli-compressed response can trigger full decompression rather than bounded decompression. Separately, if the application partially reads and decompresses a response and then calls drain_conn() to reuse or clean up the connection, urllib3 may decompress the remaining response in one operation regardless of compression algorithm. The result is rapid CPU exhaustion, large memory allocation, process termination by the operating system, container OOM kills, degraded throughput, or cascading service failures if worker pools are consumed. The attacker does not need authentication to the client application if they can cause it to fetch attacker-controlled content, but the attack generally requires the vulnerable client to make an outbound HTTP request to a malicious or compromised server.

How to fix it

Upgrade urllib3 to version 2.7.0 or later wherever urllib3 2.6.0 through versions before 2.7.0 are present. Because no per-package fixed versions were provided beyond the upstream fix, treat 2.7.0 as the minimum safe urllib3 release. Rebuild and redeploy applications, containers, virtual environments, serverless packages, and dependency bundles that vendor or pin urllib3. Regenerate lockfiles such as requirements.txt, requirements.lock, Pipfile.lock, poetry.lock, conda environment files, or application-specific dependency manifests if they pin an affected version. If immediate upgrade is not possible, reduce exposure by avoiding requests to untrusted URLs, disabling or limiting Brotli/content decompression where feasible, enforcing maximum response body sizes, using streaming with strict byte limits, setting conservative memory and CPU limits for workers, applying request timeouts, and isolating components that fetch external content. Mitigations should be considered temporary because application-level limits may not cover all affected urllib3 call patterns.

How to confirm the fix worked

Confirm that all deployed Python environments resolve urllib3 to version 2.7.0 or later. Use package inventory, software composition analysis, container image scanning, and runtime checks such as `python -m pip show urllib3`, `pip freeze | grep urllib3`, or equivalent tooling inside the actual deployment artifact. Check both direct and transitive dependencies, including applications that vendor urllib3 or bundle it inside zipapps, serverless layers, containers, appliances, or embedded tools. Validate that lockfiles and build outputs no longer include urllib3 versions 2.6.0 through 2.6.x. Where feasible, perform a controlled regression test against a benign highly compressed response and verify the process respects memory limits and does not allocate the full decompressed body during partial reads or connection draining. Also review application behavior to ensure maximum response-size controls, timeouts, and resource limits are active for outbound HTTP clients.

Typical attack path

1. Identify or induce a code path where a Python application using urllib3 2.6.x fetches attacker-controlled or untrusted HTTP content.
2. Serve an HTTP response with compression enabled, especially Brotli for the partial-read trigger, or another supported compression format for the drain_conn() trigger.
3. Craft the compressed response so the transferred payload is small but the decompressed output is very large.
4. Cause the client application to read only part of the response using HTTPResponse.read(amt=N) or to partially read the response and then call HTTPResponse.drain_conn().
5. Trigger urllib3 to decompress far more data than the application requested or intended to discard.
6. Consume excessive CPU and memory on the client, leading to latency, worker exhaustion, process crashes, container restarts, or denial of service.

How to detect it

This issue is a client-side denial-of-service condition, so exploitation evidence is most likely visible as abnormal resource consumption and crashes in applications that initiate outbound HTTP requests rather than as traditional server compromise artifacts. Review application logs, worker supervisor logs, container orchestration events, host telemetry, and EDR data for spikes in memory or CPU immediately after outbound HTTP requests, especially to newly observed or untrusted domains returning compressed content. Correlate OOM kills, MemoryError exceptions, process restarts, pod evictions, worker timeouts, request timeouts, and degraded job throughput with HTTP client logs showing `Content-Encoding: br`, `Content-Encoding: gzip`, `Content-Encoding: deflate`, or unusually small response transfer sizes followed by large memory allocation. Inspect reverse proxy, egress proxy, DNS, firewall, and HTTP access logs for repeated requests from affected applications to suspicious endpoints serving Brotli or highly compressed responses. If application debug logs include urllib3 messages, look for responses that were partially read, streamed, or drained before a crash. There are no known threat actors, KEV listing, ransomware use, or mature public exploit indicators in the provided data, so detection should focus on behavioral evidence of decompression-induced resource exhaustion rather than fixed attacker infrastructure.

• urllib3==2.6.0
• urllib3==2.6.1
• urllib3==2.6.2
• urllib3==2.6.3
• urllib3==2.6.4
• urllib3==2.6.5
• Content-Encoding: br
• Content-Encoding: gzip
• Content-Encoding: deflate
• MemoryError
• Killed process
• Out of memory
• OOMKilled
• pod evicted
• HTTPResponse.read
• HTTPResponse.drain_conn

What your security team should do

• Inventory Python applications, containers, automation jobs, agents, and third-party tools that include urllib3, prioritizing systems that fetch external, user-supplied, or partner-controlled URLs.
• Upgrade affected urllib3 installations from 2.6.0 through pre-2.7.0 to urllib3 2.7.0 or later, then rebuild and redeploy affected artifacts.
• Prioritize remediation for internet-facing services, URL previewers, web crawlers, feed processors, webhook processors, package/download clients, and high-concurrency worker pools.
• Search dependency lockfiles, SBOMs, container images, and runtime environments for pinned urllib3 2.6.x versions and remove stale vendored copies.
• Apply defense-in-depth controls: outbound allowlisting where practical, strict timeouts, maximum response-size limits, worker memory limits, and container/process restart safeguards.
• Monitor for abnormal client-side CPU spikes, memory growth, OOM kills, worker restarts, and repeated requests to unfamiliar compressed-content endpoints.
• Because the vulnerability is not currently in KEV and EPSS is low, schedule broad remediation through normal vulnerability management, but expedite systems with untrusted outbound-fetch behavior.