CVE-2025-66471

What it actually does

The flaw is a denial-of-service issue in urllib3's Streaming API handling of highly compressed HTTP response bodies. When an application streams compressed content from an untrusted or attacker-controlled endpoint, urllib3 may process decompressed data in a way that consumes excessive memory, CPU, or application resources. The impact is availability-focused: it does not indicate code execution or data disclosure, but it can cause the consuming Python process, worker, job, or service to slow down, crash, or be terminated by resource limits.

Why it matters to the business

Applications that use urllib3 to stream data from external or semi-trusted HTTP services could experience outages, failed background jobs, degraded integrations, or instability if they receive maliciously compressed responses. The current intelligence indicates low exploitation probability, no known CISA KEV listing, no ransomware association, and no known mature public exploit, so this should be prioritized as routine-to-moderate patching unless the application frequently fetches large or untrusted compressed content.

How an attack unfolds

An attacker first identifies an application workflow that uses urllib3's Streaming API to retrieve HTTP content from a location the attacker controls or can influence, such as a URL submission feature, webhook integration, package/content fetcher, feed parser, file ingestion pipeline, proxy-like service, or backend integration. The attacker hosts or injects an HTTP response with compression enabled and a payload that is small on the wire but expands dramatically when decompressed. When the vulnerable urllib3 client streams the response, the application spends excessive resources processing the compressed data. Repeated or parallel requests can amplify the effect, exhausting memory, CPU, worker pools, or job queues and causing service degradation or denial of service.

How to fix it

Upgrade urllib3 to a version that includes the upstream fix. For source-based deployments using the urllib3 Git repository, ensure the code includes commit 720f484b605f18887a48eef448d0084e2b76902d or a later trusted release containing that fix. Rebuild and redeploy any applications, containers, serverless packages, virtual environments, or vendor bundles that include urllib3. Where immediate patching is not possible, mitigate by restricting backend URL-fetching to trusted destinations, disabling automatic decompression where feasible, enforcing maximum response size and decompressed-size limits, setting strict read timeouts, limiting streaming duration, applying worker memory limits, and blocking unexpectedly compressed responses from untrusted sources.

How to confirm the fix worked

Confirm dependency resolution shows a patched urllib3 build or source tree containing commit 720f484b605f18887a48eef448d0084e2b76902d or later. Validate both direct and transitive dependency locations, including virtual environments, container images, vendored libraries, build artifacts, and packaged application bundles. Run controlled tests against compressed streaming responses to verify the application enforces response-size, timeout, and memory limits without worker crashes. In production, verify that patched services have been redeployed and that no running processes continue to load older urllib3 code.

Typical attack path

1. Find an application feature or integration that causes the backend to fetch attacker-controlled or attacker-influenced HTTP content using urllib3 streaming.
2. Prepare an HTTP server or response that advertises compression, such as gzip, deflate, or Brotli where applicable, and serves a highly compressed payload with a large decompressed size.
3. Trigger the vulnerable application to request the malicious URL or receive the malicious compressed response from an upstream source.
4. Cause urllib3's Streaming API to process the compressed stream and consume excessive memory, CPU, or worker time.
5. Repeat the request or run concurrent attempts to increase resource exhaustion and cause crashes, timeouts, queue buildup, or service unavailability.

How to detect it

Review application, proxy, egress, and runtime logs for signs that services using urllib3 fetched compressed HTTP responses shortly before crashes, timeouts, memory exhaustion, or worker restarts. Focus on workflows that accept external URLs or retrieve third-party content. Useful log sources include application request logs, outbound HTTP client logs, reverse proxy logs, egress proxy logs, container orchestrator events, process supervisor logs, kernel out-of-memory logs, APM traces, and job queue metrics. Look for repeated outbound requests to the same external host followed by high memory usage, Python MemoryError exceptions, container OOMKilled events, SIGKILL terminations, request timeouts, unusually long streaming reads, or a mismatch between small compressed transfer sizes and large application processing time. There are no known CVE-specific public exploit strings or malware artifacts associated with this issue, so detection should be behavior-based rather than signature-only.

• Content-Encoding: gzip
• Content-Encoding: deflate
• Content-Encoding: br
• MemoryError
• Killed
• OOMKilled
• Out of memory
• Cannot allocate memory
• signal 9
• SIGKILL
• urllib3.response
• urllib3.exceptions.ReadTimeoutError
• Read timed out
• ProtocolError
• IncompleteRead
• ChunkedEncodingError

What your security team should do

• Inventory applications and services that use urllib3, especially Python services that fetch, proxy, ingest, or stream HTTP content from user-supplied or third-party URLs.
• Prioritize patching internet-facing ingestion, webhook, feed-processing, proxy, crawler, file-import, and automation systems that retrieve untrusted compressed HTTP responses.
• Upgrade urllib3 to a patched version or source revision containing commit 720f484b605f18887a48eef448d0084e2b76902d, then rebuild and redeploy all affected artifacts.
• Add compensating controls for outbound HTTP fetchers: destination allowlists, maximum compressed and decompressed body sizes, strict timeouts, concurrency limits, and memory limits.
• Search logs and telemetry for unexplained memory exhaustion, worker restarts, timeout spikes, and compressed responses with very small transfer sizes but large processing impact.
• Because this is not currently in CISA KEV, has no known ransomware association, and has low EPSS, handle through normal vulnerability management unless local exposure to untrusted streaming content is high.