Kyverno CVE-2026-41323

Attacker must possess authenticated Kubernetes API access with RBAC permissions to create or modify ClusterPolicy resources (PR:L), which typically requires namespace-admin or policy-author roles in organizations using Kyverno. The Kyverno admission controller must have network egress capability to reach attacker-controlled servers, which is default in most Kubernetes deployments unless restrictive NetworkPolicies are enforced. The apiCall feature must be enabled in ClusterPolicy configurations, which is a standard Kyverno capability used for external data lookups during policy evaluation. Exploitation is limited by the need for initial authenticated cluster access and ClusterPolicy modification permissions, but these are commonly granted in multi-tenant environments where namespace owners author their own policies. No user interaction required (UI:N) once the malicious policy is created. Default Kyverno installations without additional RBAC hardening or egress restrictions are exploitable.

Real-world risk is HIGH despite requiring authenticated access (PR:L). CVSS 8.1 accurately reflects the severity given network attack vector (AV:N), low complexity (AC:L), and high confidentiality/integrity impact. The privilege requirement is deceptive - any authenticated Kubernetes user with permission to create or modify ClusterPolicy resources can exploit this, which in many clusters includes namespace administrators or policy authors. The attack is automatable once initial policy creation access is obtained, and the impact is cluster-wide compromise through webhook manipulation. SSVC decision would likely classify as Scheduled or Out-of-Cycle given the straightforward exploitation path and severe technical impact (total control over admission control). The information disclosure tag understates the severity - while technically token exfiltration, the stolen credential provides full cluster admin capabilities. No EPSS or KEV data provided, but the low attack complexity and clear exploitation path to cluster compromise warrant immediate patching. The availability of patches across three version branches (1.16.x, 1.17.x, 1.18.x) indicates vendor acknowledgment of criticality.

An attacker with namespace-admin privileges in a multi-tenant Kubernetes cluster creates a malicious ClusterPolicy containing an apiCall directive pointing to their controlled server (attacker.example.com). When Kyverno's admission controller evaluates this policy during a pod creation event, it automatically makes an HTTP request to the attacker's server with the ServiceAccount bearer token in the Authorization header. The attacker captures the token, uses it to authenticate to the Kubernetes API server with admission controller privileges, then patches the MutatingWebhookConfiguration to inject malicious code into all pod deployments cluster-wide, achieving persistent cluster compromise.