SURIQ
Envoy Gateway, the widely deployed Kubernetes gateway built on the Envoy proxy, just made public a critical flaw that turns one of its safest-looking features into a cluster-wide credential leak. Tracked as CVE-2026-53713 and rated CVSS 9.1, it lets any user allowed to submit a custom extension policy read secret files straight off the gateway's controller pod: its Kubernetes service-account token, its TLS private keys, and its process environment. With that token in hand, an attacker talks to the Kubernetes API server as the controller and reaches secrets across the cluster. The fix shipped quietly in Envoy Gateway 1.7.4 and 1.8.1 in early June; the advisory itself only went public on July 16, so many operators are learning about it now.
The feature that was supposed to be sandboxed
Envoy Gateway lets platform teams attach small custom scripts, written in the Lua language, to the traffic path using a resource called an EnvoyExtensionPolicy. Running arbitrary code inside a gateway is obviously risky, so the project guards it: by default the controller runs submitted Lua through a Strict validation step before accepting it. That validation executes the script in a sandbox whose whole job is to block dangerous operations, including reading sensitive files, before the policy is ever allowed near live traffic.
The defect is in that guard. The sandbox decides whether a file path is off-limits with a helper, to_absolute_normalized_path, feeding an is_critical_path check. The helper never collapses redundant slashes. On Linux, //var/run/secrets/kubernetes.io/serviceaccount/token points at the exact same file as the single-slash version, but the string does not begin with the blocked prefix, so the critical-path check waves it through. A path that should have been rejected is treated as harmless, and the sandboxed script reads it anyway, during validation, inside the controller pod.
What the leaked token unlocks
The files the advisory calls out are not trophies, they are keys. The controller pod's Kubernetes service-account token is a working credential for the cluster's API server. Its TLS certificates and private keys secure the control-plane channel Envoy Gateway uses to push configuration to the proxies. The advisory also lists /proc/self/environ, which can carry more secrets injected as environment variables. Read any of these and you are no longer confined to the gateway: you can query the Kubernetes API server or the configuration (xDS) server with the controller's own identity, and pull whatever secrets that identity can see. In most installs the gateway controller is a privileged component, so that is a short walk from one tenant's extension policy to the crown jewels.
Who is actually exposed
This is not an unauthenticated internet attacker. The CVSS vector, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L, spells out the shape: network reachable, low complexity, but it needs low privileges, specifically the ability to create an EnvoyExtensionPolicy with Lua. The high score comes from the Scope: Changed rating, which is the standard's way of saying a foothold in one place breaks out into another security boundary. That is exactly the multi-tenant Kubernetes story. If application teams or customers can define their own gateway extensions in their own namespaces, this flaw hands any one of them the controller's cluster credentials. If the only people who can create these policies are the same cluster admins who already hold the keys, your exposure is smaller, but you should still close it, because RBAC on custom resources drifts and the next operator you onboard may widen it without noticing.
Upgrade, then decide who is allowed to run Lua at all
The patch is a version bump, and the honest first move is to apply it everywhere the gateway runs.
| If you run | Status | Move to |
|---|---|---|
| Anything below 1.7.4 | Vulnerable | 1.7.4 |
| 1.8.0, including its release candidates | Vulnerable | 1.8.1 |
Upgrading is necessary but it is not the whole posture, because the deeper question is why untrusted tenants can inject code into your gateway at all. Envoy Gateway now offers a disableLua setting on the EnvoyProxy resource that rejects any policy carrying Lua outright. If you do not actually rely on custom Lua, turning it off removes this entire class of bug rather than patching one instance of it. Then tighten the Kubernetes role-based access controls that decide who may create an EnvoyExtensionPolicy, and treat that permission as the sensitive grant it is, on par with letting someone run code in the control plane.
Detection is thinner than you would like, because a validation-time read leaves little to find after the fact. Audit your cluster for existing EnvoyExtensionPolicy objects that contain Lua, and review who holds the create permission on them through Kubernetes audit logs. On the runtime side, the real tell is misuse of the leaked identity: watch for the gateway controller's service-account token being used from a pod or source it should never originate from, which is the kind of anomalous-credential signal a threat hunting program is built to surface. And because this landed in a batch of seven Envoy Gateway advisories fixed in the same release, including a separate xDS authentication bypass, the branch you are on matters more than any single CVE: getting current on 1.7.4 or 1.8.1 closes all of them at once. Ordering that work against the rest of your queue by real exposure rather than raw score is the whole point of vulnerability detection done well.
This is a familiar failure mode wearing new clothes: a security control that normalizes input for a decision, but not thoroughly enough, so a trivial encoding trick, one extra slash, walks past it. The lesson is not that Lua extensions are bad. It is that the layer you trust to keep untrusted code honest is itself code, and it deserves the same suspicion as everything it is guarding.