HTTPX2 CVE-2026-84380

Exploitation requires: (1) the application uses HTTPX2 prior to version 2.11.0 as an HTTP/1.1 client; (2) application code explicitly sets a Transfer-Encoding header on a request that also carries a fixed-size body (byte literals, JSON, form data, or known-length multipart) - default HTTPX2 usage that does not manually inject this header is unaffected; (3) the request traverses at least one HTTP intermediary-reverse proxy, CDN edge, or API gateway-whose Transfer-Encoding vs. Content-Length priority resolution differs from the upstream server. HTTP/2 and HTTP/3 connections use binary framing independent of these headers and are not susceptible. Direct TCP connections to a single server without an intermediary limit the impact to single-server misparse rather than cross-user session desynchronization.

The CVSS 5.6 score with AV:N/AC:H reflects a genuine exploitation barrier: a specific type of intermediary-one that resolves the Content-Length vs. Transfer-Encoding conflict differently from the upstream server-must sit in the request path, which is not a universal condition. No EPSS data was provided and the vulnerability is absent from CISA KEV, leaving exploitation probability unquantified but active exploitation unconfirmed. The practical exposure depends heavily on topology; even a mid-sized municipal IT team in olsztyn running httpx2 as a backend service client behind a mixed-vendor proxy fleet would only be at risk when application code explicitly sets Transfer-Encoding, since default httpx2 usage never triggers the flawed code path. The vendor's S:U scope assignment in the CVSS vector may understate the cross-session impact potential that is characteristic of request-smuggling classes, where adjacent users' requests can be poisoned or read; organizations with shared proxy architectures should reassess toward S:C. The absence of any public POC reduces near-term opportunistic exploitation risk. Overall, this warrants prompt remediation in production deployments that use httpx2 behind shared proxies, but does not rise to emergency response.

An attacker targets a multi-tier Python web application that uses HTTPX2 to forward client requests to an internal upstream API through a shared reverse proxy. By crafting an HTTP request that causes the application to set Transfer-Encoding: chunked while submitting a fixed-size JSON body, HTTPX2 emits both framing headers; the reverse proxy, treating Content-Length as authoritative, misparsed the request boundary and interprets trailing bytes as the beginning of a new request from the next user in the queue. The attacker's payload is thereby injected into an adjacent session, enabling partial response hijacking or unauthorized request manipulation without any public exploit code having been observed.