CVE-2026-48743: 
Envoy vulnerability analysis and mitigation

CVE-2026-48743 is an HTTP request smuggling vulnerability in Envoy proxy affecting the HTTP/3-to-HTTP/1 translation boundary. It allows unauthenticated network attackers to bypass route-based access controls and cause upstream HTTP/1 servers to process unintended requests. Affected versions include Envoy 1.35.0–1.35.10, 1.36.0–1.36.6, 1.37.0–1.37.2, and 1.38.0. The vulnerability was published on June 26, 2026, with patches released the same period. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause (CWE-444: Inconsistent Interpretation of HTTP Requests) is a mismatch between semantic request completion and body-byte accounting at the HTTP/3-to-HTTP/1 translation boundary. When Envoy receives a downstream HTTP/3 request with a HEADERS+FIN (headers-only close) that carries a nonzero Content-Length, it marks the request as complete (end_stream=true) without reconciling the declared body length against received DATA bytes. The stale Content-Length: N is then forwarded verbatim to the HTTP/1 upstream encoder, which emits it without correction. If the upstream origin responds early and keeps the connection reusable, bytes from Envoy's next upstream request are consumed as the prior request's body, and the remaining bytes are parsed by the origin as a new, attacker-influenced HTTP/1 request. Exploitation requires: downstream HTTP/3 enabled on Envoy, an HTTP/1 upstream cluster, an origin that can send an early response before consuming the declared body, and the upstream connection remaining reusable after that response (GitHub Advisory).

Successful exploitation enables HTTP request smuggling and route/policy bypass at the HTTP/3-to-HTTP/1 translation boundary. An unauthenticated attacker can cause the backend to process requests that Envoy explicitly denied — as demonstrated in the PoC where a direct request to /pwn was blocked by Envoy (EDGE-DENY), but the backend received and responded to GET /pwn HTTP/1.1 via the smuggled second stream. This results in high integrity impact (unauthorized backend request processing) and low confidentiality impact (potential exposure of responses intended for other requests), with no direct availability impact (GitHub Advisory).

A public proof-of-concept reproduction Gist is linked from the official security advisory, containing step-by-step setup instructions, configuration files, and scripts (bash /tmp/envoy-h3h1-bodydebt/run_remote.sh) that demonstrate the smuggling attack on a real Envoy deployment. The EPSS score is approximately 0.30%, indicating relatively low but non-negligible exploitation probability. No in-the-wild exploitation or threat actor attribution has been reported at this time, and the vulnerability is not currently listed in the CISA KEV catalog. Exploitation is rated as requiring high attack complexity due to the specific upstream configuration prerequisites (GitHub Advisory).

1. Reconnaissance: Identify Envoy deployments with HTTP/3 (QUIC) enabled on the downstream listener and HTTP/1 upstream clusters, using network scanning or service fingerprinting.
2. Verify upstream behavior: Confirm that the upstream HTTP/1 origin sends early responses (before consuming the full declared request body) and keeps the connection reusable (no Connection: close).
3. Craft the first HTTP/3 request: Send an HTTP/3 HEADERS frame with FIN (headers-only close) to a permitted route (e.g., /early), but include a nonzero Content-Length: N header with no DATA frames. Envoy marks this as complete and forwards it to the HTTP/1 upstream with the stale Content-Length: N.
4. Craft the second HTTP/3 request: Immediately send a second HTTP/3 request to an allowed route (e.g., /allowed), but embed a smuggled HTTP/1 request in the headers (e.g., x-smuggle: GET /pwn HTTP/1.1). The beginning bytes of this second upstream request are consumed by the origin as the body of the first request.
5. Trigger backend parsing: The remaining bytes of the second upstream request are parsed by the HTTP/1 origin as a new, independent request — in the PoC, GET /pwn HTTP/1.1 — which the origin processes and responds to.
6. Receive smuggled response: The second downstream H3 stream receives the backend's response to GET /pwn HTTP/1.1 (SMUGGLED-PWN), bypassing Envoy's route denial for /pwn (GitHub Advisory).

• Network: Unexpected HTTP/3 (QUIC/UDP port 443) requests with Content-Length > 0 but no request body data frames; unusual or mismatched responses on the second HTTP/3 stream relative to the requested path.
• Logs: Backend access logs showing request sequences where REQ#1 has a nonzero Content-Length but the body content matches the beginning of a subsequent upstream request (e.g., GET /allowed HTTP/1.1\r\n...); backend logs showing REQ#2 parsing a path that was never directly requested by a client.
• Application Behavior: Clients receiving responses for paths they did not request (e.g., receiving SMUGGLED-PWN body content when requesting /allowed); Envoy access logs showing a request to /allowed while the backend logs show a request to /pwn on the same connection (GitHub Advisory).

Envoy has released fixed versions: 1.35.11, 1.36.7, 1.37.3, and 1.38.1 (and later patch releases 1.35.13, 1.36.9, 1.37.5, 1.38.3). Upgrading to a patched version is the recommended remediation. If immediate patching is not possible, consider disabling HTTP/3 (QUIC) support on downstream listeners, or restricting upstream connections to HTTP/2 rather than HTTP/1 to eliminate the vulnerable translation path. Additionally, configuring upstream origins to always consume the full declared request body before responding (or to close connections after early responses) can reduce exploitability (GitHub Advisory).

The vulnerability was coordinated through GitHub Security Advisories by reporter ndkoo with coordinators agrawroh and phlax from the Envoy project. The Istio project released a related advisory (announcing Istio 1.28.9) referencing this CVE, indicating downstream impact on Istio users. openSUSE also issued a security announcement referencing the vulnerability. No significant broader media coverage or notable social media commentary beyond standard CVE tracking feeds has been observed (GitHub Advisory, Istio Release).