CVE-2026-122304 in Kyverno
Summary
by MITRE • 11/05/2026
Kyverno from 1.17.0 before 1.19.2 contains an authorization bypass vulnerability that allows namespace admins to escape namespace confinement because the cleanup controller builds its context loader with a nil policy. Attackers can create a namespaced CleanupPolicy with apiCall or globalReference context entries to read cross-namespace Secrets and modify validatingwebhookconfigurations using the cleanup controller's ServiceAccount.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Kyverno versions prior to 1.19.2 represents a critical authorization bypass within the Kubernetes admission control ecosystem, specifically affecting the namespace confinement guarantees provided by cluster administrators. Kyverno is widely deployed as an open-source policy engine that enforces security and compliance policies on Kubernetes clusters. The core issue lies in the implementation of its cleanup controller, which is responsible for managing resources associated with CleanupPolicy objects. In versions from 1.17.0 up to but not including 1.19.2, this controller constructs its context loader using a nil policy object under certain conditions. This technical flaw fundamentally breaks the isolation boundaries that are supposed to restrict actions to specific namespaces, allowing any user or service account with permissions to create namespaced CleanupPolicy objects to escalate privileges and access resources outside their designated namespace scope.
From an operational perspective, this vulnerability enables attackers who have been granted administrative rights within a single Kubernetes namespace to perform actions that should be strictly prohibited by cluster-level security policies. By exploiting the nil policy context in the cleanup controller, malicious actors can craft specific CleanupPolicy configurations containing apiCall or globalReference context entries. These entries allow the attacker to leverage the high-privilege ServiceAccount associated with the Kyverno cleanup controller itself. Consequently, an attacker can read sensitive data such as Secrets stored in other namespaces that are typically inaccessible due to RBAC restrictions. Furthermore, they can modify validatingwebhookconfigurations across the cluster, which effectively allows them to disable or manipulate admission controls for any namespace, thereby undermining the entire security posture of the Kubernetes environment and potentially leading to full cluster compromise if not detected and remediated promptly.
This vulnerability aligns with CWE-269, Improper Privilege Management, as it involves a failure in enforcing least privilege principles by allowing lower-level permissions to execute high-level operations through an unintended code path. Additionally, from the perspective of the MITRE ATT&CK framework for Kubernetes, this behavior corresponds to T1530, Data from Cloud Storage Object, and potentially T1484, Domain Policy Modification, depending on whether the attacker primarily targets secrets or webhook configurations. The exploitation chain relies heavily on the abuse of legitimate administrative tools, making it difficult to detect through standard monitoring unless specific behavioral analytics are in place.
To mitigate this risk, organizations running Kyverno must immediately upgrade to version 1.19.2 or later, where the cleanup controller has been patched to correctly handle policy contexts and enforce namespace boundaries as intended. In environments where immediate upgrading is not feasible due to operational constraints, administrators should restrict permissions for creating CleanupPolicy objects to only those users who require such privileges at the cluster level rather than the namespace level. Additionally, implementing strict RBAC policies that limit access to global resources like validatingwebhookconfigurations and cross-namespace Secret reads can help contain potential damage. Continuous monitoring of Kyverno controller logs for unusual apiCall or globalReference activities should also be enforced to detect any attempted exploitation in real-time.