CVE-2026-100707 in Kyverno
Summary
by MITRE • 09/26/2026
Kyverno before 1.19.1 contains a namespace isolation bypass in the apiCall context entry of namespaced Policy resources due to inconsistent path interpretation between validation and execution. A low-privilege tenant can use percent-encoded dot-segments in urlPath to bypass namespace checks and read resources from other namespaces using the Kyverno admission controller's ServiceAccount credentials.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in versions of Kyverno prior to 1.19.1 represents a critical security flaw within the apiCall context entry mechanism used by namespaced Policy resources. This issue stems from an inconsistency in how path segments are interpreted during different phases of policy evaluation, specifically between validation and execution stages. In Kubernetes environments, namespace isolation is a fundamental tenet for multi-tenant architectures, ensuring that workloads and policies operating within one logical boundary cannot inadvertently or maliciously access resources belonging to another tenant. Kyverno relies on these boundaries to enforce security policies securely, but the flaw in path interpretation undermines this trust model by allowing attackers to manipulate URL paths in ways that bypass namespace restrictions.
At a technical level, the vulnerability exploits the handling of percent-encoded dot-segments within the urlPath parameter used for apiCall operations. When a policy resource is defined as namespaced, it should theoretically be restricted to interacting only with resources within its own namespace or those explicitly permitted by cluster-wide policies. However, due to inconsistent parsing logic between validation and execution phases, an attacker can craft requests containing percent-encoded sequences that represent directory traversal patterns, such as encoded dots and slashes. These sequences are not normalized consistently across the codebase, leading to a scenario where the system validates one path structure but executes against a different, potentially deeper or cross-namespace path. This discrepancy allows the request to escape its intended namespace scope without triggering standard validation failures that would normally block unauthorized access attempts.
The operational impact of this vulnerability is severe for organizations utilizing Kyverno in multi-tenant Kubernetes clusters. A low-privilege tenant, who typically has limited permissions within their own namespace, can leverage this flaw to read sensitive resources from other namespaces. Because the apiCall context entry utilizes the ServiceAccount credentials associated with the Kyverno admission controller, the attacker effectively gains elevated privileges equivalent to those of the service account itself. This means that data considered confidential or restricted to specific teams or projects becomes accessible to unauthorized users. The ability to exfiltrate secrets, configuration maps, or other sensitive metadata from across the cluster compromises the entire security posture of the environment and violates principles of least privilege and separation of duties.
This vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure in enforcing proper restrictions on authorized access to specific data objects. Furthermore, it maps directly to MITRE ATT&CK technique T1078 Valid Accounts, specifically the sub-technique involving cloud accounts or service account impersonation, where an attacker uses legitimate credentials obtained through privilege escalation or misconfiguration to move laterally and gather intelligence within the environment. The exploitation of percent-encoded path traversal is also reminiscent of CWE-20 Improper Input Validation, highlighting a failure in sanitizing user-supplied input before processing it against system resources.
To mitigate this risk, organizations running Kyverno versions prior to 1.19.1 must upgrade immediately to version 1.19.1 or later, where the path interpretation logic has been corrected to ensure consistency between validation and execution phases. Until an upgrade is feasible, administrators should review existing namespaced policies for any use of apiCall context entries with dynamic urlPath parameters that rely on tenant-supplied input. It is advisable to restrict such inputs strictly to known safe values or disable the specific policy rules if they are not essential for current operations. Additionally, implementing strict network policies and monitoring logs for unusual access patterns involving service accounts can help detect potential exploitation attempts in real-time while remediation efforts are underway.