CVE-2026-53715

Vulnerability report without repro case. Repro case may be added later after harness is complete. **Preconditions (4):** - Pod-network reachability to :18002 (no auth) - Tenant can create EnvoyExtensionPolicy (baseline) - Attacker pod floods GET while churning EnvoyExtensionPolicy with distinct Wasm URLs - Read at :153 must overlap a write at :201/:209 (probabilistic, attacker controls both rates) **Description:** httpserver.go:153 reads s.mappingPath2Cache with no lock while httpserver.go:201/209 write it under s.Lock(); the struct uses a plain map. Writer is tenant-reachable via EnvoyExtensionPolicy translation, reader is pod-network-reachable on :18002 with per-request goroutines. Go's concurrent map read+write detection calls runtime.throw, which net/http's per-conn recover cannot catch, so the controller process exits — cross-tenant control-plane DoS. Capped at MEDIUM: DoS-only, k8s restarts pod, timing-dependent trigger.

Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.7.4 and 1.8.1, HTTPServer.ServeHTTP in internal/wasm/httpserver.go reads the plain mappingPath2Cache map without synchronization while HTTPServer.Get writes the same map during EnvoyExtensionPolicy translation. An attacker with pod-network access to unauthenticated port 18002 and tenant permission to churn policies with distinct Wasm URLs can flood GET requests until a per-request reader overlaps a writer. Go's concurrent map read and write detection invokes runtime.throw, which the net/http connection recovery cannot catch, terminating the controller process and causing a timing-dependent, cross-tenant control-plane denial of service until Kubernetes restarts the pod. This issue is fixed in versions 1.7.4 and 1.8.1.

Envoy Gateway: Wasm cache ServeHTTP reads mappingPath2Cache without lock in github.com/envoyproxy/gateway