CVE-2026-71554: 
Python vulnerability analysis and mitigation

CVE-2026-71554 is an HTTP request smuggling vulnerability in h2, a pure-Python HTTP/2 protocol stack maintained by python-hyper. Versions up to and including 4.4.0 fail to reject request header blocks containing more than one Host header, forwarding all duplicate headers to the consuming application. When the consuming application downgrades the HTTP/2 request to HTTP/1.1, the resulting request carries two Host header lines — a classic request smuggling primitive (CWE-444). The vulnerability was published on August 3, 2026, and patched in version 4.4.1. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, h2 Security Advisory).

The root cause is classified as CWE-444 (Inconsistent Interpretation of HTTP Requests / HTTP Request Smuggling). In vulnerable versions, the _validate_host_authority_header() function in src/h2/utilities.py does not check for duplicate Host headers — it simply overwrites the tracked value each time a host header is encountered, allowing multiple Host headers to pass through undetected. The fix (commit 292a408) adds a check that raises a ProtocolError if a second Host header is detected on both the receive and send paths. An attacker exploits this by crafting an HTTP/2 request with two Host headers; when a middleware or proxy downgrades this to HTTP/1.1, the ambiguous dual-Host request can cause backend servers to interpret the request differently, enabling smuggling attacks. A public PoC (poc_h2_duplicate_host.py) is available on GitHub demonstrating the bypass (h2 Security Advisory, Fix Commit, PoC Repository).

Successful exploitation provides an unauthenticated network attacker with an HTTP request smuggling primitive, which can be leveraged to bypass security controls (e.g., WAFs, authentication proxies), poison shared caches, hijack user sessions, or cause backend servers to process unintended requests. The CVSS scoring reflects a low availability impact with no direct confidentiality or integrity impact in isolation; however, in real-world deployments where h2 is used as part of a proxy or gateway that downgrades HTTP/2 to HTTP/1.1, the chained impact can be significantly higher. The vulnerability is particularly relevant in multi-tier architectures where a front-end HTTP/2 server forwards requests to HTTP/1.1 backends (GitHub Advisory, h2 Security Advisory).

A public proof-of-concept Python script (poc_h2_duplicate_host.py) is available on GitHub, demonstrating how to construct HTTP/2 frames with duplicate Host headers against h2 version 4.4.0 to bypass validation (PoC Repository). As of the time of reporting, there is no evidence of active in-the-wild exploitation, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.325%, indicating a low near-term exploitation probability. No threat actor attribution has been reported (GitHub Advisory).

1. Identify target: Locate applications using the h2 Python library (versions ≤ 4.4.0) that act as HTTP/2 intermediaries and downgrade requests to HTTP/1.1 backends (e.g., proxies, API gateways built with frameworks like Hypercorn or Twisted).
2. Craft malicious HTTP/2 request: Construct an HTTP/2 HEADERS frame containing two Host header fields (e.g., Host: legitimate.example.com and Host: attacker.example.com) using a tool or the PoC script poc_h2_duplicate_host.py.
3. Send request to vulnerable h2 endpoint: Transmit the crafted HTTP/2 request to the target server. The h2 library (≤ 4.4.0) will accept both Host headers without raising a ProtocolError and forward both to the consuming application.
4. Trigger protocol downgrade: The consuming application or proxy downgrades the HTTP/2 request to HTTP/1.1, emitting a request with two Host: header lines to the backend.
5. Exploit backend divergence: The ambiguous dual-Host HTTP/1.1 request causes the backend server to interpret the request differently from the front-end, enabling request smuggling — potentially bypassing authentication, poisoning caches, or hijacking other users' requests (PoC Repository, h2 Security Advisory).

• Network: HTTP/2 requests containing multiple Host header fields in a single HEADERS frame; unusual or unexpected Host header values in backend HTTP/1.1 access logs differing from the front-end's recorded host.
• Logs: Backend server access logs showing requests with two Host: header lines; application-level errors or unexpected routing behavior in services consuming h2-processed requests; ProtocolError exceptions in h2 logs after patching (indicating attempted exploitation).
• Application Behavior: Requests being routed to unexpected virtual hosts or backend services; cache poisoning symptoms such as users receiving responses intended for other users or different hostnames.

Upgrade the h2 library to version 4.4.1 or later, which rejects duplicate Host headers with a ProtocolError on both the send and receive paths (Fix Commit, GitHub Advisory). If immediate patching is not possible, application code consuming h2 should validate incoming request headers and reject or normalize any request containing more than one Host header before processing or forwarding. The h2 advisory notes that while h2 provides best-effort sanity checks, calling code is ultimately responsible for ensuring safe HTTP/2 usage (h2 Security Advisory).

The vulnerability was reported by researcher SunandM, who also authored the fix commit and the public PoC. The advisory was published by maintainer Kriechi on August 3, 2026. The issue is noted as similar to a previously disclosed and fixed duplicate Content-Length vulnerability in h2, suggesting a pattern of header validation gaps in the library. OpenSUSE Tumbleweed has been identified as an affected downstream product, and a security announcement was issued via the OpenSUSE security mailing list (h2 Security Advisory, OpenSUSE Announcement).