Database/Container, Kubernetes & orchestration

Kyverno: NamespacedMutatingPolicy mutate-existing lets a tenant strip Pod Security labels cluster-wide

CVSS 8.4CVE-2026-122316Container, Kubernetes & orchestrationcurated

Impact

The mutate-existing background processor does not check that a NamespacedMutatingPolicy's targets lie inside its own namespace. A tenant who can create policies in their namespace can write CEL expressions targeting Namespace objects or resources in other namespaces, and the background-controller ServiceAccount will perform the write. The demonstrated effect is stripping Pod Security Admission labels cluster-wide, which removes the guardrail that stops privileged pods, hostPath mounts and host namespaces - exactly the primitives used to reach /dev/nvidia* devices, the container toolkit socket and other tenants' GPU workloads on a shared node. The flaw is a missing authorization check on an existing-resource mutation, distinct from the generate-handler label spoofing in CVE-2026-122308 and the verifyImages cache bypass in CVE-2026-122321.

Who can reach it

Any authenticated tenant with permission to create a NamespacedMutatingPolicy in a namespace they control. The privileged cross-namespace write is executed by Kyverno's background controller, not by the attacker's own credentials.

What to do

Upgrade Kyverno to 1.19.2 or later (affected from 1.17.0): image bump plus a rollout of the Kyverno controller Deployments, no node drain. In the meantime, remove tenant RBAC for NamespacedMutatingPolicy, and verify that Pod Security labels on your namespaces still match policy - re-apply them if a mutation has already removed them.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-122316 https://github.com/kyverno/kyverno/security/advisories/GHSA-vm98-8c25-h274 https://www.vulncheck.com/advisories/kyverno-1.17.0-before-1.19.2-cross-namespace-write-via-namespacedmutatingpolicy-mutateexisting

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.