Kyverno CVE-2026-84195

Exploitation requires that the attacker hold Kubernetes RBAC permissions sufficient to create or modify Kyverno ClusterPolicy or Policy resources - this is the critical gate. The apiCall service mode must be used in the policy rule (apiCall.service.url must reference an HTTP endpoint rather than a Kubernetes API path). No special non-default Kyverno configuration is required beyond what is present in any standard installation; the credential forwarding behavior is active by default whenever the service URL path is used. Exploitation is additionally limited to contexts where the attacker can trigger a matching admission event (e.g., create a Pod if the policy matches Pod resources). Factors that limit exposure: environments where only cluster-admin or a tightly controlled CI/CD identity can write policies are substantially protected; clusters that use only apiCall with Kubernetes-internal API paths (not service.url) are not directly affected by this specific code path.

The CVSS 4.0 score of 8.3 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N) accurately reflects the threat model: network-reachable exploitation at low complexity requiring only policy-write privileges, with high confidentiality impact on both the vulnerable Kyverno system and subsequent cluster systems via the exfiltrated token. Real-world risk is elevated beyond the raw score because the exfiltrated SA token grants administrative-equivalent control over Kyverno policies and cluster resources, making this effectively a privilege escalation path from policy-author to cluster-admin. No EPSS score is available in the provided data, making exploitation probability rate estimation unreliable. The absence of a CISA KEV listing means active exploitation is not confirmed, but the embedded PoC lowers the bar to exploitation significantly - any user with ClusterPolicy creation rights can trivially reproduce the attack in minutes. The primary limiting factor is the PR:L prerequisite: an attacker must already hold permissions to create Kyverno ClusterPolicy or Policy resources, which in well-governed clusters is restricted to elevated roles. In clusters with permissive RBAC or developer self-service policy authoring, exposure is substantially higher.

An attacker with Kubernetes RBAC permissions to create ClusterPolicy resources deploys a capture server inside or outside the cluster and creates a Kyverno ClusterPolicy with a rule that matches Pod admission events and includes an apiCall pointing to the attacker-controlled service URL. When any user subsequently creates a Pod, Kyverno's admission webhook fires, executes the apiCall, and automatically injects the Kyverno admission controller's ServiceAccount bearer token into the HTTP request - which the capture server logs. The attacker then uses the token to impersonate the Kyverno service account and gain full control over cluster policies and resources. A working proof-of-concept demonstrating all four steps is included in GHSA-8wfp-579w-6r25.