GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: spoofed internal labels let a namespaced tenant clone Secrets out of restricted namespaces

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

Impact

The Generation Handler trusts the internal generate.kyverno.io labels on a resource instead of verifying who set them. A user who can create or update a ConfigMap in their own namespace can label it as Kyverno-managed with crafted policy, rule and trigger labels, causing the background controller - which holds broad cluster permissions - to run a synchronized generate policy on the attacker's behalf and clone Secrets out of namespaces the attacker cannot read into one they control. On a multi-tenant GPU cluster this is a direct path from a tenant namespace to the platform's registry pull secrets, cloud credentials and model-store tokens, carried out by a trusted controller so it looks like normal Kyverno activity in the audit log.

Who can reach it

Any authenticated user or service account with create/update rights on an ordinary resource such as a ConfigMap in a single namespace. No cluster-level permission needed; the privileged work is done by Kyverno's background-controller ServiceAccount.

What to do

Upgrade Kyverno to 1.19.2 or later - a controller image bump and rollout of the Kyverno Deployments, no node drain and no GPU workload disruption. Until then, review synchronized generate policies that clone Secrets and scope their source namespaces narrowly. Audit for ConfigMaps carrying generate.kyverno.io labels that no policy should have created, and rotate any Secret a generate policy could have copied.

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.