Description

Kyverno before 1.19.1 is vulnerable to server-side request forgery. The default egress blocklist (169.254.169.254, 169.254.169.253, metadata.google.internal, 127.0.0.0/8, ::1/128) and the scoped-token control were wired only into the new CEL http.Get/Post library and were never applied to the legacy apiCall service executor (pkg/engine/apicall/executor.go) or to the GlobalContextEntry external-API path, which handle every non-CEL context[].apiCall.service call. Because these paths use a plain net/http client with no egress filtering and no validation of the configured service URL, a ClusterPolicy or GlobalContextEntry author — or, where a deployed policy templates the service URL from the admission resource, a lower-privileged resource submitter — can cause Kyverno to issue GET/POST requests to an arbitrary host, including the cloud metadata endpoint, loopback, and any in-cluster service, reading cloud instance credentials and reaching internal endpoints with Kyverno's network position. The executor also unconditionally attaches Kyverno's projected ServiceAccount token to the attacker-chosen destination; the token is audience-scoped, limiting its replay value. Fixed in 1.19.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.6",
  "pubDate": "2026-09-26T14:16:55.703Z",
  "pubdate": "2026-09-26T14:16:55.703Z",
  "executiveSummary": "Kyverno versions prior to 1.19.1 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability due to incomplete egress filtering in the legacy API call executor. The vulnerability stems from a failure to apply established blocklists—specifically those designed to protect cloud metadata services and loopback interfaces—to non-CEL (Common Expression Language) API paths.\nThe flaw affects the pkg/engine/apicall/executor.go component and the GlobalContextEntry external-API path. An attacker with the ability to create or influence a ClusterPolicy or GlobalContextEntry resource can force the Kyverno controller to initiate unauthorized GET/POST requests to arbitrary internal and external endpoints. This allows for the exfiltration of sensitive cloud instance credentials and interaction with restricted internal services.\nSuccessful exploitation leverages Kyverno’s own network position and identity. Because the affected executor automatically attaches a projected ServiceAccount token to outgoing requests, the attacker can potentially gain unauthorized access to internal resources or cloud provider APIs that trust the Kyverno identity. The risk is significant, as it permits lateral movement within the cluster and potential privilege escalation by accessing internal metadata services.",
  "technicalDetails": "The root cause of this SSRF vulnerability is the inconsistent application of security controls between newer CEL-based validation logic and the legacy API call executor path. While Kyverno implemented robust egress blocklists (including 169.254.169.254, 169.254.169.253, metadata.google.internal, 127.0.0.0/8, and ::1/128) and scoped-token controls for its CEL-based http.Get/Post library, these protections were omitted from the legacy pkg/engine/apicall/executor.go and GlobalContextEntry external-API paths.\nThe attack flow begins when an attacker submits a malicious ClusterPolicy or GlobalContextEntry resource. If the policy templates the service URL using fields derived from an admission resource, a lower-privileged user can control the destination URL. Since the legacy executor utilizes a standard net/http client without egress filtering or validation of the target URL, the Kyverno controller executes the request exactly as defined by the user-provided input.\nThe exploitation mechanism allows an attacker to bypass network segmentation and interact with endpoints typically protected by internal firewalls. By specifying target URLs such as the cloud metadata service (e.g., 169.254.169.254), an attacker can retrieve instance identity documents, metadata, and potentially sensitive cloud credentials. Furthermore, since the executor unconditionally appends the Kyverno projected ServiceAccount token to these requests, the targeted endpoint receives an authenticated request from a high-privilege controller service. While the token is audience-scoped, it remains highly useful for interacting with services that accept the Kyverno token as valid authorization.\nThis vulnerability is particularly dangerous because it bypasses the security posture established for CEL-based policies, leaving legacy policy configurations exposed. An attacker does not require explicit authentication to the Kubernetes API if they can influence the creation of resources that utilize these legacy API call paths, effectively turning Kyverno into a proxy for arbitrary network requests from within the cluster control plane."
}