Bug 2533378 (CVE-2026-53715)

Summary: CVE-2026-53715 github.com/envoyproxy/gateway: Envoy Gateway: Denial of Service via Wasm cache improper synchronization
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Envoy Gateway. Improper synchronization in the Wasm cache handling allows an attacker with pod-network access and tenant permissions to trigger a race condition. By flooding GET requests, an attacker can cause a read-write overlap, leading to the termination of the controller process. This results in a timing-dependent, cross-tenant control-plane Denial of Service (DoS) until the affected pod is restarted.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-14 20:31:47 UTC
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.