Kyverno Service Account Token Leak via API Call

A vulnerability exists in Kyverno versions prior to 1.17.0 where the apiCall and serviceCall helpers automatically inject the Kyverno controller’s service account token into outgoing requests. This occurs when a Kyverno policy does not explicitly define an Authorization header for the request. Because the destination URL for these API calls is policy-controlled via context.apiCall.service.url, a malicious actor could create or modify a ClusterPolicy or GlobalContextEntry to direct these requests—and thus the service account token—to an attacker-controlled endpoint. This vulnerability allows for token exfiltration and subsequent unauthorized actions, depending on the RBAC permissions granted to the Kyverno service account. This issue is limited to ClusterPolicy and global context usage, as namespaced policies are blocked from servicecall usage.

Attack Chain

1. Attacker gains the ability to create or modify ClusterPolicy objects, potentially by compromising a GitOps repository or controller managing Kyverno policies.
2. Attacker crafts a malicious ClusterPolicy that uses the apiCall or serviceCall feature.
3. The policy specifies a URL for the context.apiCall.service.url that points to an attacker-controlled endpoint designed to capture the incoming request.
4. The crafted policy does not define an explicit Authorization header for the apiCall or serviceCall.
5. When the policy is triggered, Kyverno’s executor.addHTTPHeaders function detects the missing Authorization header.
6. Kyverno reads the service account token from /var/run/secrets/kubernetes.io/serviceaccount/token.
7. Kyverno injects the service account token into the request header as Authorization: Bearer <token>.
8. The request, including the Kyverno service account token, is sent to the attacker-controlled endpoint, allowing the attacker to exfiltrate the token.

Impact

Successful exploitation of this vulnerability results in the exfiltration of the Kyverno controller service account token. The severity of the impact depends on the RBAC roles and permissions assigned to the Kyverno service account within the Kubernetes cluster. With the stolen token, an attacker can perform any action that the Kyverno service account is authorized to perform, potentially leading to cluster-wide compromise, data breaches, or denial-of-service conditions. The number of affected clusters would depend on the number of Kyverno deployments using vulnerable versions.

Recommendation

• Upgrade Kyverno to version 1.17.0 or later to patch the vulnerability (go/github.com/kyverno/kyverno).
• Implement monitoring to detect modifications to ClusterPolicy resources, especially those utilizing apiCall or serviceCall to arbitrary URLs, to quickly identify potentially malicious policy changes.
• Deploy the provided Sigma rule to detect unexpected outbound network connections from the Kyverno pod that may indicate token exfiltration.
• As a workaround, set explicit Authorization headers in all apiCall and serviceCall policies to prevent the implicit token injection (see workarounds).