GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: namespaced mutating policy can fabricate cross-namespace targets and overwrite cluster-wide resources

CVSS 9.4CVE-2026-122303Container, Kubernetes & orchestrationcurated

Impact

In Kyverno 1.17.0 through 1.19.1, a NamespacedMutatingPolicy using mutate-existing can return a CEL map literal from targetMatchConstraints.expression that fabricates a target with an attacker-chosen metadata.namespace. The privileged background controller then applies the mutation there, so a tenant confined to one namespace can overwrite Secrets, Deployments or policies anywhere in the cluster. On a shared GPU cluster that is a direct tenant-to-tenant and tenant-to-platform break: rewrite another tenant's workload spec, replace image pull or registry secrets, or neuter the admission policies that keep privileged GPU pods in check. Kyverno itself is the control that operators rely on to constrain device access, so the failure is in the enforcement layer.

Who can reach it

Any tenant with permission to create a NamespacedMutatingPolicy in a namespace they own; authenticated, no cluster-level rights needed.

What to do

Upgrade Kyverno to 1.19.2 and roll the admission and background controller deployments; no node drain or reboot required. Until then, remove the RBAC that lets tenants create NamespacedMutatingPolicy objects and audit existing namespaced mutating policies for targetMatchConstraints expressions returning fabricated namespaces.

References

Related entries

All Container, Kubernetes & orchestration entries

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.