Kyverno: admission controller ServiceAccount token attached to outbound apiCall requests leaks to any endpoint

Impact

Kyverno's apiCall service mode attaches the admission controller's own ServiceAccount token to outbound HTTP requests without an explicit authorization header, so any endpoint a policy calls receives that token. A user who can get a policy to make an apiCall to an external or attacker-controlled URL captures the token and inherits the admission controller's permissions, which in a typical install means full control over Kyverno policies and broad cluster resource access. On a GPU cluster that matters because the admission controller is usually the thing enforcing which images may run, which namespaces may request GPUs, and which pods may mount device or hostPath resources - owning it means being able to turn those guardrails off cluster-wide rather than attacking one node at a time.

Who can reach it

An authenticated user with enough privilege to influence a policy's apiCall service URL, or anyone who controls a host that Kyverno policies already call out to. Not reachable unauthenticated from outside the cluster.

What to do

Upgrade Kyverno to 1.16.4 or later, then roll the admission controller Deployment so the new image is running. Because the leaked credential is the controller's ServiceAccount token, rotate that token after patching rather than assuming the upgrade alone closes the exposure, and audit which external endpoints existing apiCall policies point at. This is a control-plane workload restart, not a node action - GPU workloads do not need to be drained.

References

Related entries

• Kyverno: SSRF via apiCall.service.url lets authenticated users reach internal and metadata endpointsCVE-2026-84196 · Kyverno admission controller (apiCall.service.url variable substitution)High
• Kubernetes (kubelet): /debug/pprof exposed on the unauthenticated kubelet healthz portCVE-2019-11248 · Kubernetes (kubelet)High
• Envoy: JWT with an issuer absent from the provider list bypasses JWT authenticationCVE-2021-21378 · EnvoyHigh
• KubeVirt: A compromised node's virt-handler service account can be abused cluster-wideCVE-2023-26484 · KubeVirtHigh
• Envoy: Client can forge the x-envoy-original-path header and bypass JWT checksCVE-2023-27487 · EnvoyHigh
• Envoy: Mixed-case HTTP/2 schemes defeat case-sensitive internal scheme checksCVE-2023-35944 · EnvoyHigh