Description

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1, Envoy forwards data for a configured non-WebSocket HTTP upgrade before the upstream accepts the upgrade. An unauthenticated HTTP/2 client can place a complete HTTP/1.1 request in extended CONNECT data; Envoy downgrades the request, writes the data unframed to a keep-alive HTTP/1.1 upstream, and returns the socket to the shared pool while the smuggled response remains queued. A different downstream client can then receive the attacker's response. The relevant scope boundary is that webSocket upgrades, plain CONNECT, disabled backend keep-alive, per-downstream pools, and max_requests_per_connection set to 1 are not affected by the demonstrated path. This issue is fixed in versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-21T20:17:28.397Z",
  "pubdate": "2026-09-21T20:17:28.397Z",
  "executiveSummary": "Envoy is susceptible to an HTTP/2 request smuggling vulnerability resulting from improper state management during non-WebSocket HTTP upgrades.\nThe vulnerability allows an unauthenticated remote attacker to craft malicious HTTP/2 requests containing encapsulated HTTP/1.1 payloads. By exploiting the way Envoy handles data forwarding prior to upstream upgrade confirmation, an attacker can cause request desynchronization.\nThis leads to a critical security impact where data from an attacker's request is injected into the communication stream of an unsuspecting downstream client. Effectively, this allows for the cross-contamination of response data between different sessions, potentially leading to unauthorized data exposure or information disclosure.\nThe flaw affects Envoy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1. Exposure is contingent on specific configurations, notably those using keep-alive connections on HTTP/1.1 upstreams and shared connection pools. Environments utilizing per-downstream pools or restricting connections to a single request are not vulnerable. Remediation requires upgrading the Envoy binary to the specified patched versions.",
  "technicalDetails": "The root cause of this vulnerability lies in the race condition between upstream connection upgrades and the forwarding of data for non-WebSocket HTTP upgrades. When Envoy receives a non-WebSocket upgrade request via HTTP/2, it may proceed to forward data to the upstream before the upgrade process has been explicitly acknowledged or finalized by said upstream.\nThe attack vector involves an unauthenticated client initiating an HTTP/2 request that encapsulates a complete, smuggled HTTP/1.1 request within extended CONNECT data. Upon receiving this, Envoy performs an HTTP/2 to HTTP/1.1 downgrade and writes the smuggled data to a keep-alive HTTP/1.1 upstream connection. Because the upstream may not have finalized the upgrade, the state machine fails to account for the smuggled payload correctly.\nThe subsequent exploitation flow occurs as follows: Envoy completes the processing of the primary request and returns the socket to a shared upstream connection pool. Crucially, the response generated by the smuggled HTTP/1.1 request remains queued or 'in-flight' within the connection's buffer. When the shared pool assigns this 'dirty' socket to a different, legitimate downstream client, that client receives the response intended for the attacker's smuggled request. This results in the misrouting of sensitive information between disparate client sessions.\nThe vulnerability is limited to configurations where connection reuse is prevalent. Specifically, scenarios employing keep-alive HTTP/1.1 upstreams and shared connection pools are susceptible. Conversely, the vulnerability is mitigated by configurations that isolate connection state, such as setting 'max_requests_per_connection' to 1, utilizing per-downstream pools, or employing WebSocket upgrades and plain CONNECT methods, which appear to utilize different state transition logic.\nAffected versions include all releases prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1. The flaw resides in the Envoy proxy’s HTTP/2 codec and upstream connection management components. Since the attack is launched over HTTP/2, it requires no authentication or specific user privileges, as it targets the inherent behavior of the proxy's protocol handling during the upgrade lifecycle."
}