CVE-2026-84380: HTTPX2: Conflicting Content-Length and Transfer-Encoding headers can be auto-generated
Summary
HTTPX2 can automatically add a Content-Length header to a request that already contains a caller-supplied Transfer-Encoding header. The resulting HTTP/1.1 request contains both framing headers, which can create an ambiguous message boundary and enable request smuggling or connection desynchronization when processed by intermediaries that disagree about which header takes precedence.
Details
When a request body has a known size, HTTPX2's content encoder returns a default Content-Length. Request.prepare() applies each default header with setdefault(), which only checks whether that same header is already present. It does not check whether the mutually exclusive Transfer-Encoding header is present.
For example:
python import httpx2
request = httpx2.Request( "POST", "http://example.com/", headers={"Transfer-Encoding": "chunked"}, content=b"test 123", )
print(request.headers)
The request contains both:
text Transfer-Encoding: chunked Content-Length: 8
On an HTTP/1.1 connection, the body is serialized using chunked transfer coding while both headers are sent on the wire. This violates HTTP message-framing requirements. Fixed-size byte, JSON, form, and known-length multipart bodies can reach the affected path.
Streaming bodies with an explicit Content-Length are not affected in current HTTPX2 releases because the automatically generated Transfer-Encoding is already suppressed in that direction.
Impact
An attacker may be able to use the conflicting framing headers as a request-smuggling or desynchronization primitive. Exploitation requires an application to pass attacker-controlled request framing headers and associated body data to HTTPX2, use HTTP/1.1, and communicate through a proxy or origin that accepts conflicting headers and interprets them differently from another hop.
Depending on the downstream infrastructure, successful exploitation could interfere with requests sharing a persistent connection, bypass front-end routing or authorization decisions, or poison responses or caches. Applications that do not forward attacker-controlled Transfer-Encoding headers are not directly exposed.
Mitigation
Upgrade to HTTPX2 2.11.0 or later. Patched versions treat Content-Length and Transfer-Encoding as mutually exclusive when applying automatically generated request headers.
If upgrading is not immediately possible, remove Transfer-Encoding and other hop-by-hop framing headers from untrusted input before constructing outbound requests. Applications acting as proxies should derive outbound framing from the body rather than forwarding inbound Content-Length or Transfer-Encoding headers.
Other sources
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.
— 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.11.0 - Upgrade
Upgrade
HTTPX2to a version that resolves this vulnerability.Fixed in 2.11.0 - Configuration
If upgrading is not immediately possible, remove `Transfer-Encoding` and other hop-by-hop framing headers from untrusted input before constructing outbound requests (to avoid conflicting `Content-Length` and `Transfer-Encoding`).
HTTPX2 Transfer-Encoding = remove from untrusted input before constructing outbound requests - Configuration
For applications acting as proxies, derive outbound framing from the request body rather than forwarding inbound `Content-Length` or `Transfer-Encoding` headers.
HTTP proxy applications (using HTTPX2) outbound framing header derivation = derive from body (not inbound framing headers)
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.