Skip to main content

urllib3 CVE-2026-44432

HIGH
Improper Handling of Highly Compressed Data (Data Amplification) (CWE-409)
2026-05-11 https://github.com/urllib3/urllib3 GHSA-mf9v-mfxr-j63j
8.9
CVSS 4.0 · Vendor: https://github.com/urllib3/urllib3
Share

Severity by source

Vendor (https://github.com/urllib3/urllib3) PRIMARY
8.9 HIGH
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
SUSE
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Red Hat
7.5 HIGH
qualitative

Primary rating from Vendor (https://github.com/urllib3/urllib3).

CVSS VectorVendor: https://github.com/urllib3/urllib3

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

5
Re-analysis Queued
May 13, 2026 - 16:22 vuln.today
cvss_changed
CVSS changed
May 13, 2026 - 16:22 NVD
8.9 (HIGH)
Source Code Evidence Fetched
May 11, 2026 - 15:15 vuln.today
Analysis Generated
May 11, 2026 - 15:15 vuln.today
CVE Published
May 11, 2026 - 14:51 nvd
HIGH

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 28 pypi packages depend on urllib3 (27 direct, 1 indirect)

Ecosystem-wide dependent count for version 2.6.0.

DescriptionCVE.org

Impact

urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.

urllib3 can perform decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption.

However, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases:

  1. During the second HTTPResponse.read(amt=N) call when the response was decompressed using the official Brotli library.
  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; CWE-409) on the client side.

Affected usages

Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled:

  1. A response encoded with br is read incrementally with at least two HTTPResponse.read(amt=N) or HTTPResponse.stream(amt=N) calls while using the official Brotli library.
  2. HTTPResponse.drain_conn() is called after response decompression has already started.

Remediation

Upgrade to at least urllib3 version 2.7.0 in which the library:

  1. Is more efficient for reads with Brotli.
  2. Always skips decompression for HTTPResponse.drain_conn().

If upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases:

  1. For the Brotli-specific issue only, switch from brotli to brotlicffi until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396.
  2. If your code explicitly calls HTTPResponse.drain_conn(), call HTTPResponse.close() instead when connection reuse is not important.

Credits

The Brotli-specific issue was reported by @kimkou2024. HTTPResponse.drain_conn() inefficiency was reported by @Cycloctane.

AnalysisAI

Decompression bomb safeguards in urllib3 2.6.0 can be bypassed during streaming API operations, causing excessive CPU and memory consumption on client systems. Applications using urllib3 versions 2.6.0 through 2.6.x that stream Brotli-compressed responses with multiple read() calls, or invoke drain_conn() after partial decompression, may decompress entire payloads instead of requested chunks. This allows malicious servers to trigger resource exhaustion attacks against urllib3 clients. Vendor-released patch (version 2.7.0) confirmed by GitHub advisory GHSA-mf9v-mfxr-j63j. No public exploit identified at time of analysis, but exploitation requires only a malicious HTTP server delivering compressed responses - a low-complexity attack scenario.

Technical ContextAI

urllib3 is a foundational Python HTTP client library used by requests, pip, and numerous other tools. The streaming API design reads HTTP response bodies incrementally to avoid loading large payloads into memory. Since version 2.6.0, urllib3 added incremental decompression for Content-Encoding formats (gzip, deflate, brotli, zstd), intending to decompress only the bytes requested per read operation. However, two implementation flaws bypass this safeguard: (1) a bug in the official Brotli library integration (https://github.com/google/brotli/issues/1396) causes full decompression on the second HTTPResponse.read(amt=N) call when using the brotli package, and (2) the drain_conn() method always fully decompresses remaining data regardless of compression algorithm. These behaviors violate the intended chunk-based decompression model. The root cause is CWE-409 (Improper Handling of Highly Compressed Data/Zip Bomb), where the library fails to enforce decompression limits during streaming operations, enabling classic decompression bomb attacks where tiny compressed payloads expand to gigabytes in memory.

RemediationAI

Upgrade to urllib3 version 2.7.0 or later, which implements proper incremental decompression for Brotli and skips decompression entirely in drain_conn() operations (advisory: https://github.com/urllib3/urllib3/security/advisories/GHSA-mf9v-mfxr-j63j). If immediate upgrade is blocked by dependency constraints, apply these targeted workarounds with noted limitations: (1) For the Brotli-specific bypass only, replace the brotli package with brotlicffi in your Python environment - this mitigates issue #1 but not issue #2, and may have performance differences or compatibility gaps with some brotli features. (2) If your code explicitly calls HTTPResponse.drain_conn(), refactor to use HTTPResponse.close() instead when connection reuse is not critical - this prevents the drain_conn() decompression issue but disables HTTP connection pooling, potentially degrading performance in high-throughput scenarios. (3) Disable automatic decompression by setting decode_content=False when creating HTTPResponse objects - this prevents all decompression bombs but requires application code to handle decompression manually, breaking existing logic that expects decoded content. (4) Implement application-level decompression size limits by wrapping read operations with memory threshold checks - adds overhead and complexity but provides defense-in-depth. None of these workarounds fully address both issues; upgrade to 2.7.0 remains the complete solution.

Vendor StatusVendor

SUSE

Severity: High
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 12 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-44432 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy