Request Smuggling via Incorrect Upgrade Header Handling in Envoy
A request smuggling vulnerability exists in Envoy due to its incorrect handling of HTTP upgrade headers. Specifically, Envoy accepts a 200 OK response with an Upgrade header as a valid protocol switch, contrary to RFC 7230, which specifies that only a 101 Switching Protocols response should be accepted for protocol upgrades. If an attacker can trick a backend server into adding an Upgrade header to a 200 response, this can lead to request smuggling through Envoy.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation could allow an attacker to smuggle requests through Envoy, potentially bypassing security controls, interfering with other users' sessions, or executing unauthorized actions on backend services. The impact depends on the backend server's behavior and the attacker's ability to manipulate responses.
If you can’t patch tonight, do this now.
As a temporary mitigation, deploy network or application-level controls to block or sanitize unexpected Upgrade headers in 200 responses from backend servers. Monitor for anomalous HTTP responses containing Upgrade headers.
Patch, then assume compromise.
Upgrade Envoy to a version that correctly enforces RFC 7230 by only accepting 101 responses as valid protocol switches for upgrade requests. Ensure that backend servers do not add Upgrade headers to 200 responses.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
1 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.