CVE-2026-84380: HTTPX2: Conflicting Content-Length and Transfer-Encoding headers can be auto-generated
HTTPX2 is a next generation HTTP client for Python. Prior to 2.11.0, Request.prepare() in src/httpx2/httpx2/models.py can add a body-derived Content-Length header to a request that already contains a caller-supplied Transfer-Encoding header because its setdefault() processing checks each default header independently rather than treating the two framing headers as mutually exclusive. Fixed-size byte, JSON, form, and known-length multipart bodies can therefore be serialized over HTTP/1.1 with both headers, allowing request smuggling or connection desynchronization when downstream intermediaries disagree about which framing header takes precedence. This issue is fixed in version 2.11.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
httpx2to a version that resolves this vulnerability.Fixed in 2.11.0
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using HTTPX2 versions before 2.11.0 are exposed when they send HTTP/1.1 requests with a caller-supplied Transfer-Encoding header and a fixed-size body type, such as bytes, JSON, form data, or known-length multipart data.
What does an attacker need to exploit it?
Exploitation requires a request path where HTTPX2 emits both Content-Length and Transfer-Encoding and where downstream HTTP intermediaries disagree on which framing header takes precedence. The attack can lead to request smuggling or connection desynchronization.
Are default requests affected?
The conflicting headers are generated when the caller supplies Transfer-Encoding and HTTPX2 prepares a body whose length it can determine. The provided information does not indicate that ordinary requests without a caller-supplied Transfer-Encoding header receive both headers.
What should be done if upgrading is not immediately possible?
Avoid supplying a Transfer-Encoding header on requests with fixed-size byte, JSON, form, or known-length multipart bodies. This prevents the described condition in which HTTPX2 adds a body-derived Content-Length header alongside Transfer-Encoding.
How can I determine whether an application is affected?
Check whether it uses HTTPX2 before version 2.11.0 and constructs HTTP/1.1 requests that combine a caller-provided Transfer-Encoding header with a body of known length. Inspect the serialized outbound headers for requests containing both Content-Length and Transfer-Encoding.