CVE-2026-122310 in Kyverno
Summary
by MITRE • 11/05/2026
Kyverno from 1.19.1 before 1.19.2 validates a Policy's context.apiCall urlPath after cleaning it but executes the raw path, whose fragment or query the Kubernetes client discards. A namespace-scoped user who can create a Policy can hide ../ segments behind # or ? to reach cluster-scoped endpoints with Kyverno's ServiceAccount, gaining cluster admin.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Kyverno versions prior to 1.19.2 represents a critical path traversal and authorization bypass flaw rooted in the inconsistent handling of Uniform Resource Identifier components during API call validation. Specifically, when processing external context data within policies, the system performs sanitization checks on the urlPath parameter intended to prevent access to unauthorized cluster-scoped resources. However, this validation logic operates only on the cleaned or normalized version of the path string. The actual HTTP request execution subsequently utilizes the raw, unmodified input provided by the user. This discrepancy creates a significant security gap because standard Kubernetes client libraries and underlying web frameworks typically discard fragment identifiers (the portion following a hash symbol) and query parameters (the portion following a question mark) when resolving resource paths for authorization checks against the API server.
An attacker with namespace-scoped privileges who possesses the ability to create or modify Kyverno policies can exploit this inconsistency by embedding directory traversal sequences, such as ../ segments, within either the fragment or query string of the urlPath field. Because the validation step cleans and analyzes a version of the path that may strip these components, it incorrectly determines that the request is targeting only namespace-scoped resources. Consequently, the policy is approved for execution. When Kyverno proceeds to execute the API call using its own ServiceAccount credentials, which typically hold cluster-admin privileges or elevated permissions necessary for fetching external context data, the Kubernetes client processes the raw input. The fragment and query components are stripped by the HTTP layer before reaching the authorization engine of the Kubernetes API server, effectively masking the traversal intent from the security controls while still allowing the underlying file system or resource path resolution to traverse directories upward.
The operational impact of this vulnerability is severe, as it allows a low-privileged user in any namespace to escalate privileges to cluster-admin level. By leveraging Kyverno's ServiceAccount context, the attacker can read sensitive secrets across all namespaces, modify critical cluster configurations, and potentially deploy malicious workloads with full administrative rights. This undermines the fundamental isolation guarantees of Kubernetes multi-tenancy models where users are expected to be confined to their designated namespaces unless explicitly granted broader permissions through Role-Based Access Control policies that this exploit circumvents. The flaw effectively neutralizes namespace-level restrictions by exploiting the trust placed in Kyverno's internal service account, turning a policy management tool into a vector for complete cluster compromise.
Mitigation strategies must prioritize immediate version upgrades to Kyverno 1.19.2 or later where this logic has been corrected to ensure that validation and execution operate on identical representations of the path data. In environments where upgrading is not immediately feasible, administrators should restrict the ability to create policies with external context calls to trusted users only. Additionally, implementing network-level controls such as Kubernetes NetworkPolicies can limit outbound traffic from Kyverno pods to known legitimate endpoints, reducing the attack surface for arbitrary URL resolution. Security teams should also audit existing policy definitions for any use of urlPath parameters in external contexts and remove or sanitize them if they originate from untrusted sources. This incident highlights the importance of ensuring that input validation logic mirrors exactly how downstream libraries process data, particularly regarding standard URI component parsing behaviors defined by RFC 3986.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-745 Incorrect Deference of Reference to Sensitive Resource. The exploitation technique involves manipulating input parameters to bypass access controls, which maps directly to the ATT&CK tactic of Privilege Escalation via Tactic TA0004 specifically utilizing techniques related to resource hijacking or service account abuse. Understanding this mechanism is crucial for defenders monitoring Kyverno deployments, as traditional log analysis might not immediately reveal the traversal attempt if only the final resolved path is logged without correlating it with the original policy definition inputs. Continuous monitoring of API server logs for unexpected access patterns from Kyverno ServiceAccounts can provide early detection indicators for such exploitation attempts in unpatched environments.