CVE-2025-57804

What it actually does

This vulnerability is an HTTP/2 request splitting issue in the Python h2 protocol stack before version 4.3.0. The flaw stems from insufficient validation of carriage-return/line-feed characters in HTTP/2 header names or values when traffic is later translated or downgraded to HTTP/1.1 by an intermediary, gateway, reverse proxy, or application server. By embedding CRLF sequences in headers, an attacker can cause the downstream HTTP/1.1 parser to interpret part of a single HTTP/2 request as a separate request or as injected headers. The primary technical consequence is request smuggling/request boundary confusion, which can lead to bypassed routing rules, cache poisoning, authentication or authorization control bypass in certain proxy topologies, log manipulation, and desynchronization between front-end and back-end HTTP components. The CVSS vector indicates network exploitability, low complexity, no privileges, and no user interaction, but the scored direct impact is limited because exploitation depends heavily on whether an affected h2-based component performs HTTP/2-to-HTTP/1.1 translation or sits in a chain where downstream components trust the rewritten request.

Why it matters to the business

Organizations using affected h2-based services, gateways, or products that embed the vulnerable library may be exposed to request smuggling in internet-facing or internal service-to-service traffic. Successful exploitation could allow attackers to bypass access controls, reach unintended routes, poison shared caches, manipulate application logs, or interfere with other users’ requests, depending on deployment architecture. The issue is not currently listed in CISA KEV, is not reported as ransomware-used, and has low EPSS probability at the time of assessment, but it has been public for 350 days, so vulnerable long-lived services should be treated as hygiene debt and prioritized where HTTP/2 is accepted from untrusted clients or downgraded to HTTP/1.1 upstream. OpenBao deployments and other downstream products embedding vulnerable h2 behavior should be assessed because inherited dependency exposure may not be obvious from application code alone.

How an attack unfolds

An attacker first identifies a service endpoint that accepts HTTP/2 traffic and is implemented with, or depends on, a vulnerable version of the h2 library. The attacker then determines whether that service, a reverse proxy, or an upstream gateway converts HTTP/2 requests into HTTP/1.1 before forwarding them to an application or another proxy. If such translation exists, the attacker sends a crafted HTTP/2 request containing CRLF characters in a header name or value. The vulnerable component fails to reject or sanitize the illegal header content. When the request is downgraded to HTTP/1.1, the embedded CRLF sequence is interpreted by the downstream component as a header delimiter or request delimiter, causing part of the attacker-controlled data to be parsed as an additional header or a second request. The attacker can then attempt to desynchronize front-end and back-end request handling, smuggle a request to a protected path, poison a cache entry, alter routing behavior, or cause misleading log entries. Exploitation success depends on the exact HTTP component chain, whether HTTP/2 is enabled for untrusted clients, and how intermediaries normalize or reject malformed headers.

How to fix it

Upgrade the Python h2 library to version 4.3.0 or later. For source-based consumers of python-hyper/h2, ensure the code includes the fix commit 1aae569315eb170cdff00582644aca37ee38db62 or a later release containing it. For OpenBao consumers, upgrade to OpenBao 2.3.2 or later, or to a build containing version 0.0.0-20250806193356-4d9b5d3d6486 or later where applicable. Rebuild and redeploy all container images, virtual environments, serverless bundles, and vendored dependency packages that include h2. If immediate patching is not possible, mitigate by disabling HTTP/2 from untrusted clients where operationally feasible, preventing HTTP/2-to-HTTP/1.1 downgrade chains that rely on vulnerable parsing, and enforcing strict rejection of any request containing CR or LF characters in header names or values at the earliest edge layer. Configure reverse proxies, WAFs, API gateways, and load balancers to reject malformed HTTP/2 headers rather than normalize them. Because request smuggling often depends on multi-hop behavior, validate the full request path rather than only the application runtime.

How to confirm the fix worked

