AI analysis
urllib3, a widely used Python HTTP client library, can enter an infinite loop in HTTPResponse.stream and HTTPResponse.read_chunked when decoding certain chunked Deflate responses. From 2.6.2 until 2.8.0, the Deflate decoder keeps trailing bytes as unconsumed input after end-of-stream and repeatedly decodes them without progress when content decoding is enabled, the response uses Transfer-Encoding: chunked and Content-Encoding: deflate, the decoded body exceeds a positive finite streaming chunk size, and the encoded body has trailing bytes. A malicious or untrusted server can trigger this so the request never finishes and consumes excessive CPU; network read timeouts do not stop the loop because no further socket read occurs. Applications and services that use those urllib3 versions to stream decoded responses from servers they do not trust are affected. The flaw is fixed in 2.8.0; it is not listed in CISA KEV and no public proof-of-concept is known.
What to do: Upgrade urllib3 to 2.8.0 or later and rebuild or redeploy any applications and containers that pin 2.6.2 through versions before 2.8.0. Until then, avoid enabling content decoding while streaming chunked responses from untrusted servers, and treat hung requests with high CPU and no further network reads as a possible hit.
Affected
| python urllib3 | 2.6.2 up to, but not including, 2.8.0 |
Estimated exposure
massOn the order of millions of Python environments may have pulled a vulnerable 2.6.x/2.7.x release; exact count unknown — urllib3 is a near-universal Python HTTP dependency (including via requests and many cloud SDKs) with very large PyPI download volume, but only the narrow 2.6.2–pre-2.8.0 range is affected, so the vulnerable subset is an estimate rather…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
urllib3 is an HTTP client library for Python. From 2.6.2 until 2.8.0, HTTPResponse.stream and HTTPResponse.read_chunked can enter an infinite loop because the Deflate decoder retains trailing bytes as unconsumed input after reaching end-of-stream and repeatedly decodes them without progress. The issue occurs when an untrusted server sends a chunked Deflate response whose decoded body exceeds a positive finite chunk size and whose encoded body has trailing bytes, specifically a response with Transfer-Encoding: chunked and Content-Encoding: deflate, content decoding enabled, and the positive finite amt=N streaming chunk size. The attack mechanism is that a malicious server returns a compressed chunked response with trailing bytes after the Deflate stream. The impact is excessive CPU usage and a request that does not complete, and network read timeouts do not interrupt the loop because no further socket read occurs. This issue is fixed in version 2.8.0.