HTTPX2 EUVD-2026-70251

Exploitation requires the HTTPX2 client to make an HTTP request to an attacker-controlled or compromised server that returns a response body encoded with gzip, deflate, brotli, or zstd (any encoding HTTPX2 decodes by default). The attacker must control the server endpoint, either by operating a malicious service, compromising a legitimate upstream, or positioning as a MITM on the network path. No authentication is required on the vulnerable client system. Applications that contact only a fixed, pre-vetted allowlist of internal servers face substantially lower exposure; applications that resolve and fetch user-supplied or third-party URLs are fully exposed under default HTTPX2 configuration. No non-default HTTPX2 setting is required to trigger the vulnerability - content decoding is enabled by default.

The CVSS 7.5 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects a trivially-reachable, unauthenticated availability attack with no confidentiality or integrity impact. EPSS data is absent from the input, and the vulnerability is not listed in CISA KEV, so active exploitation is not confirmed. The decompression-bomb technique is, however, well-documented and requires no reverse engineering - even a mid-sized municipal IT team in gdynia running HTTPX2-backed API aggregators should treat this as urgent, because any server in the client's request path (third-party APIs, user-supplied URLs, compromised upstreams) can trigger it without any cooperation from the application. The principal mitigating factor is deployment context: applications that restrict outbound HTTP to a fixed, fully-trusted allowlist of internal services face substantially reduced exposure, while those that fetch arbitrary or user-supplied URLs are fully exposed with no additional prerequisites.

An attacker who operates or has compromised an HTTP server serves a response with Content-Encoding: gzip containing a crafted decompression bomb payload (a small compressed stream that expands to gigabytes). When any HTTPX2 client prior to 2.12.0 reads the response - even in streaming mode via iter_bytes() or aiter_bytes() - each incoming chunk triggers an unbounded decompress() call, rapidly exhausting system RAM and causing the Python process to be OOM-killed. No special credentials, configuration, or user interaction are needed beyond the client issuing a normal HTTP request to the malicious server.