Kyverno Flaw Auto-Attaches Kubernetes ServiceAccount Tokens to External API Calls, Raising Exfiltration Risk

A vulnerability in Kyverno's apiCall service mode silently attaches admission controller ServiceAccount (SA) tokens to all outbound HTTP requests, creating a credential exposure pathway when requests reach external or attacker-controlled endpoints. The flaw operates as an insecure default behavior, meaning policy authors do not need to explicitly configure token forwarding for it to occur. This raises the risk of token exfiltration without operators realizing their admission controller credentials are being transmitted.

The vulnerability stems from code in `pkg/engine/apicall/executor.go` that reads the ServiceAccount token from `/var/run/secrets/kubernetes.io/serviceaccount/token` and injects it into outbound requests as an `Authorization: Bearer <token>` header whenever no explicit Authorization header is defined in the policy. The logic checks only whether the header is empty before appending the token, creating what researchers describe as implicit credential forwarding. The behavior is not documented, leaving operators unaware that their admission controller identity may be forwarded to third-party services during policy evaluation.

Security researchers warn that any external endpoint reachable during a Kyverno policy lifecycle becomes a potential collection point for admission controller tokens. If an attacker controls a destination or can perform a man-in-the-middle attack, the exposed token could enable lateral movement within the cluster. The vulnerability affects environments using Kyverno's apiCall feature in service mode, and the lack of documentation means many deployments may be affected without explicit opt-in. Operators should audit policies that make external calls and treat the advisory as requiring immediate review and patching.