CVE-2026-78660 in Google
Summary
by MITRE • 10/09/2026
Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability described stems from a historical design decision within the HTTP/2 implementation that prioritized framing integrity over strict header validation. In the HTTP/2 protocol specification, certain malformed headers do not disrupt the binary framing layer because they are encapsulated within HEADERS frames and processed at the application level after frame parsing is complete. Consequently, the server accepts these non-compliant headers without raising an error or rejecting the request immediately. While this approach ensures that internal HTTP/2 communication remains stable and unaffected by malformed input, it creates a significant security gap when the system operates as a reverse proxy bridging different protocol versions.
When acting as a reverse proxy, the server receives requests from clients using various protocols, including legacy HTTP/1.x connections. The flaw manifests during the translation process where the server takes an HTTP/2 request containing malformed framing-related headers and forwards it to a backend or client that expects strict adherence to HTTP/1 standards. Because the internal implementation did not sanitize or reject these malformed headers before forwarding them, they are passed through unchanged. This behavior violates the principle of least privilege in protocol handling, as the proxy assumes responsibility for ensuring compliance with the target protocol's specifications rather than merely relaying data blindly.
The operational impact is severe when this forwarded response reaches an HTTP/1 client that also lacks strict parsing logic. In such scenarios, the malformed headers can be interpreted ambiguously by the downstream parser. This ambiguity allows attackers to inject malicious content or manipulate request boundaries, leading to HTTP Response Smuggling. By carefully crafting requests with specific header anomalies, an attacker can cause discrepancies in how different layers of the network stack interpret message boundaries. For instance, one layer might treat a portion of the payload as part of the current response while another interprets it as the start of a new request or response. This desynchronization enables attacks such as cache poisoning, session hijacking, and cross-site scripting by injecting content that appears to originate from the trusted server but is actually injected via smuggled payloads.
This vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding the failure to validate input against expected formats before processing or forwarding it. Furthermore, in the context of the MITRE ATT&CK framework, this flaw facilitates techniques associated with HTTP Request Smuggling and Response Smuggling, which are categorized under Defense Evasion and Impact categories respectively. These tactics allow adversaries to bypass security controls that rely on accurate parsing of web traffic, such as Web Application Firewalls (WAFs) or load balancers, by exploiting the inconsistent interpretation of message delimiters between different protocol versions.
To mitigate this risk, it is imperative to enforce strict header validation at the reverse proxy layer regardless of the incoming protocol's framing robustness. The implementation should reject any HTTP/2 requests that contain headers violating RFC 7540 specifications before they are translated and forwarded to downstream components. Additionally, developers must ensure that outbound responses sent over HTTP/1 adhere strictly to RFC 7230 requirements, particularly regarding header field formatting and message boundary definitions. Implementing rigorous input sanitization routines that strip or reject malformed headers will prevent the propagation of ambiguous data structures. Regular security audits focusing on protocol translation logic are essential to identify similar laxities in other areas where cross-protocol communication occurs.