CVE-2026-22771: 
NixOS vulnerability analysis and mitigation

CVE-2026-22771 is a code injection vulnerability in Envoy Gateway that allows low-privileged attackers to execute arbitrary Lua scripts via the EnvoyExtensionPolicy resource, leading to credential leakage and arbitrary code execution. It affects all Envoy Gateway versions prior to 1.5.7 and versions 1.6.0 through 1.6.1 (prior to 1.6.2). The vulnerability was published on January 12, 2026, and patched versions were released the same day. It carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Envoy Security Advisory).

The root cause is improper control of code generation (CWE-94), combined with improper input validation (CWE-20) and injection (CWE-74), in how Envoy Gateway handles Lua scripts submitted via EnvoyExtensionPolicy resources. Lua scripts are executed in two contexts: by the Envoy proxy when processing traffic, and by the Envoy Gateway controller pod during validation — neither context enforced sufficient sandboxing or security guardrails prior to the fix. An attacker with low privileges (e.g., Kubernetes RBAC permission to create EnvoyExtensionPolicy resources) can craft a malicious Lua script that reads sensitive files such as /certs/tls.key, /certs/tls.crt, or /var/run/secrets/kubernetes.io/serviceaccount/token and exfiltrates them via HTTP response bodies or error messages surfaced in resource status fields. Public PoC payloads demonstrating both TLS certificate leakage and Kubernetes service account token extraction are included in the official advisory (Envoy Security Advisory, GitHub Advisory).

Successful exploitation enables an attacker to extract the Envoy proxy's XDS client certificates (TLS private keys and certificates) and Kubernetes service account tokens, granting access to the control plane and all secrets managed by Envoy proxy. With the stolen service account token, an attacker can escalate privileges to run arbitrary pods in the envoy-gateway-system namespace, steal additional Kubernetes secrets, and even delete Envoy Gateway itself — resulting in full compromise of the proxy infrastructure and potential disruption of all downstream and upstream communications (Envoy Security Advisory).

A proof-of-concept exploit is publicly available in the official GitHub security advisory, demonstrating both credential leakage and service account token extraction techniques (Envoy Security Advisory). Exploitation requires low privileges (ability to create EnvoyExtensionPolicy resources via Kubernetes RBAC) and network access, with low attack complexity and no user interaction required. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.155% (0.004% per GitHub Advisory), indicating a low but non-negligible probability of exploitation in the near term (GitHub Advisory).

1. Reconnaissance: Identify Envoy Gateway deployments running versions prior to 1.5.7 or between 1.6.0 and 1.6.1 in a Kubernetes cluster. Determine if the attacker has or can obtain Kubernetes RBAC permissions to create EnvoyExtensionPolicy resources in any namespace.
2. Craft malicious EnvoyExtensionPolicy: Create a YAML manifest for an EnvoyExtensionPolicy resource with an inline Lua script targeting sensitive files. For TLS credential leakage, the script reads /certs/tls.crt and /certs/tls.key and injects the content into HTTP response bodies. For service account token leakage, the script reads /var/run/secrets/kubernetes.io/serviceaccount/token and triggers an error that surfaces the token in the resource's status field.
3. Apply the policy: Use kubectl apply -f malicious-policy.yaml to deploy the EnvoyExtensionPolicy targeting an existing HTTPRoute or Gateway resource within scope.
4. Trigger execution: Send HTTP requests through the affected route to cause Envoy proxy to execute the Lua script, or wait for the Envoy Gateway controller to validate the script (which also executes it), leaking the service account token in the resource status.
5. Retrieve credentials: Read the leaked TLS keys from HTTP responses or retrieve the Kubernetes service account token from kubectl describe envoyextensionpolicy lua-leak.
6. Escalate privileges: Use the stolen Kubernetes service account token to authenticate to the Kubernetes API server, enumerate and steal secrets in the envoy-gateway-system namespace, deploy arbitrary pods, or delete Envoy Gateway resources (Envoy Security Advisory, GitHub Advisory).

• Kubernetes Resources: Unexpected EnvoyExtensionPolicy resources in any namespace containing inline Lua scripts with file I/O operations (e.g., io.open, references to /certs/, /var/run/secrets/).
• Logs: Envoy Gateway controller logs showing Lua validation errors containing sensitive content (tokens, certificate data) in error messages; entries referencing envoy_on_response with file read operations.
• Resource Status: EnvoyExtensionPolicy status conditions containing error messages with embedded Kubernetes service account tokens or certificate material (visible via kubectl describe envoyextensionpolicy).
• Network: Unusual HTTP responses from Envoy proxy containing PEM-formatted certificate/key data or JWT-formatted tokens in response bodies; unexpected outbound connections from Envoy proxy pods to external IPs.
• Kubernetes API: Unexpected API calls using the Envoy Gateway service account token from unfamiliar source IPs; new pods created in the envoy-gateway-system namespace by non-standard service accounts (Envoy Security Advisory).

Upgrade Envoy Gateway to version 1.5.7 (for the 1.5.x branch) or 1.6.2 (for the 1.6.x branch) immediately. The patch enforces Lua Strict validation by default with a security hardening module that blocks dangerous Lua code, renames the previous permissive mode to InsecureSyntax, and introduces a new disableLua option in EnvoyProxy to reject all EnvoyExtensionPolicy resources containing Lua scripts. As a workaround prior to patching, restrict Kubernetes RBAC permissions so that only trusted namespaces and users can create EnvoyExtensionPolicy resources; note this restriction applies to all extensibility options (Lua, Wasm, Ext-Proc). Additionally, implement network segmentation to limit control plane access and monitor access logs for suspicious credential usage (Envoy Security Advisory, GitHub Advisory).

The vulnerability was credited to researchers rikatz and guydc as finders, with rudrakhp as the remediation developer and arkodg as the remediation reviewer, indicating coordinated disclosure within the Envoy project community (Envoy Security Advisory). The Hacker Wire covered the disclosure with a dedicated article on the credential leak mechanism, and the vulnerability was shared on Bluesky and Mastodon by security community accounts shortly after publication (The Hacker Wire). Red Hat also acknowledged the vulnerability in their security advisory tracker (Red Hat CVE).