### Impact When Envoy Gateway runs in GatewayNamespaceMode (`provider.kubernetes.deploy.type=GatewayNamespace`), the xDS gRPC server is configured with a `StreamInterceptor` for JWT authentication but no UnaryInterceptor. The go-control-plane xDS server exposes both streaming and unary (Fetch) RPC methods for all registered discovery services. Since there is no unary interceptor, these Fetch endpoints are completely unauthenticated. Additionally, the JWT authentication interceptor in GatewayNamespaceMode only validates tokens when the received gRPC message is of type `discoveryv3.DeltaDiscoveryRequest` . If the message is a `discoveryv3.DiscoveryRequest` — used by the State-of-the-World (SotW) xDS protocol — the type assertion fails, the validation block is skipped entirely, and RecvMsg returns nil (success) without any authentication. Any pod in the cluster that can reach the xDS server (port 18000) can use the SotW protocol to bypass JWT authentication and access: * TLS private keys via StreamSecrets (SDS) * All xDS resources via StreamAggregatedResources (ADS) * Backend endpoints via StreamClusters / StreamEndpoints (CDS/EDS) * Routing rules via StreamRoutes / StreamListeners (RDS/LDS) ### Credits Envoy Gateway thanks @dashingDragon and @Donjon-Cerberus for reporting this issue.
### Impact When Envoy Gateway runs in GatewayNamespaceMode (`provider.kubernetes.deploy.type=GatewayNamespace`), the xDS gRPC server is configured with a `StreamInterceptor` for JWT authentication but no UnaryInterceptor. The go-control-plane xDS server exposes both streaming and unary (Fetch) RPC methods for all registered discovery services. Since there is no unary interceptor, these Fetch endpoints are completely unauthenticated. Additionally, the JWT authentication interceptor in GatewayNamespaceMode only validates tokens when the received gRPC message is of type `discoveryv3.DeltaDiscoveryRequest` . If the message is a `discoveryv3.DiscoveryRequest` — used by the State-of-the-World (SotW) xDS protocol — the type assertion fails, the validation block is skipped entirely, and RecvMsg returns nil (success) without any authentication. Any pod in the cluster that can reach the xDS server (port 18000) can use the SotW protocol to bypass JWT authentication and access: * TLS private keys via StreamSecrets (SDS) * All xDS resources via StreamAggregatedResources (ADS) * Backend endpoints via StreamClusters / StreamEndpoints (CDS/EDS) * Routing rules via StreamRoutes / StreamListeners (RDS/LDS) ### Credits Envoy Gateway thanks @dashingDragon and @Donjon-Cerberus for reporting this issue.
Update github.com/envoyproxy/gateway to 1.8.1; github.com/envoyproxy/gateway to 1.7.4 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanEnvoy Gateway: xDS Control Plane Information Disclosure when operating in GatewayNamespaceMode affects github.com/envoyproxy/gateway (go), github.com/envoyproxy/gateway (go). Severity is high. ### Impact When Envoy Gateway runs in GatewayNamespaceMode (`provider.kubernetes.deploy.type=GatewayNamespace`), the xDS gRPC server is configured with a `StreamInterceptor` for JWT authentication but no UnaryInterceptor. The go-control-plane xDS server exposes both streaming and unary (Fetch) RPC methods for all registered discovery services. Since there is no unary interceptor, these Fetch endpoints are completely unauthenticated. Additionally, the JWT authentication interceptor in GatewayNamespaceMode only validates tokens when the received gRPC message is of type `discoveryv3.DeltaDiscoveryRequest` . If the message is a `discoveryv3.DiscoveryRequest` — used by the State-of-the-World (SotW) xDS protocol — the type assertion fails, the validation block is skipped entirely, and RecvMsg returns nil (success) without any authentication. Any pod in the cluster that can reach the xDS server (port 18000) can use the SotW protocol to bypass JWT authentication and access: * TLS private keys via StreamSecrets (SDS) * All xDS resources via StreamAggregatedResources (ADS) * Backend endpoints via StreamClusters / StreamEndpoints (CDS/EDS) * Routing rules via StreamRoutes / StreamListeners (RDS/LDS) ### Credits Envoy Gateway thanks @dashingDragon and @Donjon-Cerberus for reporting this issue.
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/envoyproxy/gatewaygo | >=1.8.0-rc.0,<1.8.1 | 1.8.1 |
| github.com/envoyproxy/gatewaygo | <1.7.4 | 1.7.4 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/envoyproxy/gateway to 1.8.1; github.com/envoyproxy/gateway to 1.7.4 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanEnvoy Gateway: xDS Control Plane Information Disclosure when operating in GatewayNamespaceMode affects github.com/envoyproxy/gateway (go), github.com/envoyproxy/gateway (go). Severity is high. ### Impact When Envoy Gateway runs in GatewayNamespaceMode (`provider.kubernetes.deploy.type=GatewayNamespace`), the xDS gRPC server is configured with a `StreamInterceptor` for JWT authentication but no UnaryInterceptor. The go-control-plane xDS server exposes both streaming and unary (Fetch) RPC methods for all registered discovery services. Since there is no unary interceptor, these Fetch endpoints are completely unauthenticated. Additionally, the JWT authentication interceptor in GatewayNamespaceMode only validates tokens when the received gRPC message is of type `discoveryv3.DeltaDiscoveryRequest` . If the message is a `discoveryv3.DiscoveryRequest` — used by the State-of-the-World (SotW) xDS protocol — the type assertion fails, the validation block is skipped entirely, and RecvMsg returns nil (success) without any authentication. Any pod in the cluster that can reach the xDS server (port 18000) can use the SotW protocol to bypass JWT authentication and access: * TLS private keys via StreamSecrets (SDS) * All xDS resources via StreamAggregatedResources (ADS) * Backend endpoints via StreamClusters / StreamEndpoints (CDS/EDS) * Routing rules via StreamRoutes / StreamListeners (RDS/LDS) ### Credits Envoy Gateway thanks @dashingDragon and @Donjon-Cerberus for reporting this issue.
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/envoyproxy/gatewaygo | >=1.8.0-rc.0,<1.8.1 | 1.8.1 |
| github.com/envoyproxy/gatewaygo | <1.7.4 | 1.7.4 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard