CVE-2026-53715 in Envoy Gateway
Summary
by MITRE • 09/14/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability resides within Envoy Gateway, an open-source project designed to manage the Envoy Proxy as either a standalone application gateway or a Kubernetes-based ingress controller. Specifically, the flaw affects internal components responsible for handling HTTP server requests and managing WebAssembly extension policies. In versions prior to 1.7.4 and 1.8.1, the architecture utilizes an unsynchronized map structure named mappingPath2Cache within the internal/wasm/httpserver.go module. This data structure is intended to cache mappings related to Wasm URLs but lacks proper concurrency controls such as mutex locks or read-write synchronization mechanisms. Consequently, concurrent access patterns that involve both reading and writing operations on this shared resource trigger undefined behavior inherent to Go's runtime environment when handling maps concurrently without safeguards.
The technical mechanism of the exploit relies on a race condition between reader and writer goroutines. The HTTPServer.ServeHTTP function performs reads from the mappingPath2Cache map, while the HTTPServer.Get method writes to it during the translation process for EnvoyExtensionPolicy resources. An attacker who possesses pod-network access to the unauthenticated port 18002 can exploit this timing window by generating a high volume of GET requests. By carefully crafting tenant permissions that allow churn policies with distinct Wasm URLs, the adversary ensures that write operations are frequently triggered while read operations are continuously executed. This deliberate flooding increases the probability of a per-request reader overlapping with a writer operation on the unsynchronized map.
When such an overlap occurs, Go's runtime detects the concurrent modification and invokes a fatal error via runtime.throw. Unlike standard panics which might be recovered by higher-level handlers in the net/http package, this specific type of fatal error cannot be caught or handled gracefully by connection recovery mechanisms. As a result, the controller process terminates immediately upon detection of the race condition. This leads to a complete crash of the Envoy Gateway control plane component responsible for managing these policies. The termination is not merely a transient glitch but results in the cessation of service until the Kubernetes orchestrator detects the pod failure and restarts it, introducing significant downtime during that interval.
The operational impact of this vulnerability constitutes a timing-dependent, cross-tenant denial of service against the control plane. Because the attack requires specific tenant permissions to churn policies with distinct Wasm URLs, it is not entirely unrestricted but remains accessible to any authenticated user within a multi-tenant environment who has been granted policy management rights. The attacker does not need elevated privileges beyond standard tenant-level access, making this a significant risk in shared infrastructure environments where isolation between tenants relies on the stability of the control plane. Once triggered, the crash disrupts all dependent services relying on that Envoy Gateway instance until automatic recovery occurs via Kubernetes pod restarts, potentially causing service outages for multiple downstream applications routed through the compromised gateway.
This vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The lack of mutex protection around a map accessed by multiple goroutines is a classic example of this class of software errors. Furthermore, from an offensive security perspective, particularly within the MITRE ATT&CK framework, this behavior can be associated with T1499 Endpoint Denial of Service or more specifically T1505 Server Software Component if viewed through the lens of compromising infrastructure components to disrupt availability. The attack vector leverages legitimate API endpoints and tenant permissions, making it difficult to distinguish from normal traffic without deep inspection of concurrency patterns and resource usage metrics.
Mitigation for this issue involves upgrading Envoy Gateway to version 1.7.4 or later, where the internal synchronization mechanisms have been corrected to prevent concurrent map access errors. Organizations running older versions should implement network segmentation strategies to restrict access to port 18002 only from trusted sources if possible, although since authentication is required for policy churn, strict identity and access management policies are critical. Monitoring tools should be configured to detect sudden spikes in GET requests targeting Wasm-related endpoints or frequent pod restarts of Envoy Gateway containers, which may indicate an ongoing exploitation attempt. Until upgrades can be applied, limiting the scope of tenant permissions regarding policy creation and modification reduces the attack surface available for triggering this race condition effectively.