GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy: request smuggling via non-WebSocket HTTP upgrade leaks responses to other clients

CVSS 7.5CVE-2026-73548Container, Kubernetes & orchestrationcurated

Impact

An unauthenticated HTTP/2 client can embed a complete HTTP/1.1 request inside extended CONNECT data for a configured non-WebSocket upgrade. Envoy writes that data unframed to a keep-alive HTTP/1.1 upstream and returns the socket to the shared pool with the smuggled response still queued, so the next downstream client on that pool gets the attacker's response. On a GPU cluster where Envoy fronts inference endpoints or sits in the service mesh, that means cross-tenant response leakage: one tenant's prompt or model output can be delivered to another tenant's request. WebSocket upgrades, plain CONNECT, disabled upstream keep-alive, per-downstream pools, and max_requests_per_connection=1 are outside the demonstrated path.

Who can reach it

Any unauthenticated client that can reach a listener with a non-WebSocket HTTP upgrade configured and a keep-alive HTTP/1.1 upstream behind it. No credentials needed.

What to do

Upgrade Envoy to 1.36.10, 1.37.6, 1.38.4 or 1.39.1 and restart the proxy; a rolling restart of the mesh data plane or gateway fleet is enough, no node drain. As an interim mitigation, remove non-WebSocket upgrade_configs, or set max_requests_per_connection to 1 / disable upstream keep-alive on the affected clusters.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.