GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy Gateway: unsynchronized Wasm cache map read/write crashes the controller process

CVSS 5.3CVE-2026-53715Container, Kubernetes & orchestrationcurated

Impact

HTTPServer.ServeHTTP reads the mappingPath2Cache map without a lock while HTTPServer.Get writes it during EnvoyExtensionPolicy translation. Go's concurrent map read/write detector calls runtime.throw, which net/http cannot recover from, so the whole controller process dies. Because the Envoy Gateway controller is shared cluster infrastructure, one tenant churning EnvoyExtensionPolicies with distinct Wasm URLs while flooding the unauthenticated port 18002 can stall gateway configuration for every other tenant until Kubernetes restarts the pod. Data plane proxies keep serving their last config, but no new routes or policies land during the outage.

Who can reach it

A workload with pod-network reachability to the controller's port 18002 (unauthenticated) plus namespace permission to create or edit EnvoyExtensionPolicy resources. Both are available to an ordinary tenant in a multi-tenant cluster unless network policy restricts the port.

What to do

Upgrade Envoy Gateway to 1.7.4 or 1.8.1 and let the controller deployment roll; this is a control-plane pod restart, not a node action, and the data plane keeps serving during the rollout. Until you can upgrade, restrict pod-network access to port 18002 with a NetworkPolicy and limit who can create EnvoyExtensionPolicy resources.

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.