Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-14T21:17:12.833Z",
  "pubdate": "2026-09-14T21:17:12.833Z",
  "executiveSummary": "A race condition vulnerability exists in Envoy Gateway versions prior to 1.7.4 and 1.8.1, stemming from unsynchronized access to a shared map object.\nThe vulnerability is classified as a data race leading to a denial of service (DoS).\nIt affects the internal/wasm/httpserver.go component, specifically during the handling of Wasm policy translations.\nAn attacker with pod-network access to the unauthenticated port 18002 can exploit this by rapidly churn policy configurations to trigger concurrent read/write operations.\nGo's runtime detects the illegal concurrent map access and invokes a fatal panic (runtime.throw), which is unrecoverable by the net/http stack, causing the controller process to terminate.\nThis vulnerability presents a cross-tenant security risk, as a single tenant can cause a system-wide control-plane denial of service, forcing a Kubernetes-level restart of the pod to restore functionality.\nExploitation requires no authentication, relying solely on network reachability to the exposed management port.",
  "technicalDetails": "The root cause of this vulnerability is a lack of synchronization primitives (such as sync.RWMutex or sync.Map) when accessing the mappingPath2Cache map within the HTTPServer implementation.\nThe vulnerable code resides in internal/wasm/httpserver.go. The HTTPServer.ServeHTTP function performs read operations on mappingPath2Cache, while the HTTPServer.Get function performs write operations during the EnvoyExtensionPolicy translation process.\nIn the Go programming language, concurrent reads and writes to a map are not thread-safe and are explicitly disallowed by the runtime. When the Go runtime detects such an operation, it immediately invokes runtime.throw to terminate the process, as the memory integrity of the map structure cannot be guaranteed.\nThe attack flow begins with an attacker who possesses pod-network access to the management port 18002. Since this port is unauthenticated, the attacker can submit a rapid succession of API requests designed to trigger the EnvoyExtensionPolicy translation mechanism.\nBy continuously churning policies with distinct Wasm URLs, the attacker forces the HTTPServer.Get function to write to the mappingPath2Cache map. Simultaneously, the attacker floods the system with GET requests that trigger HTTPServer.ServeHTTP, forcing the runtime to execute read operations on the same map memory address.\nBecause the operations occur concurrently without mutual exclusion, a collision occurs. The Go runtime detects the data race and panics. Because the net/http server recovery mechanisms cannot catch a runtime fatal error/throw, the entire controller process crashes.\nThe impact is a complete control-plane denial of service. The service remains unavailable until the Kubernetes orchestration layer detects the process termination and restarts the pod. This constitutes a cross-tenant impact, as the crash disrupts control-plane operations for all users of the affected Envoy Gateway instance, not just the attacker.\nThis vulnerability persists in all versions prior to 1.7.4 and 1.8.1, where concurrent access is not guarded by appropriate synchronization primitives."
}