CVE-2026-21441: 
Python vulnerability analysis and mitigation

CVE-2026-21441 is a decompression bomb vulnerability in the Python urllib3 HTTP client library, classified as "Decompression-bomb safeguards bypassed when following HTTP redirects (streaming API)." It affects urllib3 versions 1.22 through 2.6.2 (i.e., >= 1.22, < 2.6.3) and was disclosed on January 7, 2026, via a GitHub Security Advisory. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.9 (High) (Github Advisory, urllib3 Advisory).

The root cause is improper handling of highly compressed data (CWE-409). When urllib3's streaming API (preload_content=False) follows HTTP redirects, the library calls drain_conn() which internally invokes self.read() — unconditionally decompressing the entire redirect response body based on the Content-Encoding header (e.g., gzip, deflate, br, zstd) before any application-level read methods are called. Critically, configured read limits do not restrict the amount of decompressed data during this drain operation, eliminating any safeguard against decompression bombs. The fix in v2.6.3 modifies drain_conn() to pass decode_content=self._has_decoded_content, ensuring decompression is skipped unless decoding was already initiated by the caller (urllib3 Advisory, Patch Commit).

Successful exploitation causes a Denial of Service (DoS) on the client application: a malicious HTTP server can send a redirect response containing a highly compressed payload (a "decompression bomb") that, when decompressed by the vulnerable urllib3 client, consumes excessive CPU and memory resources, potentially crashing or making the client application unresponsive. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Any application or library that uses urllib3 with preload_content=False and does not explicitly disable redirects when communicating with untrusted servers is at risk, including downstream products from IBM, Microsoft, Oracle, Splunk, Red Hat, and others (Github Advisory).

As of the time of this report, there is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation (Github Advisory). The EPSS score is approximately 0.014% (3rd percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. The attack requires the client to make requests to a malicious or compromised server, which represents a meaningful precondition limiting opportunistic exploitation.

1. Set up a malicious HTTP server: The attacker operates an HTTP server that, upon receiving a GET request, responds with an HTTP redirect (e.g., 301, 302, or 303) that includes a Content-Encoding: gzip header and a body containing a decompression bomb — a small, highly compressed payload that expands to gigabytes of data when decompressed.
2. Lure the target application: The attacker causes a vulnerable client application (one using urllib3 >= 1.22 and < 2.6.3 with preload_content=False and redirects enabled) to make an HTTP request to the malicious server. This could be achieved via SSRF, a malicious URL in user-supplied input, or by compromising a legitimate server the application trusts.
3. Trigger redirect handling: When urllib3 receives the redirect response, it calls drain_conn() internally to drain the connection before following the redirect. This calls self.read() without restricting decompression.
4. Exhaust client resources: The decompression bomb payload is fully decompressed in memory, consuming all available RAM and CPU on the client host, causing the application process to crash or become unresponsive (DoS) (urllib3 Advisory, Patch Commit).

• Process Behavior: Sudden spike in memory consumption and CPU usage by a Python process using urllib3, particularly when making outbound HTTP requests; process may become unresponsive or crash with an out-of-memory error.
• Network: Outbound HTTP requests from the application to an external server that responds with a redirect (3xx status code) containing a Content-Encoding header (e.g., gzip, deflate, br, zstd) and an unusually large or suspicious response body.
• Logs: Application logs showing urllib3 requests to untrusted or unexpected hosts followed by process crashes, OOM killer events in system logs (dmesg or /var/log/syslog), or Python MemoryError tracebacks.
• System: OS-level OOM (Out of Memory) events triggered by a Python process; swap space exhaustion coinciding with outbound HTTP activity.

The primary remediation is to upgrade urllib3 to version 2.6.3 or later, which fixes the issue by not decoding redirect response content when preload_content=False (urllib3 Advisory). If an immediate upgrade is not possible, set redirect=False on all urllib3 requests made to untrusted sources as a workaround. Downstream product users should apply vendor-specific patches: Splunk DB Connect (February 2026 update), IBM products (various April–June 2026 advisories), Oracle (April 2026 CPU), Red Hat (multiple RHSA advisories), Microsoft Azure Linux packages, Debian, Ubuntu, Fedora, SUSE, and AlmaLinux have all released updated packages (Splunk Advisory, Oracle Advisory). Additionally, implement network-level controls to limit HTTP response sizes from untrusted sources and monitor for unexpected high memory/CPU consumption in Python applications.

The vulnerability was reported by researcher D47A and coordinated by urllib3 maintainers illia-v, pquentin, and sethmlarson, with the fix merged promptly before the January 7, 2026 disclosure (urllib3 Advisory). The advisory received broad attention across the Linux distribution ecosystem, with Fedora, Debian, Ubuntu, SUSE, openSUSE, AlmaLinux, Oracle Linux, and Red Hat all issuing security updates within weeks of disclosure. Social media activity was noted on Mastodon/Fediverse security accounts (e.g., @LambdaWatchdog), and German security news outlet Pro-Linux published multiple coverage articles. The vulnerability's wide impact across enterprise products from IBM, Microsoft, Oracle, and Splunk drove sustained patching activity over several months.