Description

Kyverno before 1.16.4 automatically attaches the admission controller's ServiceAccount token to outbound HTTP requests in apiCall service mode without explicit authorization headers. Attackers can exfiltrate the token by directing apiCall requests to external or attacker-controlled endpoints, gaining full control over Kyverno policies and cluster resources.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-01T12:17:49.130Z",
  "pubdate": "2026-09-01T12:17:49.130Z",
  "executiveSummary": "Kyverno versions prior to 1.16.4 are susceptible to an improper authorization vulnerability within the apiCall service mode functionality.\nThe vulnerability allows for the unauthorized exfiltration of the Kyverno admission controller's ServiceAccount token.\nBy manipulating apiCall configurations, an attacker can force the controller to transmit its sensitive bearer token to an external, attacker-controlled endpoint.\nThis flaw grants an adversary the ability to impersonate the Kyverno controller, potentially leading to full control over Kyverno policies and elevated cluster-wide resource access.\nThe vulnerability requires the ability to create or modify Kyverno policies within the cluster to trigger the malicious apiCall.\nThe impact is critical, as it bypasses intended access controls and exposes the identity of a highly privileged system component.",
  "technicalDetails": "The root cause of this vulnerability lies in the automatic and implicit injection of the admission controller's ServiceAccount token into outbound HTTP requests initiated by the apiCall feature in Kyverno.\nWhen a user defines an apiCall within a Kyverno policy, the controller attempts to fetch data from an external service. In affected versions, the implementation fails to isolate the request from the controller's own authentication context, resulting in the inclusion of the ServiceAccount's JWT (JSON Web Token) in the request headers.\nThe attack flow begins with an adversary possessing sufficient permissions to define or update a Kyverno policy resource. The attacker crafts a policy containing an apiCall definition that points to an adversary-controlled server.\nUpon the policy being triggered by a resource admission event, the Kyverno controller executes the apiCall. During this process, the controller inadvertently attaches its ServiceAccount token to the outbound HTTP request.\nThe attacker's server, acting as a listener, captures the incoming request, extracts the authorization header, and retrieves the bearer token.\nOnce the token is obtained, the attacker can use the ServiceAccount credentials to authenticate directly against the Kubernetes API server, assuming the role of the Kyverno controller.\nGiven that the Kyverno controller typically requires extensive permissions to manage AdmissionReports, PolicyReports, and to patch various cluster resources, the compromise of this token effectively escalates the attacker's privileges to the level of the controller's RBAC scope.\nThis behavior persists across all versions of Kyverno before 1.16.4, affecting the core admission controller component responsible for policy enforcement.\nExploitation does not require external network exposure of the Kyverno controller itself, as the outbound request is initiated from within the cluster to the destination defined in the policy, allowing the attacker to bypass egress filtering or internal network boundaries."
}