GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: generate rules are authorized against the controller's RBAC, not the policy author's

CVSS 9.3CVE-2026-122302Container, Kubernetes & orchestrationcurated

Impact

A namespace admin on a shared GPU cluster can author a namespaced Policy with generate rules that target other namespaces or cluster-scoped kinds. Because admission only verifies that the Kyverno background controller has permission, not that the author does, the controller then creates or clones those resources cluster-wide on the attacker's behalf - effectively lending out its own high privilege. On a multi-tenant GPU cluster this is a tenant-to-cluster escalation: the attacker can plant RBAC objects, service accounts or workloads in namespaces belonging to other tenants and schedule onto their GPUs. Kyverno sits in the admission path, so the component that is supposed to enforce tenancy is the one that breaks it.

Who can reach it

An authenticated tenant with rights to create Policy objects in a single namespace. No cluster-level permission and no node access needed; the Kubernetes API server is the only thing that has to be reachable.

What to do

Upgrade Kyverno to 1.19.2 or later per the GitHub advisory. This is a controller deployment rollout - restart of the Kyverno pods, no node drain and no GPU workload interruption, though admission is briefly unavailable during the rolling update so check the webhook failure policy before starting. Until the upgrade lands, restrict who can create Policy objects in tenant 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.