CVE-2025-66471: 
Python vulnerability analysis and mitigation

CVE-2025-66471 is a decompression bomb (data amplification) vulnerability in urllib3's Streaming API that allows a remote attacker to trigger excessive CPU usage and memory allocation on the client side. Affecting urllib3 versions 1.0 through 2.5.x (prior to 2.6.0), the flaw was disclosed on December 5, 2025, by the urllib3 project via a GitHub Security Advisory. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.9 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-409 (Improper Handling of Highly Compressed Data / Data Amplification). When urllib3 streams a compressed HTTP response (using Content-Encoding values such as gzip, deflate, br, or zstd), its decompression logic may fully decode a small amount of highly compressed data in a single operation rather than limiting decompression to the requested chunk size. Excess decompressed data is buffered internally, but the unbounded decompression step itself can consume enormous CPU and memory resources before any limit is applied. Affected streaming methods include stream(), read(amt=N), read1(amt=N), read_chunked(amt=N), and readinto(b) on urllib3.HTTPResponse, unless decoding is explicitly disabled (GitHub Advisory, Patch Commit).

Successful exploitation causes a denial-of-service condition on any Python application or library that uses urllib3 to stream compressed HTTP responses from untrusted sources. An attacker controlling an HTTP server (or performing a man-in-the-middle position) can serve a crafted highly compressed response that, when decompressed by the vulnerable client, results in extreme CPU consumption and massive memory allocation, potentially rendering the application unresponsive or crashing the host process. There is no confidentiality or integrity impact; the vulnerability is limited to availability (GitHub Advisory).

1. Set up a malicious HTTP server: Configure a server to serve HTTP responses with a Content-Encoding header (e.g., Content-Encoding: gzip or Content-Encoding: br) and a body consisting of a highly compressed payload (a "decompression bomb") — a small compressed file that expands to gigabytes of data upon decompression.
2. Identify a vulnerable target: Find a Python application using urllib3 versions 1.0–2.5.x that streams HTTP responses from attacker-controlled or interceptable endpoints (e.g., via SSRF, open redirect, or direct network access).
3. Trigger the streaming request: Cause the target application to make an HTTP request to the malicious server using a streaming method such as response.stream(), response.read(amt=256), or response.read_chunked(amt=256) with preload_content=False.
4. Exploit decompression: urllib3 receives the compressed response and, due to the flawed decompression logic, fully decompresses the bomb in a single operation to satisfy the chunk request, consuming all available CPU and memory on the client host.
5. Achieve denial of service: The target application process becomes unresponsive or crashes due to resource exhaustion, resulting in a denial-of-service condition (GitHub Advisory).

• Process: Python processes consuming abnormally high CPU (near 100%) and rapidly growing memory usage, particularly processes making outbound HTTP requests.
• Logs: Application logs showing urllib3 streaming operations (stream(), read(), read_chunked()) against external or untrusted endpoints followed by OOM (out-of-memory) errors, process crashes, or unresponsiveness.
• Network: Inbound HTTP responses with Content-Encoding: gzip, deflate, br, or zstd headers where the compressed payload is disproportionately small relative to the declared or actual decompressed size.
• System: OS-level OOM killer events (oom_kill_process in kernel logs on Linux) or Windows application crash events associated with Python interpreter processes; sudden spikes in system memory consumption correlated with HTTP response processing.

The primary remediation is to upgrade urllib3 to version 2.6.0 or later, which fixes the decompression logic to avoid fully decoding data beyond the requested chunk size (GitHub Advisory, Patch Commit). If Brotli encoding support is used, also upgrade to Brotli ≥ 1.2.0 or brotlicffi ≥ 1.2.0.0 (enforced automatically via the urllib3[brotli] extra in patched versions). As a short-term workaround where upgrading is not immediately possible, explicitly disable response decoding in urllib3 streaming calls, or implement network-level filtering to block or limit compressed HTTP responses from untrusted sources. Numerous downstream vendors including IBM (API Connect, Cloud Pak for Automation, QRadar Suite, Netezza Appliance, watsonx Orchestrate, Instana), Red Hat, Ubuntu, and Microsoft have issued or are issuing patches for affected products (IBM Advisory, Red Hat, Ubuntu USN-7927-1).

The vulnerability was reported by researcher @Cycloctane, with supplemental information provided by @stamparm during a security audit performed by 7ASecurity and facilitated by OSTIF, indicating coordinated responsible disclosure (GitHub Advisory). Security news outlets such as SecurityOnline.info covered the flaw alongside a related urllib3 issue, noting the risk of client-side DoS via unbounded decompression. The broad downstream impact — spanning IBM enterprise products, Red Hat, Ubuntu, Microsoft Azure Linux, Oracle, and many open-source projects — generated significant patching activity across the ecosystem. Social media discussion was modest, consistent with the low EPSS score and absence of active exploitation.