CVE-2024-23326: Envoyproxy Request Smuggling Vulnerability

CVE-2024-23326 Overview

CVE-2024-23326 is an HTTP request smuggling vulnerability in Envoy, the cloud-native open source edge and service proxy. Envoy incorrectly accepts a 200 OK response from an upstream server when a client requests a protocol upgrade. Per RFC 7230 Section 6.7, servers must respond with 101 Switching Protocols to confirm an upgrade. By accepting 200 as a valid upgrade confirmation, Envoy creates a theoretical request smuggling path when an upstream server can be coerced into echoing an Upgrade header into its response.

Critical Impact

Attackers may smuggle requests through Envoy, bypassing front-end security controls and reaching backend services with attacker-controlled HTTP semantics.

Affected Products

• Envoyproxy Envoy (multiple release branches prior to the fixed versions listed in the vendor advisory)
• Service meshes and API gateways embedding vulnerable Envoy builds
• Kubernetes ingress controllers based on Envoy (for example, Istio, Contour, Gloo)

Discovery Timeline

• 2024-06-04 - CVE-2024-23326 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2024-23326

Vulnerability Analysis

The flaw is an HTTP Request Smuggling defect tracked under CWE-444 (Inconsistent Interpretation of HTTP Requests) and CWE-391 (Unchecked Error Condition). Envoy treats an upstream 200 OK containing an Upgrade header as a successful protocol switch. RFC 7230 requires a 101 Switching Protocols status code for any actual upgrade. Once Envoy believes the upgrade succeeded, it stops applying HTTP/1.1 framing rules to the remainder of the connection and forwards bytes as tunneled protocol data.

If the upstream application can be tricked into reflecting attacker-controlled headers, including Upgrade and Connection, the desynchronization lets an attacker prepend a smuggled request to the next pipelined client. The smuggled request inherits the trust of the front-end proxy and may bypass authentication, WAF rules, or routing decisions enforced at the edge.

Root Cause

The root cause is missing validation of the HTTP status code paired with the Upgrade header in the upstream response path. Envoy's HTTP/1 codec should reject any non-101 response when honoring an upgrade. Instead, it accepts 200 and transitions the connection into upgrade mode, violating the state machine defined by RFC 7230.

Attack Vector

Exploitation requires a client request that includes Upgrade and Connection: upgrade headers traversing Envoy to a backend that reflects those headers into a 200 response. The attacker chains a second request after the upgrade-style request on the same front-end connection. Because Envoy now treats the connection as a tunnel, the second request body is interpreted as a fresh HTTP request by either Envoy or a downstream listener, producing the smuggling primitive.

No authenticated session, user interaction, or local access is required. The attack is fully remote over the network and depends only on a cooperating or misconfigured upstream that reflects upgrade headers.

No verified public proof-of-concept exploit is available at the time of writing. Refer to the Envoy GitHub Security Advisory GHSA-vcf8-7238-v74c for vendor analysis.

Detection Methods for CVE-2024-23326

Indicators of Compromise

• Upstream HTTP responses with status 200 that also carry Upgrade and Connection: upgrade headers.
• Access log entries where a single front-end connection shows mismatched request and response counts.
• Backend application logs containing requests whose Host, method, or path differ from what Envoy logged for the same connection.
• Sudden appearance of pipelined or chunked requests targeting internal-only routes from external clients.

Detection Strategies

• Run Envoy in debug logging and alert on the upgrade code path completing with a non-101 upstream status.
• Deploy network IDS signatures that flag HTTP responses containing both Upgrade and a 2xx status other than 101.
• Correlate Envoy access logs with upstream application logs to identify request count drift on the same client connection.
• Audit running Envoy versions across the fleet and compare against the fixed releases listed in the vendor advisory.

Monitoring Recommendations

• Forward Envoy access and connection logs to a centralized analytics platform and retain HTTP method, path, status, and upgrade headers.
• Monitor cluster.upstream_rq_* and http.downstream_rq_* statistics for anomalies in upgrade transitions.
• Alert on any reflection of client-supplied Upgrade headers in upstream responses during synthetic monitoring.

How to Mitigate CVE-2024-23326

Immediate Actions Required

• Upgrade Envoy to a patched release as listed in GHSA-vcf8-7238-v74c.
• Update derived products such as Istio, Contour, Gloo, and AWS App Mesh to versions that ship the patched Envoy build.
• Audit upstream services for header reflection bugs that could echo Upgrade into a 200 response.
• Disable HTTP upgrades on listeners where WebSocket or similar protocols are not required.

Patch Information

The Envoy maintainers released fixes in supported branches; consult the Envoy Security Advisory GHSA-vcf8-7238-v74c for the exact fixed versions corresponding to each maintained release line. Patched builds reject upstream responses that include an Upgrade header without a 101 status.

Workarounds

• Strip the Upgrade and Connection headers from client requests at the edge when upgrades are not in scope for the route.
• Configure upstream applications to never echo client-supplied headers into response headers.
• Restrict use of Envoy upgrade configuration to routes that explicitly require WebSocket or CONNECT semantics.

# Example Envoy route configuration disabling HTTP upgrades on a virtual host
route_config:
  virtual_hosts:
  - name: backend
    domains: ["*"]
    routes:
    - match: { prefix: "/" }
      route:
        cluster: backend_service
        upgrade_configs:
        - upgrade_type: "websocket"
          enabled: false