CVE-2026-48743: Envoyproxy Envoy Auth Bypass Vulnerability

CVE-2026-48743 Overview

CVE-2026-48743 is an HTTP request smuggling vulnerability in Envoy, the open source edge and service proxy used in cloud-native deployments. Envoy translates a downstream HTTP/3 request that is complete at the transport layer but still declares a nonzero Content-Length into an upstream HTTP/1 request carrying unresolved body debt. When the HTTP/1 origin responds before consuming the declared body and keeps the connection reusable, the start of the next Envoy-generated request is consumed as the previous request's body. The remaining bytes are then parsed by the origin as a new HTTP/1 request, enabling route bypass and cross-stream response confusion [CWE-444].

Critical Impact
Attackers can bypass Envoy routing policies and smuggle requests to backend origins, receiving responses intended for controlled endpoints on a separate downstream HTTP/3 stream.

Affected Products

Envoy versions prior to 1.35.11
Envoy versions prior to 1.36.7 and 1.37.3
Envoy versions prior to 1.38.1

Discovery Timeline

2026-06-26 - CVE-2026-48743 published to NVD
2026-06-29 - Last updated in NVD database

Technical Details for CVE-2026-48743

Vulnerability Analysis

Envoy accepts an HTTP/3 request whose HEADERS frame carries the FIN flag, marking the stream as complete at the QUIC transport layer. If those headers include a nonzero Content-Length, Envoy treats the request as valid and forwards it upstream. The upstream translation produces an HTTP/1.1 request with the same Content-Length header but no accompanying body bytes. The HTTP/1 origin then expects additional bytes on the connection to satisfy the declared length.

When the origin replies immediately without draining the body and returns the connection to Envoy's upstream connection pool, the connection is reused for the next tenant request. Envoy writes the next request's request line and headers onto the connection, and the origin consumes those bytes as the leftover body of the previous request. The origin then parses the trailing bytes as a fresh HTTP/1 request, which was never subjected to Envoy's routing or authorization filters.

Root Cause

The root cause is inconsistent handling of message framing between HTTP/3 and HTTP/1. Envoy trusts the HTTP/3 transport-layer stream completion signal while preserving a contradictory Content-Length header during protocol downgrade. The upstream HTTP/1 codec never resolves this body debt or closes the reusable connection, leaving state that desynchronizes the proxy and the origin.

Attack Vector

An attacker sends a crafted HTTP/3 request to Envoy with FIN on the HEADERS frame and a nonzero Content-Length targeting an allowed route. Envoy denies direct access to a restricted path such as /pwn, but the smuggled request bytes reach the backend as GET /pwn HTTP/1.1. A second downstream HTTP/3 stream then receives the origin's response for the backend-parsed request. Exploitation requires an HTTP/1 upstream that answers before reading the body and continues to pool the connection.

No verified proof-of-concept code is published beyond the vendor advisory. See the Envoy GitHub Security Advisory GHSA-8phg-2h2q-jgxf for reproduction details.

Detection Methods for CVE-2026-48743

Indicators of Compromise

Backend access logs showing requests to routes that Envoy policy denies at the edge, particularly following HTTP/3 client traffic.
Mismatches between Envoy access logs and upstream origin logs for the same trace identifier or request ID.
Downstream HTTP/3 clients receiving response bodies whose content does not match the request they issued.

Detection Strategies

Correlate x-request-id and x-forwarded-for headers across Envoy and origin logs to surface requests reaching the backend without a matching Envoy record.
Inspect Envoy upstream connection reuse counters and flag origin responses returned before the declared body length is transmitted.
Deploy HTTP request smuggling test suites such as those included with h2c-smuggler or the Envoy fuzzing corpus against staging environments running vulnerable builds.

Monitoring Recommendations

Alert on HTTP/3 downstream requests carrying Content-Length greater than zero with an immediate stream FIN and no DATA frames.
Monitor upstream HTTP/1 connections in Envoy's connection pool for responses returned before the request body is fully written.
Track sudden increases in 4xx or 2xx responses on protected backend paths that should be unreachable per Envoy route configuration.

How to Mitigate CVE-2026-48743

Immediate Actions Required

Upgrade Envoy to 1.35.11, 1.36.7, 1.37.3, or 1.38.1 depending on the deployed release train.
Audit backend access logs since HTTP/3 was enabled at the edge for requests to restricted paths that lack a matching Envoy entry.
Restart or drain Envoy upstream connection pools after patching to clear any desynchronized reusable HTTP/1 connections.

Patch Information

The Envoy project fixed CVE-2026-48743 in versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1. The fix reconciles HTTP/3 stream completion with the declared Content-Length before generating the upstream HTTP/1 request, preventing body debt on reusable connections. See the Envoy GitHub Security Advisory GHSA-8phg-2h2q-jgxf for patch commits and release notes.

Workarounds

Disable HTTP/3 listeners at the Envoy edge until the patched release is deployed.
Configure upstream clusters to use HTTP/2 rather than HTTP/1.1, eliminating the connection reuse desync vector.
Force upstream connection close after each request by setting max_requests_per_connection: 1 on affected clusters.

bash

# Configuration example: force single-use upstream HTTP/1 connections
clusters:
  - name: backend_service
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    max_requests_per_connection: 1
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http_protocol_options: {}