CVE-2026-21441

What it actually does

This vulnerability is a client-side denial-of-service flaw in urllib3’s streaming HTTP response handling. When a streamed request receives an HTTP redirect response with a compressed body, urllib3 drains the entire response body to reuse the connection and performs decompression even though the caller has not requested the body content. Configured streaming read limits do not cap the decompressed output in this path, allowing a malicious or compromised HTTP server to return a small compressed redirect body that expands into very large data. The result can be excessive CPU consumption and large memory allocation in the client process, potentially causing application slowdowns, process crashes, worker exhaustion, or container/node resource pressure.

Why it matters to the business

Applications, automation jobs, package managers, agents, or services that use affected urllib3 streaming behavior to contact untrusted or attacker-controlled HTTP endpoints can be made unavailable or unstable. The practical impact is service degradation, failed background jobs, increased infrastructure costs from CPU and memory spikes, and potential cascading failures where many workers or clients process malicious redirects at the same time. Although this issue is not listed in CISA KEV and has no reported ransomware association, the CVSS score is high and urllib3 is widely used across Python software, so organizations should prioritize remediation in internet-facing clients, crawlers, integrations, CI/CD jobs, and systems that fetch URLs from user-controlled or third-party sources.

How an attack unfolds

An attacker positions or controls an HTTP server that a vulnerable urllib3-based client will request, either directly, through a user-supplied URL, through a compromised third-party endpoint, or through a redirect chain. The server returns an HTTP redirect response, such as a 301, 302, 303, 307, or 308, and includes a compressed response body with a high compression ratio using an encoding such as gzip, deflate, brotli, or zstd. When the vulnerable client receives the redirect while using urllib3’s streaming API, urllib3 attempts to drain the redirect response body so the connection can be reused. During that drain operation, it unnecessarily decompresses the body before application code explicitly reads it, and the normal read limits do not effectively bound the decompressed size. A decompression bomb can therefore force the client process to spend excessive CPU cycles and allocate large amounts of memory. Repeated requests or many parallel clients can turn this into a reliable denial of service against application workers, scheduled jobs, or infrastructure nodes.

How to fix it

Upgrade urllib3 and downstream packages to versions that include the upstream fix. For source-based deployments, ensure urllib3 includes commit 0248277dd7ac0239204889ca991353ad3e3a1ddc or a later release containing the fix. For Debian-tracked packages in the supplied data, apply the relevant fixed package updates: Debian 11 fixed in 5.10.127-1; Debian 12, 13, and 14 fixed in 5.18.5-1. Because urllib3 is commonly vendored or pulled transitively by other Python packages, update lockfiles, rebuild containers, refresh virtual environments, and redeploy applications rather than only updating the base OS. Where immediate upgrade is not possible, reduce exposure by avoiding streaming requests to untrusted URLs, disabling automatic redirects where feasible, rejecting redirects from untrusted hosts, enforcing strict allowlists for outbound destinations, applying network egress controls, setting conservative process/container memory limits, and blocking or limiting compressed redirect responses at proxies where practical.

How to confirm the fix worked

Confirm remediation by inventorying Python environments, containers, virtual environments, application dependencies, and vendored libraries for affected urllib3 versions or code paths. Use package manager output, software composition analysis, SBOMs, and lockfiles to verify that urllib3 has been upgraded to a fixed release or contains commit 0248277dd7ac0239204889ca991353ad3e3a1ddc or later. For Debian systems, verify the installed package versions meet or exceed the listed fixed versions for the applicable release. Functional validation can include a controlled test server that returns a redirect with a compressed body and confirming that the client does not decompress unbounded content, does not allocate excessive memory, and respects expected limits. Also verify that container images and deployed runtime artifacts were rebuilt after dependency updates, because build-time lockfiles and runtime packages can diverge.

Typical attack path

1. Identify an application, agent, job, or service that uses affected urllib3 streaming functionality to fetch HTTP or HTTPS URLs.
2. Cause the client to request an attacker-controlled or compromised endpoint, for example through user-supplied URLs, external integrations, webhooks, package metadata, crawlers, or redirectable third-party content.
3. Return an HTTP redirect response with a compressed response body and a Content-Encoding value such as gzip, deflate, br, or zstd.
4. Craft the compressed body so it is small on the wire but expands to very large decompressed output.
5. Rely on vulnerable urllib3 behavior to drain and decompress the redirect body before caller read methods are invoked and without enforcing configured decompressed read limits.
6. Repeat or parallelize requests to exhaust CPU, memory, application workers, containers, or hosts, resulting in denial of service.

How to detect it

Look for signs of resource exhaustion in processes that make outbound HTTP requests with Python libraries. Useful sources include application logs, outbound proxy logs, web gateway logs, EDR telemetry, container metrics, host metrics, Python exception traces, orchestrator events, and process accounting. Focus on time windows where Python services show sudden CPU saturation, memory growth, out-of-memory kills, container restarts, worker timeouts, or degraded job throughput. Correlate those events with outbound HTTP responses returning 301, 302, 303, 307, or 308 status codes that also include Content-Encoding headers such as gzip, deflate, br, or zstd and unusually small transferred byte counts relative to high client-side CPU or memory use. Review whether the destination host was newly contacted, user-supplied, recently changed, or part of a redirect chain. Because exploitation may not leave a unique payload artifact, detection should emphasize behavioral correlation: compressed redirect responses followed immediately by high resource consumption, Python worker crashes, OOM events, or repeated retries to the same external endpoint.

• Content-Encoding: gzip
• Content-Encoding: deflate
• Content-Encoding: br
• Content-Encoding: zstd
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308
• TooManyRedirects
• MemoryError
• Killed process
• Out of memory
• OOMKilled
• Exit Code 137
• urllib3.response
• urllib3.connectionpool
• decode_content=True

What your security team should do

• Prioritize patching applications and automation that fetch external, user-controlled, or third-party URLs using Python HTTP clients, especially crawlers, webhook processors, CI/CD tasks, package downloaders, and integration services.
• Perform software composition analysis across source repositories, lockfiles, container images, virtual environments, and vendored dependencies to locate urllib3 usage, including transitive dependencies through requests, botocore, and other Python libraries.
• Upgrade urllib3 to a fixed version or codebase containing commit 0248277dd7ac0239204889ca991353ad3e3a1ddc, then rebuild and redeploy affected applications and images.
• Apply Debian fixed package updates where applicable: Debian 11 fixed in 5.10.127-1; Debian 12, 13, and 14 fixed in 5.18.5-1.
• Temporarily disable automatic redirects, restrict outbound destinations, or enforce URL allowlists for high-risk services until upgrades are complete.
• Add monitoring for unusual CPU and memory spikes correlated with outbound HTTP requests, redirect responses, or compressed response handling.
• Review outbound proxy, EDR, application, and infrastructure telemetry for evidence of repeated compressed redirects from the same external hosts.
• Ensure workload resource limits, retry limits, and circuit breakers are configured so decompression-related failures do not cascade across worker pools.