CVE-2026-41323 is a high severity SSRF and credential leak (CVSS 8.1) in Kyverno. A ClusterPolicy apiCall can send the admission controller's service account token to any URL. Fixed in 1.16.4, 1.17.2-rc1 and 1.18.0-rc1. Upgrade, then review who can create policies.
What's affected
Per the record, versions before 1.16.4 are affected, and the patched versions are 1.16.4, 1.17.2-rc1 and 1.18.0-rc1. The advisory says it was tested on v1.17.1 with a default Helm install and likely affects all versions with apiCall service support.
How to check if you're exposed
Find your Kyverno version:
kubectl -n kyverno get deploy -o wide
helm list -n kyverno
Read the image tags and compare them with the fixed versions. Then find policies that use apiCall with a service URL:
kubectl get clusterpolicy -o yaml | grep -n "service:"
Treat any URL that points outside the cluster, or that you do not recognise, as a lead worth chasing. Also list who has permission to create or update ClusterPolicy objects, because the attack needs that right.
What to do now
- Upgrade Kyverno to 1.16.4, 1.17.2-rc1, 1.18.0-rc1 or later, using the track you run.
- Audit existing ClusterPolicy objects for apiCall service URLs and remove ones you cannot explain.
- Restrict who can create or edit policies with Kubernetes RBAC.
- If you suspect a token left the cluster, rotate the admission controller's credentials and review the webhook configurations for unexpected changes.
- Run the free dependency scan on your charts and images so you know which Kyverno version each cluster runs.
Why it matters
The record lists CWE-200, exposure of sensitive information, and CWE-918, server side request forgery. The advisory describes two issues that combine. The service URL from a policy goes into an HTTP request with no scheme or address checks. Then, if the request has no Authorization header, Kyverno adds its own service account token.
In the default Helm install, that account can read and patch the webhook configurations. A stolen token could therefore let an attacker alter admission control for the whole cluster, which is why a policy author gets a path to cluster level impact. The vector requires low privileges, so the control is deciding who may author policies. The record does not flag this CVE as known exploited.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to be cluster admin to abuse this?
The vector says low privileges are required. The advisory's chain needs the right to create a policy that uses apiCall, so tight RBAC on policy objects helps a lot.
Sources
Last reviewed: 19 October 2026.
