GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy Gateway: unauthenticated xDS on port 18000 hands out TLS private keys and full routing config

CVSS 7.4CVE-2026-53714Container, Kubernetes & orchestrationcurated

Impact

In GatewayNamespaceMode the xDS gRPC server installs a JWT StreamInterceptor but no UnaryInterceptor, so every unary Fetch RPC is unauthenticated; the streaming interceptor only type-asserts DeltaDiscoveryRequest, so a State-of-the-World DiscoveryRequest fails the assertion and is returned as success without any JWT validation. Any pod that can open a connection to port 18000 can pull TLS private keys via StreamSecrets, all endpoints, listeners, routes and clusters via the aggregated or per-type streams. On a shared GPU cluster that fronts inference endpoints through Envoy Gateway, one tenant pod with cluster network reach walks away with the certificates and the full internal topology - enough to impersonate any service the gateway terminates TLS for. Key compromise is not fixed by the patch alone.

Who can reach it

Any pod or host with network reach to the Envoy Gateway xDS port 18000 in a GatewayNamespaceMode deployment. No authentication required.

What to do

Upgrade Envoy Gateway to 1.7.4 or 1.8.1 and roll the control-plane deployment - a daemon restart, not a node action. Because private keys may already have been served to anything that could reach the port, treat the certificates handled by affected gateways as exposed and reissue them. Until the upgrade, restrict reachability of port 18000 with a NetworkPolicy that permits only the proxy pods.

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.