CVE-2026-122311 in Kyverno
Summary
by MITRE • 11/05/2026
Kyverno from 1.16.0 before 1.19.2 fails to validate path segments in the resource argument of resource.get() and resource.post(), allowing namespaced CEL policies to escape their namespace. Tenants who can create a NamespacedValidatingPolicy can insert .. segments to read and write arbitrary cluster objects using the admission controller's ServiceAccount, leading to cluster takeover.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Kyverno versions prior to 1.19.2 represents a critical security flaw within the policy engine’s handling of resource arguments for CEL-based policies. Specifically, the functions resource.get() and resource.post(), which are designed to facilitate interactions with Kubernetes resources during admission control evaluation, fail to properly sanitize or validate path segments provided in their input parameters. This lack of rigorous validation allows attackers who possess the ability to create NamespacedValidatingPolicy objects to manipulate these arguments by inserting directory traversal sequences such as double dots (..). By exploiting this mechanism, a tenant can effectively bypass namespace isolation boundaries that are typically enforced by Kubernetes RBAC and Kyverno’s own scoping rules.
From a technical perspective, the core issue lies in how the admission controller processes the resource path constructed from user-supplied input within CEL expressions. When a policy is evaluated, the engine constructs API calls to interact with cluster resources based on these paths. Because the validation logic does not adequately check for relative path components that could resolve outside the intended namespace context, an attacker can craft a malicious policy where the resource argument points to arbitrary objects across the entire cluster rather than being restricted to the namespace in which the policy is defined. This effectively neutralizes the multi-tenancy guarantees provided by Kubernetes namespaces when combined with Kyverno’s admission control capabilities.
The operational impact of this vulnerability is severe, leading directly to a complete cluster takeover scenario. Since Kyverno policies are executed using the privileges of the ServiceAccount associated with the Kyverno controller or webhook, an attacker who successfully exploits this flaw can read and write any resource in the cluster regardless of its namespace. This includes sensitive configurations such as secrets, service accounts, role bindings, and deployment manifests. An adversary could escalate their privileges by creating new ClusterRoleBindings that grant them admin access to all namespaces, exfiltrate confidential data stored in Secrets across the entire infrastructure, or deploy malicious workloads with elevated permissions. The ability to write arbitrary cluster objects means an attacker can persistently maintain control over the environment even if initial entry points are patched.
This vulnerability aligns closely with CWE-20 Improper Input Validation and CWE-749 Exposed Dangerous Method for Unrestricted Access, as it involves a failure to restrict access to a dangerous API function based on user input. In terms of MITRE ATT&CK mapping, this exploit technique corresponds to T1531 Account Access Removal or more accurately T1068 Exploitation for Privilege Escalation and potentially T1499 Endpoint Denial of Service if the attacker chooses to disrupt operations by modifying critical system resources. It also reflects aspects of T1528 Steal Application Access Token, as it leverages the identity of the Kyverno service account to perform unauthorized actions across namespace boundaries.
To mitigate this risk, organizations running Kyverno must immediately upgrade to version 1.19.2 or later, where the path segment validation logic has been hardened to prevent directory traversal attacks within resource arguments. In addition to upgrading, administrators should enforce strict RBAC policies that limit which users and service accounts are permitted to create NamespacedValidatingPolicy objects. Implementing admission control webhooks that inspect policy definitions for suspicious patterns before they are persisted can provide an additional layer of defense. Furthermore, adopting a principle of least privilege for the Kyverno controller’s ServiceAccount ensures that even if such a vulnerability is exploited in other contexts, the blast radius remains contained by restricting the permissions available to the execution context of the policies themselves.