Can you explain this vulnerability to me?

CVE-2026-40868 is a vulnerability in Kyverno versions prior to 1.16.4 where the Kyverno controller serviceaccount token is implicitly injected into outgoing HTTP requests made via the apiCall and serviceCall helpers if a policy does not explicitly set an Authorization header.

Because the URL used in these calls (context.apiCall.service.url) is controlled by the policy, an attacker who can create or update a ClusterPolicy or GlobalContextEntry can specify an attacker-controlled endpoint to receive the token.

This leads to a confused deputy problem where the Kyverno serviceaccount token is leaked to an attacker, potentially allowing unauthorized access depending on the permissions of that token.

The vulnerability does not affect namespaced policies due to a URL path gate restricting serviceCall usage, and it was fixed in Kyverno version 1.16.4.

Useful 0 Not Useful 0

How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability in Kyverno prior to version 1.16.4 allows leakage of the Kyverno controller serviceaccount token to attacker-controlled endpoints. This token leakage can lead to unauthorized access depending on the RBAC permissions bound to the token.

Such unauthorized access and token exfiltration could potentially lead to breaches of confidentiality and unauthorized data access, which may impact compliance with standards and regulations like GDPR and HIPAA that require strict controls on access to sensitive data and credentials.

Mitigations such as disabling automatic token injection, enforcing explicit Authorization headers, and restricting serviceCall usage help reduce the risk of token leakage and thus help maintain compliance with these regulations.

Useful 0 Not Useful 0

How can this vulnerability impact me? :

This vulnerability can lead to the leakage of the Kyverno controller serviceaccount token to attacker-controlled endpoints.

If an attacker obtains this token, they may be able to perform unauthorized actions within the Kubernetes cluster, depending on the RBAC permissions associated with the token.

Such unauthorized access could compromise the security and integrity of your cloud native platform, potentially allowing attackers to manipulate policies, access sensitive data, or disrupt operations.

Useful 0 Not Useful 0

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring outgoing HTTP requests made by Kyverno policies that use the apiCall or serviceCall helpers without an explicit Authorization header. Specifically, you can look for HTTP requests that include an Authorization: Bearer <token> header containing the Kyverno controller serviceaccount token being sent to potentially attacker-controlled endpoints.

A proof of concept involves running an in-cluster HTTP receiver that logs incoming Authorization headers to detect if the Kyverno token is being leaked.

While no exact commands are provided, a practical approach includes capturing network traffic from the Kyverno controller pod and filtering for HTTP requests with Authorization headers. For example, using kubectl and tcpdump or curl inside the cluster:

• kubectl exec -n kyverno <kyverno-pod> -- tcpdump -i any -A port 80 or port 443
• Set up an HTTP server inside the cluster to log Authorization headers from incoming requests.
• Review ClusterPolicy or GlobalContextEntry resources for usage of context.apiCall.service.url without explicit Authorization headers.

Useful 0 Not Useful 0

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include upgrading Kyverno to version 1.16.4 or later, where this vulnerability is fixed.

Additional recommended mitigations are:

• Disable automatic injection of the Kyverno serviceaccount token into policy-controlled serviceCall requests.
• Require explicit Authorization headers in serviceCall policies to prevent implicit token injection.
• Enforce a strict allowlist of destination URLs where credentials may be attached.
• Avoid using serviceCall to arbitrary URLs in policies.

Useful 0 Not Useful 0