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, an HTTPRoute can use an extension-managed custom backendRef to reference a backend resource in another namespace without a matching Gateway API ReferenceGrant in the target namespace. The custom-backend branch in internal/gatewayapi/route.go omits validateBackendNamespace, allowing the route-owning namespace to bind to and use the resource without the backend namespace owner's consent and violating the Gateway API cross-namespace authorization model. This issue is fixed in versions 1.7.4 and 1.8.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-09-14T21:17:13.140Z",
  "pubdate": "2026-09-14T21:17:13.140Z",
  "executiveSummary": "Envoy Gateway is susceptible to a cross-namespace authorization bypass vulnerability that violates the established Gateway API security model. The vulnerability stems from an inadequate validation mechanism when processing custom backendRef configurations within HTTPRoutes.\nBy omitting the required namespace validation check, the system allows an attacker to bypass mandatory ReferenceGrant authorization requirements. This enables a user in one namespace to bind an HTTPRoute to backend resources located in unauthorized target namespaces without the backend owner's explicit consent.\nThis vulnerability affects Envoy Gateway versions prior to 1.7.4 and 1.8.1. The impact includes unauthorized access to backend resources and potential lateral movement or resource poisoning, depending on the nature of the backend being accessed. Successful exploitation requires an attacker to possess the ability to define or modify HTTPRoutes within the cluster. Because Envoy Gateway operates as a Kubernetes-based application gateway, this flaw undermines the multi-tenancy isolation guarantees provided by the Gateway API, presenting a critical risk to environments relying on strict namespace-based access control.",
  "technicalDetails": "The vulnerability resides within the internal/gatewayapi/route.go component of Envoy Gateway, specifically during the processing of custom backendRef resources. The Gateway API specification mandates a strict cross-namespace authorization model, requiring a ReferenceGrant resource to be present in the target namespace to authorize a cross-namespace reference. This serves as a critical security boundary to prevent unauthorized resource coupling.\nThe root cause of this vulnerability is the omission of the validateBackendNamespace function within the custom-backend branch of the routing logic. In standard implementations, this function is responsible for verifying that the requesting route-owning namespace has been granted explicit permission to bind to the target backend resource. By failing to invoke this validation during the configuration reconciliation process, the Envoy Gateway controller fails to enforce the ReferenceGrant protocol.\nThe attack flow follows a specific progression: First, an attacker identifies a target backend resource residing in a namespace for which they do not have administrative control. Second, the attacker defines an HTTPRoute within their own namespace (or an environment they control) and specifies a custom backendRef pointing to the sensitive resource in the unauthorized namespace. Third, when the Envoy Gateway controller processes this HTTPRoute, the internal/gatewayapi/route.go logic proceeds to configure the route without checking for a corresponding ReferenceGrant.\nBecause the validation check is bypassed, the Envoy Gateway successfully reconciles the configuration, effectively linking the traffic path to the unintended backend. The system treats the unauthorized reference as legitimate, allowing traffic originating from the malicious route to be routed directly to the victim backend. This bypasses the intended Kubernetes RBAC and Gateway API isolation constraints. The exploitation requires the attacker to have permissions to create or update HTTPRoute objects, which is common in many multi-tenant Kubernetes configurations. Post-exploitation impact allows for the proxying of traffic to internal services that were intended to be private or restricted to specific namespaces, potentially leading to unauthorized data access, service disruption, or further exploitation of backend services that assume requests are coming from trusted sources within their own namespace boundary. This affects versions prior to 1.7.4 and 1.8.1."
}