CVE-2026-122312 in Kyverno
Summary
by MITRE • 11/05/2026
Kyverno from 1.19.1 before 1.19.2 contains a namespace isolation bypass in APICall Fetch() in pkg/engine/apicall/apiCall.go because path.Clean treats '?' as a path character, letting the namespace regex match segments inside the query string. Users who can create namespaced policies can supply a URLPath like /api/v1/nodes?x=/namespaces/default/ that passes validation while client-go requests the cluster-scoped endpoint, reading resources outside their namespace.
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 APICall Fetch functionality located in pkg/engine/apicall/apiCall.go. This issue stems from an improper handling of URL path components, specifically involving the Go standard library function path.Clean. In this context, path.Clean is utilized to normalize and validate user-supplied URLs before they are processed by the Kubernetes client-go library. The core technical flaw arises because path.Clean treats the question mark character as a valid segment within the path rather than recognizing it as the delimiter that separates the URL path from the query string parameters. This misinterpretation allows an attacker to embed namespace-specific paths directly into the query portion of a URL, thereby bypassing intended isolation mechanisms designed to restrict access based on namespaces.
The operational impact of this vulnerability is significant for environments where users are granted permissions to create namespaced policies within Kyverno. An adversary with such privileges can craft a malicious policy configuration that includes a carefully constructed URLPath parameter. By appending query string parameters containing namespace identifiers, such as /api/v1/nodes?x=/namespaces/default/, the input appears valid during the initial validation phase because path.Clean does not strip or correctly parse the segment following the question mark. Consequently, the Kyverno engine accepts this configuration as compliant with namespace isolation rules. However, when the underlying Kubernetes client-go library executes the request, it interprets the URL according to standard HTTP semantics where everything after the question mark is treated as a query parameter rather than part of the resource path. This discrepancy results in the API server receiving a request for a cluster-scoped endpoint, specifically /api/v1/nodes, which exists outside the scope of the user's designated namespace.
This bypass effectively allows users to read resources that they should not have access to under normal RBAC and Kyverno policy constraints. For instance, by targeting nodes or other cluster-level resources through this mechanism, an attacker can exfiltrate sensitive information about the cluster topology, node configurations, or potentially other data protected by namespace boundaries. This constitutes a clear violation of confidentiality principles as it enables unauthorized access to privileged API endpoints. The flaw highlights a subtle but dangerous edge case in how URL parsing functions interact with security validation logic, demonstrating that relying on standard library path cleaning without explicit query string separation can lead to severe isolation failures in multi-tenant Kubernetes environments.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-601 Open Redirect URL Redirection, as the core issue involves bypassing access controls through malformed input handling that leads to unintended resource access. In terms of the MITRE ATT&CK framework for Kubernetes, this behavior corresponds to T1537.002 Abuse Cloud Infrastructure APIs via Misconfigured Endpoints and potentially T1651 Client-Side Proxy Abuse if used in conjunction with other techniques to pivot through API calls. The attack vector is primarily local within the context of policy creation but results in remote code execution-like effects regarding data access across namespace boundaries.
To mitigate this vulnerability, organizations running Kyverno must upgrade immediately to version 1.19.2 or later where the path.Clean behavior has been corrected to properly distinguish between URL paths and query strings. Until an upgrade is feasible, administrators should enforce strict validation of policy inputs at the admission webhook level to reject any URLs containing question marks in unexpected positions or restrict the ability for lower-privileged users to create policies that utilize external API calls. Additionally, implementing network-level controls such as Kubernetes NetworkPolicies can help limit egress traffic from Kyverno pods to only necessary endpoints, reducing the blast radius if a policy is misconfigured. Regular auditing of created policies and monitoring for anomalous API requests originating from service accounts associated with Kyverno are also recommended defensive measures to detect potential exploitation attempts in real-time.