GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy: oversized host/:authority header aborts the proxy process when auto_sni is enabled

CVSS 7.5CVE-2024-32475Container, Kubernetes & orchestrationcurated

Impact

An unauthenticated request carrying a host/:authority header longer than 255 characters makes Envoy abort its own process instead of handling the SNI-too-long error. On a GPU fleet Envoy is usually the ingress gateway or the service-mesh sidecar in front of inference endpoints, so a single malformed request kills request serving for everything behind that proxy. Where Envoy runs as a sidecar next to a model server, the pod restarts even though the GPU workload itself is healthy, and repeated requests hold it in a crash loop. No data disclosure or code execution is involved - this is availability only, and only for configurations where an upstream TLS cluster uses auto_sni.

Who can reach it

Anyone who can send an HTTP request through the proxy, no authentication required, when the route targets an upstream TLS cluster with auto_sni enabled. Internet-facing ingress gateways are reachable by anyone; a mesh sidecar is reachable by any workload that can address the service.

What to do

Upgrade Envoy to 1.30.1, 1.29.4, 1.28.3 or 1.27.5. Ingress gateways and standalone proxies take a daemon restart (drain and roll the gateway deployment); mesh sidecars need the affected pods restarted to pick up the new image, which on a GPU node means recreating the serving pod but not draining or rebooting the node. As an interim mitigation, disable auto_sni on upstream TLS clusters or reject over-length host/:authority headers at the edge.

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.