CVE-2026-22039: How an admission controller vulnerability turned Kubernetes namespaces into a security illusion

# CVE-2026-22039: How an admission controller vulnerability turned Kubernetes namespaces into a security illusion ## What started the discussion Just saw this nasty Kyverno CVE that's a perfect example of why I'm skeptical of admission controllers with god-mode RBAC. CVE-2026-22039 lets any user with namespaced Policy perms exfiltrate data from ANY namespace by abusing api Call variable substitution. Attacker creates a policy in their restricted namespace, triggers it with annotations pointing to kube-system resources, and boom- Kyverno's cluster-admin SA does the dirty work for them. Fixed in 1.16.3/1.15.3 but this highlights how these security tools can become the biggest attack vector. ## What stood out in the comments ### Discussion point 1 This doesn't really seem to be any better or worse than any of the million snippet annotation CVEs that have hit ingress-nginx over the last few years. ### Discussion point 2 I mean... Yeah? You should always be conscientious of the power an application has. The kyverno docs have all sorts of caveats on how mismanaging the install can lock your cluster, block important user pieces, etc. Kyverno is a fantastic tool imo ### Discussion point 3 In fairness, this sort of problem has existed forever across any technology that needs high-level privileges. At the end of the day, though, the amount of junk and problems that Kyverno has probably caught and prevented likely far outweighs this one CVE and while I haven't read the CVE, the description you provide seems to imply that an attacker would need to have access to a namespace to begin with. That shaves down the attack surface and likelihood A LOT. As with so many things, it's about threat model. I'm certainly not saying that god-mode SA's and admission controllers should just be _permitted_ no matter what, and that the developers of those should really work to limit required security (just like anyone else following least privilege), but understanding what it means for your cluster(s) is a big part of this. ### Discussion point 4 I did some dev work on Kyverno a couple years back and the source code was a dumpster fire. ### Discussion point 5 Namespaces are not security boundaries and never have been. Tools like vCluster 'isolate' independent virtual clusters via namespace, but you have to enable network policies explicitly to gain true east-west network isolation. Further, in the default worker node model (shared/host), you still have all the container-escape, noisy neighbor, lateral movement concerns you always had, so PSA becomes even more critical. It's getting easier/better with tools like vCluster but, even so, multitenancy accomplished exclusively via Kubernetes has always been a complex problem and challenge for platform teams and will likely continue to be. As with so many other security concerns, folks will always point to the fact that Kubernetes wasn't designed with a lot of this in mind, and it's taken SIGs, OSS community involvement, and concerned organizations to drive innovation in this area. ## Thread snapshot - Original subreddit: r/kubernetes - Original author: u/RemmeM89 - Reddit score: 79 - Comment count: 24 - Original thread: https://www.reddit.com/r/kubernetes/comments/1r44yxo/cve202622039_how_an_admission_controller/