GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: namespaced mutating policy can generate resources into any namespace

CVE-2026-54523Container, Kubernetes & orchestrationcurated

Impact

A user who can create NamespacedMutatingPolicy objects in a single namespace can make the Kyverno admission controller - which runs with cluster-wide privileges - create ConfigMaps, Secrets, NetworkPolicies and RoleBindings in namespaces they have no rights over. On a multi-tenant GPU cluster where Kyverno is the thing enforcing tenant separation, this turns the policy engine into a privilege-escalation path: a tenant with a namespace of their own can plant a RoleBinding elsewhere and reach other tenants' workloads and credentials. It also lets an attacker rewrite NetworkPolicies that fence tenant traffic off the storage and fabric networks. Scope is changed (CVSS S:C) precisely because the controller's authority, not the caller's, is what applies the change.

Who can reach it

Any authenticated cluster user with RBAC to create NamespacedMutatingPolicy objects in at least one namespace - typically a tenant namespace admin. No cluster-level rights needed, and no access to a node.

What to do

Upgrade Kyverno to 1.18.2; only 1.18.0 and 1.18.1 are affected. This is a control-plane component upgrade - roll the admission controller Deployment and let the pods restart. No node drain or reboot is involved, but plan for the brief admission gap while the webhook pods cycle, and check the failurePolicy of your webhooks so workload admission does not stall during the roll. Until upgraded, restrict who can create NamespacedMutatingPolicy via RBAC.

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.