GHSA-pf96-p4fj-6566

Suggest an improvement
Source
https://github.com/advisories/GHSA-pf96-p4fj-6566
Import Source
https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/09/GHSA-pf96-p4fj-6566/GHSA-pf96-p4fj-6566.json
JSON Data
https://api.osv.dev/v1/vulns/GHSA-pf96-p4fj-6566
Aliases
Downstream
Published
2026-09-08T20:46:28Z
Modified
2026-09-10T12:25:28Z
Severity
  • 5.6 (Medium) CVSS_V3 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L CVSS Calculator
Summary
HTTPX2: Conflicting Content-Length and Transfer-Encoding headers can be auto-generated
Details

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:

import httpx2

request = httpx2.Request(
    "POST",
    "http://example.com/",
    headers={"Transfer-Encoding": "chunked"},
    content=b"test 123",
)

print(request.headers)

The request contains both:

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.

Database specific
{
    "cwe_ids": [
        "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T20:46:28Z",
    "nvd_published_at": "2026-09-02T18:21:29Z",
    "severity": "MODERATE"
}
References

Affected packages

PyPI / httpx2

Package

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
2.11.0

Affected versions

0.*
0.0.0
2.*
2.0.0b1
2.0.0
2.1.0
2.2.0
2.3.0
2.4.0
2.5.0
2.6.0
2.7.0
2.8.0
2.9.0
2.9.1
2.10.0

Database specific

source
"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/09/GHSA-pf96-p4fj-6566/GHSA-pf96-p4fj-6566.json"