CVE-2026-84382: HTTPX2: Streaming response decompression does not bound peak memory (decompression amplification)
Summary
When decoding a compressed response body (gzip, deflate, br, or zstd), HTTPX2 fully decompressed each network read before yielding content to the application. A small compressed input could therefore cause a large intermediate memory allocation, even when the application streamed the response to keep memory usage bounded.
Details
HTTPX2's default transport reads the socket in pieces of up to 64 KiB. Before 2.12.0, each piece was inflated completely into one intermediate allocation before any decompressed bytes were yielded.
At DEFLATE's maximum compression ratio of roughly 1032:1, a 64 KiB compressed chunk can expand to about 64 MiB in one allocation. Brotli and Zstandard responses can cause similarly large amplification. Streaming the response did not prevent these transient allocations.
Impact
Applications that fetch resources from untrusted or attacker-influenced servers - such as webhook receivers, link unfurlers, crawlers, SSRF-reachable fetchers, and redirect followers - can experience memory pressure or out-of-memory termination when processing a malicious compressed response. No authentication or user interaction is required beyond issuing a request to the server.
Mitigation
Upgrade to HTTPX2 2.12.0 or later. Patched versions decompress responses incrementally with bounded intermediate buffers, including responses with multiple content encodings.
Other sources
HTTPX2 is a next generation HTTP client for Python. Prior to 2.12.0, the HTTPX2 content decoders in src/httpx2/httpx2/decoders.py fully inflate each gzip, deflate, br, or zstd network chunk before iterbytes() or aiterbytes() yields bounded pieces to the application. A 64 KiB compressed chunk can expand to approximately 64 MiB in one intermediate allocation, so an attacker-controlled or compromised server can cause severe memory pressure or out-of-memory process termination even when the application streams the response. This issue is fixed in version 2.12.0.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/httpx2to a version that resolves this vulnerability.Fixed in 2.12.0 - Upgrade
Upgrade
HTTPX2to a version that resolves this vulnerability.Fixed in 2.12.0
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using HTTPX2 before 2.12.0 are exposed when they consume compressed HTTP responses using gzip, deflate, brotli, or zstd. Streaming through iter_bytes() or aiter_bytes() does not prevent the vulnerable intermediate allocation.
What does an attacker need to exploit it?
An attacker needs to control or compromise an HTTP server that the application requests, or otherwise cause the application to retrieve an attacker-controlled compressed response. No authentication or user interaction is required.
Is a streaming response consumer protected by bounded output chunks?
No. Before 2.12.0, HTTPX2 fully inflates each compressed network chunk before yielding bounded pieces, allowing a 64 KiB compressed chunk to require approximately 64 MiB in an intermediate allocation.
How can this be remediated?
Upgrade HTTPX2 to version 2.12.0, which fixes the decompression behavior.