Confirm dependency versions in all build artifacts and running deployments. For Python environments, verify that `h2` reports version 4.3.0 or later through package metadata, lockfiles, SBOMs, container image scans, and runtime package inspection. For OpenBao, confirm the running version is 2.3.2 or later, or a fixed build containing 0.0.0-20250806193356-4d9b5d3d6486 or later as applicable. Review dependency trees for transitive inclusion of h2 in frameworks, proxies, service clients, and embedded products. Validate edge behavior by sending controlled malformed HTTP/2 requests with CRLF characters in headers in a non-production or authorized test environment and confirming they are rejected with an error rather than forwarded, normalized, or logged as multiple requests. Check that reverse proxies and application gateways consistently reject illegal HTTP/2 headers and that downstream HTTP/1.1 services do not receive attacker-controlled split headers or synthetic requests. Re-scan container images and SBOMs after redeployment to ensure older h2 versions are no longer present.

Typical attack path

1. Identify an exposed service, API gateway, reverse proxy, or embedded product that accepts HTTP/2 connections.
2. Fingerprint the stack or infer use of vulnerable h2 behavior through dependency disclosures, response behavior, or controlled malformed-header testing.
3. Confirm that traffic is translated or downgraded from HTTP/2 to HTTP/1.1 before reaching a downstream server or proxy.
4. Send crafted HTTP/2 requests containing CRLF characters in header names or values.
5. Observe whether downstream behavior indicates request splitting, header injection, request desynchronization, cache anomalies, or unexpected routing.
6. Use the smuggled request or injected header to attempt access-control bypass, cache poisoning, log manipulation, or interaction with another user’s queued request.

How to detect it

To determine whether exploitation has already occurred, review logs from every HTTP hop in the request path: CDN, WAF, load balancer, API gateway, reverse proxy, service mesh ingress, application server, and downstream HTTP/1.1 services. Look for evidence that a single client request produced multiple backend requests, malformed or rejected HTTP/2 headers, CRLF characters or their encoded forms in header values, unexpected blank lines inside logged request headers, duplicated request IDs, mismatched frontend and backend request counts, unusual 400/421/502 responses around the same source IP, and access to internal or protected paths immediately after malformed requests. Compare edge-layer logs with backend logs for desynchronization: the backend may show requests that do not have a corresponding edge request, requests with suspicious injected headers, or requests attributed to the wrong user/session. For cacheable endpoints, review cache logs for unexpected keys, poisoned responses, or cache hits following malformed requests. For OpenBao or other security-sensitive services, review audit logs for unexpected API paths, authentication context mismatches, abnormal token use after malformed requests, and denied requests followed by successful access from the same source. Because CRLF may be normalized or omitted by logging systems, also search for URL-encoded, double-encoded, escaped, and hexadecimal representations of carriage return and line feed. Absence of these indicators does not prove non-exploitation, especially if intermediaries do not log raw headers.

• %0d%0a
• %0D%0A
• %250d%250a
• %250D%250A
• \r\n
• \x0d\x0a
• \015\012
• ERROR: Invalid HTTP/2 header
• Invalid HTTP/2 header
• malformed HTTP/2 header
• Illegal header value
• Illegal header name
• CRLF
• carriage return
• line feed
• request smuggling
• request splitting
• HTTP/2 stream error
• PROTOCOL_ERROR
• RST_STREAM
• GOAWAY
• unexpected request
• upstream sent invalid header
• client sent invalid header
• invalid header while reading client request headers
• 400 Bad Request
• 421 Misdirected Request
• 502 Bad Gateway

What your security team should do

• Inventory all services, containers, packages, and products that use python-hyper/h2 or downstream products such as OpenBao.
• Prioritize remediation for internet-facing endpoints, API gateways, reverse proxies, authentication services, and any component that accepts HTTP/2 and forwards traffic as HTTP/1.1.
• Upgrade h2 to 4.3.0 or later and upgrade OpenBao to 2.3.2 or later where used.
• If patching is delayed, disable HTTP/2 on affected exposed listeners or enforce strict malformed-header rejection at the edge.
• Review WAF, gateway, load balancer, and reverse proxy configurations to ensure CRLF characters in HTTP headers are rejected, not normalized.
• Search recent access, proxy, WAF, and application logs for malformed HTTP/2 requests, encoded CRLF sequences, anomalous duplicated requests, unexpected internal route access, and cache poisoning symptoms.
• Perform authorized request-smuggling validation against representative staging paths that mirror production proxy chains.
• Update SBOMs, dependency lockfiles, and CI/CD dependency policies to block h2 versions earlier than 4.3.0.
• Add regression tests for HTTP/2 header validation and HTTP/2-to-HTTP/1.1 downgrade behavior in services that terminate or translate HTTP/2.