Introduction
A flaw in Kyverno's apiCall feature silently forwards the admission controller's privileged ServiceAccount token to any URL specified in a ClusterPolicy, with no destination validation whatsoever. For organizations running Kyverno in production Kubernetes clusters, this means anyone with ClusterPolicy write access can exfiltrate a token that can patch webhook configurations, which is enough for full cluster takeover.
Kyverno is a Kubernetes-native policy engine for cloud-native platform engineering teams. It supports policy as code for cluster governance, security enforcement, and automated resource management. It is a CNCF incubating project with broad adoption across enterprise Kubernetes deployments. As an admission controller, Kyverno sits directly in the critical path of every API request to the cluster, so vulnerabilities in it are especially serious.
Technical Information
CVE-2026-41323 comes from two separate implementation issues in Kyverno's apiCall feature. Together they form a complete chain from credential theft to cluster compromise.
Root Cause: Unvalidated URL and Implicit Token Injection
The first issue is that Kyverno does not validate the service URL in a ClusterPolicy's apiCall block at all. The URL goes straight into HTTP request creation with no scheme check, no IP restriction, and no allowlist. This matches CWE-918 (Server-Side Request Forgery), because the application builds a request to a user-controlled URL without sanitizing it.
The second issue is implicit credential injection. When the outgoing HTTP request has no Authorization header, the Kyverno executor automatically reads its own ServiceAccount token from the pod's filesystem and adds it as a Bearer token. This falls under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).
The injected token belongs to the Kyverno admission controller's ServiceAccount. In a default Helm installation, that ServiceAccount has these verified permissions:
| Action | Result |
|---|---|
| List pods in all namespaces | Allowed |
| Read configmaps in kube-system | Allowed |
| Patch MutatingWebhookConfiguration | Allowed |
| Patch ValidatingWebhookConfiguration | Allowed |
| Read secrets cluster wide | Denied |
The permissions that matter are the patch rights on MutatingWebhookConfiguration and ValidatingWebhookConfiguration. With them, an attacker can redirect or intercept every API request that passes through the cluster's admission control layer.
Attack Flow
Exploitation takes four steps:
-
Policy creation: An attacker with permission to create or modify ClusterPolicy resources writes a malicious policy. Its apiCall block sets the service URL to an HTTP listener the attacker controls.
-
Trigger: When a Kubernetes resource that matches the policy is created (a new pod, for example), Kyverno evaluates the policy, and the apiCall sends an outbound HTTP request to the attacker's endpoint.
-
Token capture: The policy definition sets no explicit Authorization header, so Kyverno automatically injects its admission controller ServiceAccount token into the request. The attacker's listener reads the token from the Authorization header.
-
Cluster compromise: The attacker authenticates to the Kubernetes API server with the stolen token. With patch permissions on webhook configurations, the attacker can hijack Kyverno's webhooks, intercept all API requests flowing through the cluster, and inject malicious containers into workloads.
SSRF Dimension
The missing URL validation also allows server-side request forgery against internal network endpoints. If the apiCall URL points at the cloud metadata service (169.254.169.254), an attacker can extract cloud IAM credentials from the instance metadata endpoint. That pivots the attack from the Kubernetes cluster into the wider cloud environment, and may give the attacker access to cloud storage, databases, and other services tied to the node's IAM role.
Affected Systems and Versions
These Kyverno versions are affected:
- All versions prior to 1.16.4
- All versions in the 1.17.x branch prior to 1.17.2-rc1
- All versions in the 1.18.x branch prior to 1.18.0-rc1
A deployment is vulnerable when:
- The apiCall feature is available in ClusterPolicy resources (the default).
- The admission controller ServiceAccount keeps its default Helm installation permissions, which include the ability to patch webhook configurations.
- Users or service accounts in the cluster have permission to create or modify ClusterPolicy resources.
The patched versions are 1.16.4, 1.17.2-rc1, and 1.18.0-rc1.
References
- NVD Entry for CVE-2026-41323
- GitHub Security Advisory GHSA-f9g8-6ppc-pqq4: ServiceAccount token leaked to external servers via apiCall service URL
- GitHub Advisory Database: GHSA-8wfp-579w-6r25
- Patch commit: use scoped token for request authz (main branch)
- Patch commit: backport to 1.17.x branch
- Patch commit: backport to 1.16.x branch



