GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy Gateway: extension-managed backendRef skips ReferenceGrant checks across namespaces

CVSS 6.4CVE-2026-53718Container, Kubernetes & orchestrationcurated

Impact

The custom-backend branch in internal/gatewayapi/route.go omits validateBackendNamespace, so an HTTPRoute using an extension-managed backendRef can bind to a resource in another namespace with no ReferenceGrant in the target namespace. That breaks the Gateway API consent model: the namespace owning the route decides unilaterally, and the namespace owning the backend never approves. In a multi-tenant GPU cluster where namespaces are the tenancy boundary, a tenant can publish traffic to another tenant's internal service - an inference endpoint, a model registry, a feature store - through the shared gateway, exposing data that was only ever meant to be reachable inside its own namespace. Exploitation requires the cluster to have an extension server configured and custom backend types in use, which is what keeps the complexity rating high.

Who can reach it

An authenticated tenant with RBAC to create HTTPRoutes in its own namespace, in a cluster that has an Envoy Gateway extension server providing custom backend resources. No access to the target namespace is needed.

What to do

Upgrade Envoy Gateway to 1.7.4 or 1.8.1 and restart the controller deployment; no node disruption. Until patched, audit existing HTTPRoutes for custom backendRefs pointing outside their own namespace and compare against the ReferenceGrants that actually exist, since the missing check means past bindings were never validated.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.