CVE-2026-100705: Kyverno before 1.19.1 SSRF via legacy apiCall service executor
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Kyvernoto a version that resolves this vulnerability.Fixed in 1.19.1
Event History
Frequently Asked Questions
Who can trigger the vulnerable request paths?
An author of a ClusterPolicy or GlobalContextEntry can configure the target service URL. A lower-privileged user can also trigger requests when a deployed policy templates that URL from an admission resource they can submit.
Are the existing egress blocklist and scoped-token controls effective for these requests?
No. Those controls were applied only to the CEL http.Get/Post library, not to the legacy apiCall service executor or the GlobalContextEntry external-API path.
What should be reviewed to determine exposure?
Review non-CEL context[].apiCall.service usage and GlobalContextEntry external-API configurations, especially service URLs derived from admission-resource fields. These paths can send GET or POST requests to arbitrary destinations, including metadata services, loopback addresses, and in-cluster services.
What credentials or network access could be exposed?
Kyverno makes requests using its own network position and unconditionally attaches its projected ServiceAccount token to the configured destination. The token is audience-scoped, which limits replay value, but requests may still reach internal endpoints or cloud metadata services and retrieve instance credentials.
What version resolves the issue?
The issue is fixed in Kyverno 1.19.1. Kyverno versions before 1.19.1 are affected.