Python h2 Library CVE-2026-71554

Exploitation requires two conditions to be simultaneously present. First, the target application must use h2 version 4.4.0 or earlier as its HTTP/2 parsing layer - any deployment running h2 ≥4.4.1 is patched. Second, the application or an intermediary component must downgrade the parsed HTTP/2 request to HTTP/1.1 before forwarding it to an upstream or origin server, which is a common pattern in reverse proxies, API gateways, and load balancers. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms that no authentication and no special attacker-side configuration is required to send the crafted HTTP/2 request. The limiting factor is architectural: deployments where h2 terminates HTTP/2 without any subsequent HTTP/1.1 forwarding are not exposed to the smuggling consequence, even though the library still silently accepts the malformed header block.

The NVD CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) rates this as moderate, but the I:N assignment is worth scrutinising: request smuggling is fundamentally an integrity-class attack (cache poisoning, security control bypass, routing manipulation), and the A:L rating in the official vector is atypical for this vulnerability class. Real-world risk is highly deployment-dependent - the smuggling impact only materialises where h2 feeds into an HTTP/1.1 backend or proxy that interprets Host headers; deployments where h2 is a terminating endpoint with no downstream HTTP/1.1 forwarding are not exposed to the smuggling consequence, though the library still silently accepts the malformed input. No EPSS data was provided, so exploitation probability cannot be quantified. Not in CISA KEV and no public exploit code identified at time of analysis, suggesting no widespread weaponisation at the time of disclosure. Patch is available and straightforward to apply, making this a low-urgency-but-clear-action item for teams running h2-powered HTTP/2-to-HTTP/1.1 gateway architectures.

A remote, unauthenticated attacker sends a crafted HTTP/2 request to an h2-powered reverse proxy, embedding two Host header fields in a single HPACK header block. The h2 library accepts both and forwards them to a backend that rewrites the request as HTTP/1.1; the resulting request carries two Host lines, which the origin server or caching layer interprets inconsistently with the proxy, allowing the attacker to poison a shared cache entry or bypass a Host-based access control rule. No public exploit code has been identified at time of analysis, but the technique is well-documented in HTTP smuggling literature.