CVE-2026-22039 in Kyverno
Summary
by MITRE • 01/27/2026
Kyverno is a policy engine designed for cloud native platform engineering teams. Versions prior to 1.16.3 and 1.15.3 have a critical authorization boundary bypass in namespaced Kyverno Policy apiCall. The resolved `urlPath` is executed using the Kyverno admission controller ServiceAccount, with no enforcement that the request is limited to the policy’s namespace. As a result, any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno’s admission controller identity, targeting any API path allowed by that ServiceAccount’s RBAC. This breaks namespace isolation by enabling cross-namespace reads (for example, ConfigMaps and, where permitted, Secrets) and allows cluster-scoped or cross-namespace writes (for example, creating ClusterPolicies) by controlling the urlPath through context variable substitution. Versions 1.16.3 and 1.15.3 contain a patch for the vulnerability.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 04/25/2026
The vulnerability described in CVE-2026-22039 represents a critical authorization boundary bypass in Kyverno policy engine versions prior to 1.16.3 and 1.15.3. This flaw specifically affects the namespaced Kyverno Policy apiCall functionality, where the system fails to properly validate that API requests are confined to the policy's namespace. The vulnerability stems from how Kyverno processes the resolved urlPath parameter within its admission controller, which operates under the identity of the Kyverno admission controller ServiceAccount. This architectural weakness allows attackers to exploit the system's trust in the ServiceAccount's permissions without proper namespace boundary enforcement.
The technical implementation of this vulnerability occurs when authenticated users with permissions to create namespaced policies manipulate the urlPath parameter through context variable substitution. The system executes these requests using Kyverno's privileged admission controller ServiceAccount, which typically has extensive RBAC permissions within the cluster. This misconfiguration enables attackers to perform Kubernetes API operations that extend far beyond the intended namespace boundaries. The vulnerability specifically targets the namespace isolation mechanism that should prevent cross-namespace access patterns, allowing unauthorized access to sensitive resources such as ConfigMaps and potentially Secrets where permitted by the ServiceAccount's role-based access controls.
The operational impact of this vulnerability is severe and multifaceted, encompassing both read and write capabilities across namespace boundaries. Attackers can perform cross-namespace reads to access sensitive configuration data and potentially credentials stored in ConfigMaps or Secrets, undermining the fundamental security principle of namespace isolation. Additionally, the vulnerability enables cluster-scoped or cross-namespace write operations, including the creation of ClusterPolicies that can modify cluster-wide configurations and access control rules. This capability allows attackers to escalate their privileges and potentially compromise the entire Kubernetes cluster. The vulnerability's classification as critical aligns with CWE-284 (Improper Access Control) and represents a direct violation of the principle of least privilege that should govern all Kubernetes access patterns.
This vulnerability directly maps to ATT&CK technique T1078.004 (Cloud Infrastructure Access) and T1566.001 (Phishing via Service) as it enables unauthorized access to cloud infrastructure resources through compromised Kubernetes policies. The attack vector leverages legitimate authentication mechanisms to execute unauthorized API operations, making detection particularly challenging. Organizations should immediately upgrade to Kyverno versions 1.16.3 or 1.15.3 to remediate this vulnerability, as the patch addresses the core authorization enforcement issue. Security teams should also implement additional monitoring for unusual apiCall patterns and namespace boundary violations, particularly focusing on requests that attempt to access resources outside of expected policy scopes. The vulnerability highlights the critical importance of proper authorization enforcement in cloud-native environments and the necessity of validating all request parameters against namespace boundaries, especially when operating under privileged identities.