CVE-2025-66418: 
Python vulnerability analysis and mitigation

CVE-2025-66418 is a Denial of Service vulnerability in the Python urllib3 HTTP client library caused by an unbounded decompression chain depth. Starting in version 1.24 and prior to 2.6.0, urllib3 supports chained HTTP content encodings (per RFC 9110) but imposes no limit on the number of compression steps in the Content-Encoding header, allowing a malicious server to trigger excessive CPU usage and massive memory allocation. The vulnerability was published on December 5, 2025, and fixed in urllib3 2.6.0. 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-770 (Allocation of Resources Without Limits or Throttling). urllib3's MultiDecoder class, which handles chained HTTP content encodings, did not enforce any maximum on the number of decoders in the chain. An attacker controlling a malicious HTTP server can craft a response with a Content-Encoding header containing a virtually unlimited number of compression algorithms (e.g., gzip, deflate, br, zstd, gzip, deflate, ...), causing the client to allocate decoders and memory for each step, leading to resource exhaustion. The fix in commit 24d7b67 introduces a hard-coded limit of 5 chained encodings (max_decode_links = 5), raising a DecodeError if exceeded. Exploitation requires the client to connect to a server controlled by the attacker — a precondition classified as "Attack Requirements: Present" in CVSS v4.0 (GitHub Advisory, GitHub Commit).

Successful exploitation results in a Denial of Service against any application or library using urllib3 to make HTTP requests to untrusted servers. The attacker can cause high CPU consumption and massive memory allocation on the client system, potentially crashing the process or degrading service availability. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue affecting the vulnerable system and, depending on deployment, downstream systems that depend on it (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of this report (Feedly). The EPSS score is approximately 0.016% (0.000160), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to control or compromise an HTTP server that the victim client connects to, which limits opportunistic exploitation but remains a realistic threat in supply chain or man-in-the-middle scenarios.

1. Set up a malicious HTTP server: The attacker configures an HTTP server to respond with a crafted HTTP response containing a Content-Encoding header with more than 5 chained compression algorithms (e.g., Content-Encoding: gzip, deflate, br, zstd, gzip, deflate, gzip, deflate, ...).
2. Lure or redirect the victim client: The attacker either operates a server that the victim application connects to (e.g., a third-party API, a compromised dependency mirror, or a man-in-the-middle position), or tricks the application into connecting to the malicious server.
3. Deliver the crafted response: When the urllib3 client (version 1.24–2.5.x) receives the response, it attempts to instantiate a MultiDecoder with an unbounded number of decoders corresponding to each Content-Encoding value.
4. Trigger resource exhaustion: The client allocates memory and CPU for each decompression step. With a sufficiently large chain, this causes the process to exhaust available memory and CPU, resulting in a crash or severe performance degradation (GitHub Advisory, GitHub Commit).

• Network: Outbound HTTP/HTTPS connections from application processes to unexpected or untrusted servers; responses with unusually long Content-Encoding headers containing more than 5 comma-separated encoding values.
• Process: Sudden spike in CPU and memory usage by Python processes using urllib3; process crashes or OOM (Out of Memory) kills associated with HTTP response processing.
• Logs: Application error logs showing DecodeError: Too many content encodings in the chain (in patched versions detecting the attack); unexpected MemoryError or resource exhaustion errors in Python application logs during HTTP response handling.
• File System: No specific file artifacts expected; however, core dump files generated by crashed Python processes may indicate exploitation attempts.

The primary remediation is to upgrade urllib3 to version 2.6.0 or later, which limits the decompression chain to a maximum of 5 links (GitHub Advisory). For systems that cannot immediately upgrade, the official advisory recommends using preload_content=False and manually inspecting resp.headers["content-encoding"] to verify a safe number of encodings before reading response content. Additionally, restricting HTTP connections to trusted servers only and applying OS-level CPU and memory limits (e.g., via cgroups or ulimits) on processes using urllib3 can reduce the blast radius. Downstream products from Oracle, IBM (API Connect, Netezza Appliance, Business Automation Workflow, QRadar Suite, Instana, and others), Red Hat, Debian, Ubuntu, and Amazon Linux have also released or are releasing updated packages (Oracle CPU Jan 2026, IBM Netezza Advisory).

The vulnerability was reported by researcher illia-v and reviewed by sethmlarson and pquentin from the urllib3 maintainer team, who released the fix promptly in version 2.6.0 (GitHub Advisory). The issue received coverage from security news outlets such as SecurityOnline.info, which highlighted the client-side DoS risk from unbounded decompression and streaming resource exhaustion. Multiple Linux distributions (Debian, Ubuntu, Fedora, openSUSE, AlmaLinux, Rocky Linux) and major vendors (Oracle, IBM, Red Hat, Microsoft, Amazon Linux) have issued advisories and updated packages, reflecting broad ecosystem impact. Community discussion on platforms like Mastodon and Bluesky noted the wide deployment of urllib3 as a transitive dependency in many Python projects, amplifying the remediation urgency.