CVE-2026-122311 · Infrastructure
NO FIX YET · SEE WHAT TO DO
Kyverno versions from 1.16.0 before 1.19.2 do not validate path segments in the resource argument of resource.get() and resource.post() in CEL policies. A tenant allowed to create a NamespacedValidatingPolicy can use '..' segments to read and write arbitrary cluster objects through the admission controller's ServiceAccount, which the sources say leads to cluster takeover.
first public Oct 21, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Clusters running Kyverno from 1.16.0 before 1.19.2 where tenants can create NamespacedValidatingPolicy resources. The sources do not say whether ClusterValidatingPolicy or default installs are affected, so the exposure surface beyond namespaced policies is unknown. Teams that run Kyverno only with trusted administrators and no tenant policy creation are less exposed.
Not affected if kyverno-1.19.2-or-later, kyverno-below-1.16.0, no-tenant-policy-creation
Who cares kubernetes, kyverno, multi-tenant-clusters
kubectl get deployment -n kyverno kyverno-admission-controller -o jsonpath='{.spec.template.spec.containers[0].image}') and see whether it falls in 1.16.0 to before 1.19.2.kubectl auth can-i create namespacedvalidatingpolicies --namespace <tenant-ns>.1.19.2 or later (the sources state this as the fixed version).Kyverno from 1.16.0 before 1.19.2 fails to validate path segments in the resource argument of resource.get() and resource.post(), allowing namespaced CEL policies to escape their namespace. Tenants who can create a NamespacedValidatingPolicy can insert .. segments to read and write arbitrary cluster objects using the admission controller's ServiceAccount, leading to cluster takeover.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.