CVE-2026-84199: Kyverno before 1.16.2 SSRF via APICall Feature
Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature. The URL field in a Policy's ServiceCall configuration is not validated, so a user with namespace-level Policy creation permissions can direct Kyverno to make HTTP requests to arbitrary internal resources (e.g., cloud metadata endpoints such as 169.254.169.254 or other tenants' resources). Because Kyverno executes these requests using its cluster-wide high-privilege ServiceAccount (a Confused Deputy problem), the responses—potentially including other tenants' secrets and cloud IAM credentials—are returned in the PolicyReport and can be read by the attacker, breaking multi-tenant isolation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Kyvernoto a version that resolves this vulnerability.Fixed in 1.16.2 - Compensating control
Mitigate the SSRF risk in the Kyverno APICall feature by preventing namespace-level users from creating Policies with ServiceCall configurations that include an unvalidated URL field; restrict Policy creation/ServiceCall permissions to trusted namespaces/users until Kyverno is upgraded to 1.16.2.
Event History
Frequently Asked Questions
Who can exploit this vulnerability?
A user who has permission to create namespace-level Kyverno Policies can exploit it. This is particularly significant in multi-tenant clusters, where such a user may use Kyverno's cluster-wide ServiceAccount privileges to access resources belonging to other tenants.
What access or conditions are required for exploitation?
The attacker needs namespace-level Policy creation permissions and must be able to configure a ServiceCall using the APICall feature. No user interaction is required; the attacker supplies an unvalidated URL that Kyverno then requests.
What can an attacker obtain through the SSRF?
Kyverno can be directed to request arbitrary internal HTTP resources, including cloud metadata endpoints or other tenants' resources. Responses are returned in PolicyReport data readable by the attacker, potentially exposing secrets or cloud IAM credentials.
How can I tell whether the issue affects my deployment?
Deployments running Kyverno before 1.16.2 are affected. Review whether namespace-level users or tenant roles can create Kyverno Policies with ServiceCall/APICall configurations, and inspect PolicyReports for unexpected results from such policies.
What should be prioritized if patching cannot happen immediately?
Restrict namespace-level permissions to create Kyverno Policies, especially Policies that can use ServiceCall/APICall. Treat PolicyReport access as sensitive because it may contain responses obtained using Kyverno's high-privilege ServiceAccount.