CVE-2025-66418

What it actually does

The flaw allows an HTTP response processed by urllib3 to specify an unbounded chain of content encodings, such as repeated or deeply nested compression algorithms in the Content-Encoding header. When a client using an affected urllib3 version receives such a response, it may repeatedly decompress the body, consuming excessive CPU and allocating large amounts of memory. The result is a denial of service in the client application or service that initiated the HTTP request. The issue is not a remote code execution or data disclosure vulnerability; its primary impact is resource exhaustion triggered by a malicious or compromised HTTP server, proxy, or man-in-the-middle position.

Why it matters to the business

Applications, automation jobs, image-processing workflows, package-fetching tools, API clients, and backend services that retrieve content from external or untrusted HTTP endpoints can be crashed, slowed, or restarted by a malicious response. This can cause service degradation, failed jobs, autoscaling cost increases, alert noise, and operational instability. The CVSS score is high because exploitation can cause significant availability impact, but current public exploitation signals are low: EPSS is 0.00692, the vulnerability is not listed in CISA KEV, and exploit maturity is reported as none. Organizations with broad use of urllib3 or affected Ubuntu ImageMagick packages should still prioritize remediation because urllib3 is a widely reused HTTP client dependency and vulnerable code may be present transitively.

How an attack unfolds

An attacker first needs to influence an application into making an HTTP request to a server or endpoint the attacker controls, or to intercept/modify HTTP traffic where TLS is absent or broken. The attacker-controlled server replies with a crafted HTTP response that contains an excessive Content-Encoding chain, for example many repeated compression algorithms, along with response content designed to expand through decompression. The affected urllib3 client attempts to honor the chained encodings according to HTTP semantics but lacks a sufficient bound on the number of decompression steps. As decompression proceeds, the client process consumes high CPU and memory, potentially causing timeouts, worker exhaustion, container OOM kills, process crashes, or service restarts. Exploitation is most plausible in software that fetches arbitrary URLs, follows redirects to untrusted domains, processes user-supplied links, imports remote media, or relies on third-party APIs that could be compromised.

How to fix it

Upgrade affected components to versions that include the urllib3 fix limiting decompression-chain handling. For urllib3 source-based consumers, use a release that contains commit 720f484b605f18887a48eef448d0084e2b76902d or later. For Ubuntu packages, apply the vendor fixed packages: imagemagick on Ubuntu 20.04 LTS fixed in 8:6.9.10.23+dfsg-2.1ubuntu11.4, and imagemagick on Ubuntu 22.04 LTS fixed in 8:6.9.11.60+dfsg-1ubuntu1. Because urllib3 is often pulled in transitively, review Python dependency lockfiles, container images, virtual environments, and packaged applications rather than only direct dependencies. As compensating controls, restrict server-side URL fetching to trusted destinations, enforce allowlists for outbound fetch features, limit response sizes, set aggressive HTTP timeouts, disable automatic decompression where feasible, cap worker memory, and ensure container/process supervisors restart failed workers without causing cascading outage.

How to confirm the fix worked

Confirm dependency and package versions after patching. For Python environments, inspect installed versions with tools such as pip show urllib3, pip freeze, pipdeptree, poetry show, pip-audit, safety, or software composition analysis tooling, and verify the resolved urllib3 build contains the fix. For Ubuntu systems, verify package versions with dpkg -l imagemagick or apt-cache policy imagemagick and confirm they are at or above the fixed versions. For containers, rebuild from patched base images and rescan the final image rather than only the source repository. Functional validation can include a controlled test using a local mock HTTP server that returns an excessive Content-Encoding chain and confirming the client rejects, limits, or safely fails the response without abnormal memory growth. Also confirm outbound-fetch features have destination allowlists, response-size limits, read timeouts, and memory ceilings in place.

Typical attack path

1. Identify an application or workflow that uses affected urllib3 code and fetches attacker-influenced HTTP URLs or third-party content.
2. Cause the target application to request an attacker-controlled URL, compromised endpoint, redirect destination, or intercepted HTTP response.
3. Return an HTTP response with an unusually long or repeated Content-Encoding chain such as gzip, zstd, deflate, or br repeated many times.
4. Provide compressed response content that causes repeated decompression work and large memory allocation in the client.
5. Allow the affected client to exhaust CPU or memory, leading to slowdowns, request failures, process termination, container OOM kills, or service restarts.

How to detect it

Evidence of prior exploitation is most likely to appear as availability and resource-exhaustion artifacts rather than clear compromise indicators. Review application logs, HTTP client debug logs, outbound proxy logs, gateway logs, EDR telemetry, container orchestration events, system logs, and APM metrics for a sequence of outbound HTTP requests to unusual or user-supplied destinations followed by sharp CPU or memory growth, worker termination, OOM kills, request timeouts, or service restarts. Where response headers are logged, search for Content-Encoding headers with unusually long comma-separated chains or repeated encodings such as gzip, gzip, gzip or zstd, zstd, zstd. In Linux environments, inspect syslog, journald, dmesg, and container runtime events for OOM killer entries affecting Python, application worker, or ImageMagick-related processes. In Kubernetes or similar platforms, look for pods entering OOMKilled or CrashLoopBackOff states shortly after outbound HTTP activity. Correlate suspicious events with URLs submitted by users, webhook payloads, remote media imports, feed ingestion, document/image conversion jobs, and third-party API calls. Absence of these artifacts does not prove non-exploitation, especially if response headers and outbound HTTP metadata were not retained.

• Content-Encoding: gzip, gzip, gzip
• Content-Encoding: zstd, zstd, zstd
• Content-Encoding: deflate, deflate, deflate
• Content-Encoding: br, br, br
• Content-Encoding: gzip, zstd, gzip, zstd
• Content-Encoding: gzip, deflate, gzip, deflate
• Out of memory: Killed process
• Killed process
• MemoryError
• OOMKilled
• CrashLoopBackOff
• status=9/KILL
• urllib3
• ContentDecodingError
• DecodeError

What your security team should do

• Inventory applications, containers, CI jobs, and packaged tools that include urllib3 directly or transitively, prioritizing internet-facing services and systems that fetch user-supplied or third-party URLs.
• Patch urllib3 consumers to a release containing commit 720f484b605f18887a48eef448d0084e2b76902d or later, and apply the fixed Ubuntu ImageMagick packages where applicable.
• Prioritize remediation for services that process arbitrary URLs, webhooks, remote images, attachments, feeds, package metadata, or third-party API responses.
• Add or verify egress controls and URL-fetch allowlists so applications cannot retrieve content from arbitrary attacker-controlled hosts.
• Enforce HTTP client safeguards: maximum response size, connection/read timeouts, redirect limits, decompression limits where available, and per-process/container memory limits.
• Search recent logs for unexplained OOM kills, worker crashes, CPU saturation, and outbound HTTP requests followed immediately by process restarts or memory errors.
• Create detection logic for unusually long or repeated Content-Encoding response headers in proxy, gateway, WAF, packet-capture, or HTTP client telemetry.
• Because this is not currently KEV-listed and has low EPSS, treat it as a high-availability-impact patching item rather than an active widespread exploitation emergency unless local telemetry shows suspicious crashes.