CVE-2026-122320 in Kyverno
Summary
by MITRE • 11/05/2026
Kyverno before 1.19.2 contains a missing authorization vulnerability that allows namespaced Policy authors to read resources in other namespaces by templating generate.clone or cloneList namespace values. Attackers can annotate a triggering ConfigMap so the background-controller copies a victim namespace's sensitive ConfigMap into the attacker's namespace, enabling cross-tenant data disclosure.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Kyverno versions prior to 1.19.2 represents a critical failure in access control mechanisms within Kubernetes admission controllers and policy engines. Specifically, this flaw stems from an improper implementation of authorization checks when processing generate.clone or cloneList policies that utilize namespace templating features. In standard Kubernetes operations, RBAC (Role-Based Access Control) ensures that subjects can only interact with resources they are explicitly permitted to access. However, Kyverno's background controller, which handles the asynchronous application and maintenance of cluster-wide policies, failed to enforce these boundaries when cloning resources across namespaces based on dynamic namespace values derived from triggering events. This architectural oversight allows a user or service account with permissions limited to their own namespace to exploit policy generation rules to bypass isolation constraints.
The technical mechanism of this exploitation relies on the ability of namespaced Policy authors to define generate policies that clone existing ConfigMaps, Secrets, or other sensitive resources into different namespaces. By annotating a triggering resource within their controlled namespace, an attacker can instruct Kyverno's background controller to copy a target resource from a victim namespace into the attacker's own namespace. The vulnerability arises because the authorization check performed during this cloning operation does not adequately verify whether the actor initiating the policy has read access to the source resource in its original location. Consequently, the system proceeds with the data transfer regardless of the lack of explicit permissions for cross-namespace reading operations. This effectively circumvents the intended multi-tenant isolation boundaries that are fundamental to secure Kubernetes deployments.
The operational impact of this vulnerability is severe, particularly in shared or multi-tenant environments where strict separation between workloads and namespaces is required. Attackers can leverage this flaw to perform unauthorized data exfiltration by reading sensitive configuration files, credentials stored in ConfigMaps, or other non-secret but confidential information residing in adjacent namespaces. This leads directly to cross-tenant data disclosure, compromising the confidentiality of services running on the cluster. In a cloud-native context where microservices often rely on shared infrastructure with varying levels of trust, such unauthorized access can serve as an initial foothold for further lateral movement or privilege escalation attacks within the cluster environment.
From a classification perspective, this vulnerability aligns with CWE-269, which denotes Improper Privilege Management, specifically regarding the failure to enforce proper authorization checks before performing sensitive operations. It also maps to MITRE ATT&CK techniques related to Data from Information Repositories and potentially T1530 if used in conjunction with other tools for exfiltration. The flaw highlights a broader category of issues where policy engines execute actions based on user-defined templates without sufficiently validating the underlying permissions required for those template expansions, particularly when cross-boundary operations are involved.
To mitigate this risk, organizations running Kyverno must upgrade to version 1.19.2 or later immediately, as these versions include patches that enforce stricter authorization checks during resource cloning operations. Administrators should also audit existing generate policies to ensure they do not rely on namespace templating features that could be exploited for cross-namespace data access unless absolutely necessary and properly secured with additional RBAC constraints. Implementing network policies and strict Pod Security Standards can further limit the blast radius of any compromised service account, reducing the potential impact if similar vulnerabilities are discovered in other components of the Kubernetes ecosystem. Regular review of policy definitions against least privilege principles is essential to maintain robust security posture in dynamic container orchestration environments.