CVE-2026-53714 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, the xDS gRPC server in GatewayNamespaceMode, configured through provider.kubernetes.deploy.type=GatewayNamespace, installs a JWT StreamInterceptor but no UnaryInterceptor, leaving every unary Fetch RPC unauthenticated. The streaming interceptor also authenticates only discoveryv3.DeltaDiscoveryRequest messages; a discoveryv3.DiscoveryRequest used by the State-of-the-World protocol fails the type assertion and returns success without JWT validation. Any pod that can reach port 18000 can use the unauthenticated unary or State-of-the-World paths to retrieve TLS private keys through StreamSecrets, all xDS resources through StreamAggregatedResources, backend endpoints through StreamClusters or StreamEndpoints, and routing configuration through StreamRoutes or StreamListeners. This issue is fixed in versions 1.7.4 and 1.8.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
Envoy Gateway serves as a critical infrastructure component for managing the Envoy Proxy within both standalone and Kubernetes-based application gateway deployments. The security architecture of this system relies heavily on the xDS gRPC server to distribute configuration data, such as routing rules, cluster definitions, and secrets, to proxy instances. In versions prior to 1.7.4 and 1.8.1, a significant authentication flaw was present in the GatewayNamespaceMode implementation, which is activated when the provider.kubernetes.deploy.type is set to GatewayNamespace. This configuration mode exposes an xDS gRPC server on port 18000 that handles various discovery requests essential for proxy operation. The vulnerability stems from an incomplete enforcement of JSON Web Token (JWT) authentication mechanisms within this specific operational context, creating a pathway for unauthorized access to sensitive internal configurations and credentials.
The technical root cause involves two distinct failures in the interceptor logic used by the gRPC server. First, while a JWT StreamInterceptor is installed to handle streaming requests, no corresponding UnaryInterceptor is configured. This omission means that all unary Fetch RPCs are processed without any authentication checks. Second, even within the authenticated stream handling path, there is a type assertion error regarding message types. The interceptor correctly authenticates discoveryv3.DeltaDiscoveryRequest messages but fails to properly validate JWT tokens for discoveryv3.DiscoveryRequest messages. In the State-of-the-World protocol variant of xDS, clients use DiscoveryRequest rather than DeltaDiscoveryRequest. Due to this flaw, these requests bypass authentication entirely and return success without verifying the identity of the requester. This represents a classic case where partial implementation of security controls leads to complete circumvention in specific code paths.
The operational impact of this vulnerability is severe due to the sensitivity of the data accessible through the xDS endpoints. Any pod or network entity that can reach port 18000 on the Envoy Gateway instance can exploit these unauthenticated channels. By leveraging the StreamSecrets endpoint, an attacker can retrieve TLS private keys, which compromises the confidentiality and integrity of encrypted communications handled by the gateway. Furthermore, access to StreamAggregatedResources allows for the extraction of all xDS resources, providing a comprehensive map of the infrastructure's configuration. Attackers can also utilize StreamClusters or StreamEndpoints to discover backend services and their network locations, facilitating lateral movement within the cluster. Additionally, accessing StreamRoutes or StreamListeners reveals detailed routing configurations, enabling potential traffic manipulation or service disruption. This level of access effectively grants an attacker full visibility into the gateway's operational state and security credentials.
From a classification perspective, this vulnerability aligns with CWE-287: Improper Authentication, as the system fails to correctly verify identity before granting access to protected resources. It also relates to CWE-693: Protection Mechanism Failure, specifically in how the authentication mechanism is bypassed through unhandled message types and missing interceptors for unary calls. In terms of offensive security frameworks, this exploit maps directly to MITRE ATT&CK technique T1504.002: Web Service Discovery via Cloud Infrastructure, as it involves enumerating and accessing internal service configurations. The ability to retrieve TLS keys further implicates techniques associated with credential access and potential man-in-the-middle attacks if the private keys are misused elsewhere in the infrastructure.
To mitigate this vulnerability, organizations must immediately upgrade Envoy Gateway to version 1.7.4 or later for the stable release branch, or version 1.8.1 and above for the development branch. These versions contain patches that ensure both unary and streaming requests undergo proper JWT validation regardless of the message type used in the xDS protocol. Until an upgrade is performed, network-level controls should be implemented to restrict access to port 18000 exclusively to trusted internal components that require direct interaction with the gateway's configuration server. Additionally, monitoring for unusual gRPC traffic patterns on this port can help detect exploitation attempts while remediation efforts are underway. Regular audits of interceptor configurations and authentication middleware in proxy deployments are recommended to prevent similar partial implementation flaws in future updates.