Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-01T12:17:18.183Z",
  "pubdate": "2026-09-01T12:17:18.183Z",
  "executiveSummary": "Kyverno versions prior to v1.13.4 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability originating from its Service Call functionality. This security flaw allows an authenticated user with sufficient Kubernetes permissions to create or update Kyverno (Cluster)Policies to manipulate the service configuration. By specifying arbitrary external URLs within the apiCall/service parameters, an attacker can coerce the Kyverno controller to initiate unauthorized requests to external endpoints.\nThe primary risk implication is the exfiltration of sensitive cluster data. Because the Kyverno engine injects policy context—which can include raw Kubernetes resource data such as Secrets, ConfigMaps, and other sensitive metadata—into these outgoing requests, an attacker can systematically harvest cluster credentials and proprietary configuration information. This vulnerability effectively bypasses intended cluster boundaries, as the Kyverno controller acts as a proxy for the malicious request. Exploitation requires the attacker to have RBAC privileges to create or modify Kyverno policy objects within the cluster. Given the nature of Kyverno's role as a policy enforcement engine, this SSRF represents a critical escalation path, potentially leading to a total compromise of cluster secrets and subsequent lateral movement or persistent unauthorized access.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper validation of the service address parameter within the Kyverno Service Call mechanism. While the component is architecturally designed to facilitate in-cluster communication for validation, mutation, and generation logic, the implementation fails to restrict the resolver to internal service names or legitimate cluster endpoints. Specifically, the component does not enforce a blocklist or whitelist for URI schemes and hostnames, allowing the resolution of external addresses.\nThe exploitation flow is as follows: First, an attacker with authorization to create Kyverno (Cluster)Policies defines a policy utilizing the 'apiCall' feature. Within the 'service' configuration block, the attacker designates an external URL controlled by their infrastructure. Second, the Kyverno controller, operating with high-level cluster permissions, processes the policy. When the triggering condition of the policy is met, the engine evaluates the context data associated with the relevant Kubernetes objects. Third, the controller executes a GET/POST request to the attacker-defined URL. During this operation, the engine includes the collected policy context data in the request body or headers.\nBecause the Kyverno controller is a privileged component, it maintains access to the Kubernetes API server and reads cluster resources as defined in the policy context. This means the injected context is not limited to public metadata; it encompasses sensitive information stored in Secrets or other sensitive objects if they are captured by the policy's selector logic. The attacker receives these credentials at their remote listener, effectively exfiltrating them from the restricted cluster environment.\nThis vulnerability is present in all Kyverno versions before v1.13.4. It requires the attacker to hold specific RBAC permissions allowing the modification of 'policies.kyverno.io' or 'clusterpolicies.kyverno.io' resources. The network exposure is facilitated by the controller's outbound network access, which is typically permitted in standard Kubernetes deployments. The post-exploitation impact is severe, as the exfiltration of Kubernetes Secrets facilitates the compromise of integrated third-party services, registry credentials, or cloud provider tokens, leading to a broader security failure beyond the containerized environment."
}