Kubernetes CVE-2026-40868

Attacker must have permission to create or update ClusterPolicy resources or create GlobalContextEntry resources in the target Kubernetes cluster. In GitOps deployments, this translates to write access to the policy repository or ability to inject commits into the repository's sync workflow (supply chain compromise). The vulnerable ClusterPolicy or GlobalContextEntry must use the context.apiCall.service.url feature without explicitly setting an Authorization request header, triggering the implicit token injection logic in executor.addHTTPHeaders. Namespaced Policy resources cannot exploit this vulnerability due to servicecall blocking at the urlPath gate. Successful exfiltration requires network reachability from Kyverno controller pods to the attacker-controlled endpoint specified in service.url, which may be blocked by restrictive egress policies but is typically allowed in default cluster networking configurations. Impact severity depends on RBAC grants bound to the kyverno-controller ServiceAccount - deployments using cluster-admin or similarly privileged roles face full cluster compromise, while minimal-RBAC deployments limit post-exploitation capabilities.

Real-world risk is significant for GitOps environments where policy repositories are a supply chain attack vector. CVSS 8.1 accurately reflects the network-accessible attack (AV:N) with straightforward exploitation (AC:L) requiring only ClusterPolicy creation privileges (PR:L), resulting in high confidentiality and integrity impact through token exfiltration and potential privilege escalation. No user interaction required (UI:N) and unchanged scope (S:U) indicate the attack remains within the Kyverno controller's privilege boundary. EPSS data not provided, but the combination of GitHub advisory with functional PoC, clear exploitation path, and broad Kyverno deployment in production clusters suggests elevated real-world likelihood. No CISA KEV listing indicates exploitation is not yet widespread, but the GitOps threat model (compromised policy repo becomes untrusted input) represents a realistic attack chain in modern CI/CD workflows. The RBAC-dependent impact creates variable risk: in clusters where the Kyverno ServiceAccount has cluster-admin rights (common default), token exfiltration enables full cluster compromise. The existence of a detailed PoC with reproducible test harness lowers the skill barrier for exploitation. Priority should be high for any deployment using ClusterPolicy or GlobalContextEntry with servicecall features, especially in GitOps configurations where policy source integrity is not cryptographically verified.

An attacker compromises a GitOps repository managing Kyverno policies and commits a malicious ClusterPolicy containing a context.apiCall.service definition targeting the attacker's internet-accessible HTTP server. When the GitOps controller (Flux/ArgoCD) synchronizes this policy to the cluster, Kyverno evaluates the policy and executes the servicecall without an explicit Authorization header. The executor.addHTTPHeaders function automatically injects Authorization: Bearer [kyverno-serviceaccount-token] and transmits it to the attacker's endpoint. The attacker captures the token and uses kubectl with --token= to authenticate as the Kyverno ServiceAccount, leveraging its cluster-wide RBAC grants to create privileged pods, access secrets, or modify critical cluster resources. Functional proof-of-concept code demonstrating token injection and exfiltration is included in the GitHub advisory attachments.