CVE-2026-97688 in urllib3
Summary
by MITRE • 09/29/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified within urllib3 versions ranging from 2.6.2 to 2.8.0 represents a critical resource exhaustion flaw rooted in the handling of compressed HTTP responses. Urllib3, being one of the most widely used HTTP client libraries for Python, serves as a foundational component for countless applications and services that communicate over the web. The specific defect lies within the implementation of the HTTPResponse.stream and HTTPResponse.read_chunked methods, which are responsible for processing data received in chunked transfer encoding with content compression enabled. When these functions encounter a Deflate-encoded stream, they rely on Python’s built-in zlib decompression module to decode the payload. However, under specific conditions involving trailing bytes after the end of the compressed stream, this interaction fails to terminate correctly, leading to an infinite loop that consumes system resources indefinitely.
The technical root cause is associated with how the Deflate decoder handles data at the boundary of the stream's conclusion. According to industry standards such as CWE-835, which classifies loops that consume excessive CPU or memory without making progress, this vulnerability fits squarely into that category. When an untrusted server sends a chunked response where Transfer-Encoding is set to chunked and Content-Encoding is set to deflate, the client attempts to decode the data in chunks of a specified size. If the decoded body exceeds the positive finite chunk size and the encoded stream contains trailing bytes after the actual end-of-stream marker, the zlib decoder retains these bytes as unconsumed input. Instead of recognizing that no further valid decompression can occur and raising an appropriate error or terminating gracefully, the library repeatedly attempts to decode these same trailing bytes without making any progress in consumption. This behavior creates a tight loop where CPU cycles are consumed continuously while no actual data is processed toward completion.
The operational impact of this vulnerability is severe for both client-side applications and server-side infrastructure that relies on urllib3 for outbound requests or proxy operations. The primary consequence is excessive CPU usage, which can lead to denial-of-service conditions by starving other processes of computational resources. Furthermore, the affected request fails to complete, causing application-level timeouts rather than network-level interruptions. This occurs because the infinite loop prevents any further socket reads from being initiated; since no new data is requested from the network stack during this stuck state, standard network read timeouts do not trigger to break the cycle. Consequently, connections remain open and occupied indefinitely, potentially exhausting connection pools or thread resources in high-throughput environments.
This flaw aligns with ATT&CK technique T1496, Resource Hijacking, specifically sub-technique T1496.002, which involves using computational resources for malicious purposes such as denial of service through resource exhaustion. Attackers can exploit this by crafting a specially formatted HTTP response that includes the necessary headers and payload structure to trigger the infinite loop in vulnerable urllib3 instances. The attack mechanism is straightforward: a malicious server simply needs to return a compressed chunked response with trailing bytes after the deflate stream ends, ensuring that the decoded body size exceeds the configured chunk size. This triggers the defective logic path within the library, locking up the processing thread or process until manual intervention occurs.
Mitigation for this vulnerability requires immediate upgrading of the urllib3 package to version 2.8.0 or later, where the issue has been resolved by correcting the handling of trailing bytes in the Deflate decoder integration. Organizations relying on Python-based services should audit their dependency trees and ensure that all instances of urllib3 are updated across development, staging, and production environments. Additionally, implementing network-level timeouts with aggressive settings can provide a secondary layer of defense against similar resource exhaustion attacks, although this is not a substitute for patching the underlying library flaw. Security teams should also monitor for unusual CPU spikes associated with HTTP client operations as an indicator of potential exploitation attempts targeting unpatched systems.