CVE-2025-15613 in Kyverno
Summary
by MITRE • 09/01/2026
Kyverno before v1.13.4 is vulnerable to server-side request forgery (SSRF) via its Service Call functionality. An attacker with permission to create Kyverno (Cluster)Policies can specify an external URL in a policy's apiCall/service configuration; although Service Call is documented for in-cluster services, it also resolves external addresses, allowing requests to an attacker-controlled server. Because policy context data (including contents of Kubernetes resources such as secrets) is sent in these requests, an attacker can exfiltrate sensitive cluster data.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in Kyverno versions prior to 1.13.4 represents a critical Server-Side Request Forgery flaw inherent to the Service Call functionality within its policy engine architecture. This security defect allows for unauthorized access and potential data exfiltration by exploiting the way Kyverno resolves URLs specified in ClusterPolicy or Policy resources. While the official documentation explicitly states that the Service Call feature is intended exclusively for interacting with internal cluster services, the underlying implementation fails to enforce this boundary constraint effectively. Consequently, when an attacker possesses the necessary permissions to create or modify policies within a namespace or at the cluster level, they can manipulate the apiCall configuration fields to point towards external domains under their control rather than legitimate in-cluster endpoints. This deviation from intended design creates a direct pathway for malicious actors to leverage Kyverno as a proxy for outbound network requests originating from the Kubernetes control plane components that evaluate these policies.
From an operational perspective, the impact of this vulnerability is severe due to the nature of data processed during policy evaluation cycles. When Kyverno evaluates a resource against a defined policy, it often gathers context information about the target resources, which may include sensitive metadata and actual content such as secret values, configuration maps, or other privileged Kubernetes objects. In the case of an SSRF attack via Service Call, this contextual data is packaged and transmitted to the external URL specified by the attacker. This mechanism effectively turns Kyverno into a powerful exfiltration tool, allowing adversaries to retrieve sensitive cluster state information without needing direct network access to the internal services or API server from their own infrastructure. The ability to read secrets and other confidential configurations significantly compromises the integrity of the entire Kubernetes environment, potentially leading further credential theft, lateral movement, or persistent backdoor installation within the cluster.
This vulnerability aligns closely with CWE-918, which defines Server-Side Request Forgery as a weakness where a web server retrieves content from an arbitrary URL provided by the user without sufficient validation of that input. Furthermore, in terms of adversary tactics and techniques, this exploit maps directly to ATT&CK technique T1505.003, known as Web Services: Cloud Service Dashboard or API Abuse, specifically leveraging legitimate administrative tools for malicious data exfiltration. It also relates to CWE-284 regarding Improper Access Control, as the vulnerability stems from insufficient validation of input parameters that dictate network behavior within a privileged context. The exploitation does not require complex binary exploits or memory corruption but relies on logical flaws in how external inputs are processed by security enforcement tools themselves.
Mitigation strategies must prioritize immediate version upgrades and strict access control policies to address this risk effectively. Organizations running Kyverno should upgrade to version 1.13.4 or later, where the developers have implemented stricter validation logic to ensure that Service Call operations remain confined to internal cluster services as originally intended. In environments where upgrading is not immediately feasible, administrators must enforce rigorous Role-Based Access Control (RBAC) policies to restrict who can create or modify ClusterPolicies and Policies. Limiting these permissions to a minimal set of trusted service accounts reduces the attack surface significantly by preventing unauthorized users from injecting malicious URLs into policy definitions. Additionally, implementing network-level controls such as egress filtering on nodes running Kyverno controllers can provide an additional layer of defense by blocking outbound connections to untrusted external domains during policy evaluation processes. Regular auditing of policy configurations and monitoring for anomalous outbound traffic patterns associated with the Kyverno service account are also recommended practices to detect potential exploitation attempts early in the kill chain.