Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/envoyproxy/gateway >= 1.8.0-rc.0, < 1.8.1; < 1.7.4
Fixed in
1.8.11.7.4· Vendor fix available
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…
Recommended action: Upgrade to 1.8.1 or 1.7.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/gateway >= 1.8.0-rc.0, < 1.8.1; < 1.7.4
Fixed in
1.8.11.7.4· Vendor fix available
Issue
Impact The toabsolutenormalizedpath function (security.lua:28-43) does not collapse redundant path separators (// → /). On Linux, //etc/passwd is equivalent to /etc/passwd (POSIX path semantics), but iscriticalpath fails to match the double-slash variant because //etc/passwd does not start with /etc/. This allows Lua code submitted as an EnvoyExtensionPolicy to read arbitrary files from the gateway controller pod's filesystem during Strict validation (the default), including: /etc/passwd Kubernetes SA tokens via //var/run/secrets/kubernetes.io/serviceaccount/token TLS certificates via //certs/... Process environment via //proc/self/environ These credentials can be used to read sensitive information from the K8s API Server or from the Gateway XDS server. Patches This has been patched in versions = v1.7.4 and v1.8.1 - Collapse redundant path separators (// to /) so double-slash variants like //etc/passwd and //var/run/secrets/... are matched by the critical-path check. - Rewrite the…
Recommended action: Upgrade to 1.8.1 or 1.7.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/gateway >= 1.8.0-rc.0, < 1.8.1; < 1.7.4
Fixed in
1.8.11.7.4· Vendor fix available
Issue
Vulnerability report without repro case. Repro case may be added later after harness is complete. Preconditions (4): - Pod-network reachability to :18002 (no auth) - Tenant can create EnvoyExtensionPolicy (baseline) - Attacker pod floods GET while churning EnvoyExtensionPolicy with distinct Wasm URLs - Read at :153 must overlap a write at :201/:209 (probabilistic, attacker controls both rates) Description: httpserver.go:153 reads s.mappingPath2Cache with no lock while httpserver.go:201/209 write it under s.Lock(); the struct uses a plain map. Writer is tenant-reachable via EnvoyExtensionPolicy translation, reader is pod-network-reachable on :18002 with per-request goroutines. Go's concurrent map read+write detection calls runtime.throw, which net/http's per-conn recover cannot catch, so the controller process exits — cross-tenant control-plane DoS. Capped at MEDIUM: DoS-only, k8s restarts pod, timing-dependent trigger.
Recommended action: Upgrade to 1.8.1 or 1.7.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/gateway >= 1.8.0-rc.0, < 1.8.1; < 1.7.4
Fixed in
1.8.11.7.4· Vendor fix available
Issue
Vulnerability report without repro case. Repro case may be added later after harness is complete. Preconditions (4): - Tenant can create EnvoyExtensionPolicy (baseline) - Controller has egress to attacker-controlled OCI registry - No registry allowlist (none exists in code) - Layer presents Docker/OCI media type Description At imagefetcher.go:287, make([]byte, h.Size) uses the attacker-controlled tar-header size; the LimitReader at :278 bounds bytes read from the stream but not the header-declared size returned by tr.Next() (a 512-byte header can claim a multi-TB entry via PAX/GNU encoding). Reached from untrusted tenant input via EnvoyExtensionPolicy spec.wasm[].code.image.url (envoyextensionpolicy.go:1157 → cache.go:262/299 → imagefetcher.go:218 → :287), and the allocation happens for every tar entry regardless of filename. The resulting Go runtime OOM throw is unrecoverable and, because the CRD persists, crash-loops the shared controller — single-request, non-volumetric,…
Recommended action: Upgrade to 1.8.1 or 1.7.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/gateway >= 1.8.0-rc.0, < 1.8.1; < 1.7.4
Fixed in
1.8.11.7.4· Vendor fix available
Issue
Vulnerability report without repro case. Repro case may be added later after harness is complete. Preconditions (4): - Tenant has SecurityPolicy + TCPRoute RBAC (baseline) - Tenant namespace permitted to attach TCPRoute to a Gateway listener - spec.authorization omitted (the trigger) - No admission webhook blocks the shape Description: A namespace-scoped tenant can deterministically panic the gatewayapi runner on every reconcile with a single CRD; the recover() in message/watchutil.go:53 keeps the process alive but unwinds the entire handle() callback in runner/runner.go:192, so xDS/Infra IR publishing stalls controller-wide until an admin deletes the object. Data plane keeps serving last-good config.
Recommended action: Upgrade to 1.8.1 or 1.7.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/gateway >= 1.8.0-rc.0, < 1.8.1; < 1.7.4
Fixed in
1.8.11.7.4· Vendor fix available
Issue
Vulnerability report without repro case. Repro case may be added later after harness is complete. Preconditions (4): - Tenant can create EnvoyExtensionPolicy (baseline) - Attacker hosts a gzip-bomb at a reachable URL - sha256 unset (optional field; check is post-decompression anyway) - No operator Wasm-URL allowlist (none exists in code) Description getFileFromGZ calls io.ReadAll on a raw gzip.Reader (httpfetcher.go:216) with no output bound, while the compressed input is capped at 256 MiB (httpfetcher.go:139). The bytes originate from a tenant-controlled EnvoyExtensionPolicy.spec.wasm[].code.http.url (envoyextensionpolicy.go:1077 → cache.go:248 → httpfetcher.go:147 → :233), so an untrusted tenant can point at a ~10 MiB gzip-of-zeros and force ~10 GiB allocation in the shared controller process. All candidate guards execute either before the body is buffered or after decompression. OOM-kills, restarts, re-reconciles same CR, crash-loops — persistent cross-tenant control-plane outage…
Recommended action: Upgrade to 1.8.1 or 1.7.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/gateway >= 1.8.0-rc.0, < 1.8.1; < 1.7.4
Fixed in
1.8.11.7.4· Vendor fix available
Issue
Impact Envoy Gateway accepts extension-managed custom backendRefs from an HTTPRoute to a backend resource in another namespace without requiring a matching Gateway API ReferenceGrant in the target namespace. This breaks the Gateway API cross-namespace consent model: the namespace that owns the referenced backend resource does not need to opt in with a ReferenceGrant before another namespace’s HTTPRoute can use that resource. Patches 1.7.4 1.8.1
Recommended action: Upgrade to 1.8.1 or 1.7.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/gateway >= 1.6.0-rc.0, < 1.6.2; < 1.5.7
Fixed in
1.6.21.5.7· Vendor fix available
Issue
Impact Envoy Gateway allows users to create Lua scripts that are executed by Envoy proxy using the EnvoyExtensionPolicy resource. Administrators can use Kubernetes RBAC to grant users the ability to create EnvoyExtensionPolicy resources. Lua scripts in policies are executed in two contexts: An EnvoyExtensionPolicy can be attached to Gateway and xRoute resources. Lua scripts in the policy will process traffic in that scope. Lua scripts are interpreted and run by the Envoy Gateway controller pod for validation purposes. Lua scripts executed by Envoy proxy can be used to leak the proxy's credentials. These credentials can then be used to communicate with the control plane and gain access to all secrets that are used by Envoy proxy, e.g. TLS private keys and credentials used for downstream and upstream communication. For example, the following EnvoyExtensionPolicy, when executed by Envoy proxy, will leak the proxy's XDS client certificates. This execution can lead to arbitrary code…
Recommended action: Upgrade to 1.6.2 or 1.5.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/gateway < 1.2.7; >= 1.3.0-rc.1, < 1.3.1
Fixed in
1.3.11.2.7· Vendor fix available
Issue
Impact In all Envoy Gateway versions prior to 1.2.7 and 1.3.1 a default Envoy Proxy access log configuration is used. This format is vulnerable to log injection attacks. If the attacker uses a specially crafted user-agent which performs json injection, then he could add and overwrite fields to the access log. Examples of attacks include: - Using following string as user agent : HELLO-WORLD", "evil-ip": "1.1.1.1", "x-forwarded-for": "1.1.1.1 would lead to setting of new access log properties and overwrite of existing properties. Existing properties such as the value of the X-Forwarded-For header may have importance for security analysis of access logs, and their overwrite can be used to hide malicious activity. - Using the following string as user-agent : " which renders an invalid json document. The invalid document may fail to be processed by observability solutions, which would allow attacker to hide malicious activity. Patches 1.3.1, 1.2.7 Fix Using JSON format as the default…
Recommended action: Upgrade to 1.3.1 or 1.2.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A user with access to a Kubernetes cluster where Envoy Gateway is installed can use a path traversal attack to execute Envoy Admin interface commands on proxies managed by Envoy Gateway. The admin interface can be used to terminate the Envoy process and extract the Envoy configuration (possibly containing confidential data). For example, the following command, if run from within the Kubernetes cluster, can be used to get the configuration dump of the proxy: Patches 1.2.6 Workarounds The EnvoyProxy API can be used to apply a bootstrap config patch that restricts access strictly to the prometheus stats endpoint. Find below an example of such a bootstrap patch. References - Envoy Admin Interface: https://www.envoyproxy.io/docs/envoy/latest/operations/admin - Envoy Configuration Best Practices: https://www.envoyproxy.io/docs/envoy/latest/configuration/bestpractices/edge
Recommended action: Upgrade to 1.2.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.