CVE-2026-53713: Envoy Gateway Information Disclosure Flaw

CVE-2026-53713 Overview

CVE-2026-53713 is a path normalization flaw in Envoy Gateway, an open source controller for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. The to_absolute_normalized_path function in internal/gatewayapi/luavalidator/security.lua fails to collapse redundant path separators before is_critical_path evaluates Lua submitted through EnvoyExtensionPolicy during default Strict validation. Because Linux resolves a double-slash absolute path as the corresponding single-slash path, an attacker can bypass the validator and submit Lua that reads arbitrary files from the gateway controller pod. The issue is fixed in versions 1.7.4 and 1.8.1. The weakness is classified as [CWE-20 Improper Input Validation].

Critical Impact
A validated Lua submission can read Kubernetes service-account tokens, TLS certificates, and process environment data, exposing credentials that grant access to the Kubernetes API Server and Envoy Gateway xDS server.

Affected Products

Envoy Gateway versions prior to 1.7.4
Envoy Gateway versions prior to 1.8.1
Deployments accepting EnvoyExtensionPolicy resources with Lua under default Strict validation

Discovery Timeline

2026-09-14 - CVE-2026-53713 published to NVD
2026-09-16 - Last updated in NVD database
Fixed releases published as Envoy Gateway v1.7.4 and Envoy Gateway v1.8.1
Coordinated disclosure documented in GitHub Security Advisory GHSA-wcrf-9vrr-854f

Technical Details for CVE-2026-53713

Vulnerability Analysis

Envoy Gateway ships a Lua validator that inspects user-supplied Lua submitted through EnvoyExtensionPolicy. The validator enforces a Strict policy by blocking access to sensitive paths such as /var/run/secrets, /certs, and /sys. The to_absolute_normalized_path helper in internal/gatewayapi/luavalidator/security.lua produces the absolute form of a requested path but does not collapse redundant separators. As a result, the is_critical_path check compares a non-canonical string against its blocklist and misses variants such as //var/run/secrets/kubernetes.io/serviceaccount/token. Because the Linux kernel resolves //path and /path to the same inode, the Lua runtime in the controller pod opens the file even though the validator approved it. The controller pod typically holds a mounted service-account token, cluster TLS material, and environment variables containing xDS credentials, which are read and returned to the attacker.

Root Cause

The root cause is improper input validation [CWE-20]. Path canonicalization inside the validator was incomplete: the code checked whether the supplied path started with a critical prefix but did not first normalize repeated / characters. The blocklist and the filesystem interpret paths differently, creating a parser differential between the validator and the Lua io library.

Attack Vector

An authenticated user with permission to create or modify EnvoyExtensionPolicy resources submits a Lua snippet that opens a doubly-prefixed path. The Envoy Gateway control plane accepts the policy, and the Lua executes inside the gateway controller pod, returning file contents to a location the attacker can observe. Stolen Kubernetes service-account tokens can then be used to pivot to the Kubernetes API Server or to the Envoy xDS control plane.

text

     "/sys",
     "/certs",
     "/var/run/secrets",
+    -- "/var/run" is a symlink to "/run" on Debian-derived (distroless) images.
+    "/run/secrets",
 }

-- ============================================================================
// Source: https://github.com/envoyproxy/gateway/commit/5a78db82b7cf4fc5bebbeda2c50952892038a464

The patch expands the critical-path blocklist to also include /run/secrets, closing the symlink-based variant on Debian-derived distroless images used by the controller.

Detection Methods for CVE-2026-53713

Indicators of Compromise

EnvoyExtensionPolicy resources containing Lua that references paths beginning with //, ///, or symlinked prefixes such as /run/secrets/
Unexpected reads of /var/run/secrets/kubernetes.io/serviceaccount/token originating from the Envoy Gateway controller pod
Kubernetes API Server audit entries showing the gateway controller service account performing reconnaissance calls such as list secrets or get configmaps in namespaces it does not normally touch

Detection Strategies

Inspect all EnvoyExtensionPolicy manifests for Lua that calls io.open, io.lines, or require against absolute paths, and flag any path containing repeated separators
Enable Kubernetes audit logging on EnvoyExtensionPolicy create and update events and alert on new submitters or unusually large Lua payloads
Compare the running Envoy Gateway image tag against 1.7.4 and 1.8.1 in cluster inventory to identify unpatched controllers

Monitoring Recommendations

Forward Kubernetes API audit logs and Envoy Gateway controller logs to a centralized analytics store and correlate policy changes with subsequent secret-access activity
Alert on service-account token use from IP addresses outside the cluster CIDR, which would indicate an exfiltrated token being replayed
Track outbound connections from the gateway controller pod that deviate from its baseline xDS and Kubernetes API destinations

How to Mitigate CVE-2026-53713

Immediate Actions Required

Upgrade Envoy Gateway to 1.7.4 or 1.8.1 in every cluster running the controller
Rotate the Envoy Gateway controller service-account token and any TLS material or xDS credentials mounted into the controller pod
Restrict RBAC on EnvoyExtensionPolicy so that only trusted platform operators can create or modify policies with Lua bodies
Review Kubernetes audit logs for prior EnvoyExtensionPolicy submissions containing Lua and treat suspicious entries as potential compromise

Patch Information

The fix is delivered in Envoy Gateway v1.7.4 and Envoy Gateway v1.8.1. The changes are tracked in Pull Request #9171, Pull Request #9172, and Pull Request #9173, corresponding to commits 5a78db8, 96e2b75, and b473718. The patches extend the critical-path blocklist in security.lua and tighten backend namespace validation in route.go.

Workarounds

Disable acceptance of Lua bodies in EnvoyExtensionPolicy until the controller is upgraded by using an admission controller such as Kyverno or OPA Gatekeeper to reject policies with Lua fields
Apply a NetworkPolicy that blocks egress from the Envoy Gateway controller pod to any destination other than the Kubernetes API Server and configured xDS endpoints
Mount service-account tokens with automountServiceAccountToken: false where feasible and use bound, short-lived projected tokens with narrow RBAC

bash

# Verify the running Envoy Gateway version and enforce a minimum patched release
kubectl -n envoy-gateway-system get deploy envoy-gateway \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

# Upgrade via Helm to a patched release
helm repo update
helm upgrade envoy-gateway oci://docker.io/envoyproxy/gateway-helm \
  --version v1.8.1 \
  -n envoy-gateway-system

# Restrict who can submit EnvoyExtensionPolicy resources
kubectl create clusterrole eep-editor \
  --verb=create,update,patch,delete \
  --resource=envoyextensionpolicies.gateway.envoyproxy.io