CVE-2026-44432: urllib3: Decompression-bomb safeguards bypassed in parts of the streaming API
urllib3 is an HTTP client library for Python. From 2.6.0 to before 2.7.0, urllib3 could decompress the whole response instead of the requested portion (1) during the second HTTPResponse.read(amt=N) call when the response was decompressed using the official Brotli library or (2) when HTTPResponse.drain_conn() was called after the response had been read and decompressed partially (compression algorithm did not matter here). These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data) on the client side. This vulnerability is fixed in 2.7.0.
Security readout for executives and security teams
Plain-English summary
urllib3 2.6.x can ignore intended streaming limits and decompress far more data than requested. A small compressed response can expand into heavy memory and CPU use on the client, potentially causing application slowdowns or outages. The source bundle states this is fixed in urllib3 2.7.0.
Executive priority
Prioritize remediation for internet-facing automation, API clients, crawlers, and backend integrations that fetch external content. The likely business impact is availability loss from client resource exhaustion, not compromise, but the affected version range is narrow and the fix is available.
Technical view
The flaw affects urllib3 >=2.6.0 and <2.7.0. Certain HTTPResponse.read(amt=N) paths using the official Brotli library, and drain_conn() after partial decompression, may decode the full response instead of the requested portion. This is CWE-409 resource exhaustion with CVSS 4.0 score 8.9.
Likely exposure
Python applications, services, or tools that use urllib3 2.6.x to fetch untrusted or attacker-influenced HTTP responses are most exposed, especially when streaming, Brotli decompression, or connection draining is used.
Exploitation context
The bundle does not show CISA KEV listing or confirmed active exploitation. Practical abuse requires an attacker-controlled or attacker-influenced HTTP response reaching a vulnerable urllib3 client, causing client-side resource exhaustion rather than data theft or code execution.
Researcher notes
Evidence is strongest for urllib3 upstream behavior and affected range. The provided sources identify the vulnerable API conditions, Brotli-specific read case, algorithm-independent drain_conn case, CVSS 8.9, and fixed version. No exploit-in-the-wild evidence is included.
Mitigation direction
Upgrade urllib3 to 2.7.0 or later where directly managed.
Apply relevant Red Hat advisories for packaged or downstream urllib3 copies.
Identify bundled urllib3 in containers, vendor packages, and Python lockfiles.
Review vendor guidance where urllib3 is transitively supplied.
Consider limiting requests to untrusted endpoints until patched.
Validation and detection
Inventory urllib3 versions across applications, images, and dependency lockfiles.
Flag any urllib3 version >=2.6.0 and <2.7.0.
Review code paths using HTTPResponse.read(amt=N) with decompression.
Review partial-read flows that call HTTPResponse.drain_conn().
Confirm patched deployments run urllib3 2.7.0 or vendor-fixed builds.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-409: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-409 · source CWE mapping
Improper Handling of Highly Compressed Data (Data Amplification)
Improper Handling of Highly Compressed Data (Data Amplification) represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.