Kyverno CVE-2026-41485

Requires Kubernetes RBAC permissions to create Policy or ClusterPolicy custom resources in the cluster - typically granted only to platform administrators, SREs, or DevOps teams managing policy enforcement. Does NOT require cluster-admin or elevated node access, just namespace-level policy creation rights for Policy objects or cluster-level rights for ClusterPolicy. Exploitation limited to clusters running vulnerable Kyverno versions (pre-1.17.2 or pre-1.16.4) with the legacy policy engine enabled. Only affects resources and controllers processing legacy policy DSL - CEL-based policy engine is immune. Attack succeeds against default Kyverno configurations without requiring specific feature flags or non-standard deployment modes. Primary limiting factor is RBAC boundary: in well-configured clusters, policy creation is restricted to trusted identities; in multi-tenant or loosely controlled environments where developers have broad policy permissions, the attack surface expands significantly.

Real-world risk is moderate despite 7.7 CVSS score. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H) correctly reflects network-accessible low-complexity attack requiring only low privileges, with Changed scope due to cluster-wide controller crash and High availability impact. However, exploitation requires RBAC permissions to create policies - a privilege typically restricted to platform administrators, not regular users. EPSS data not provided but expected to be low given the narrow privilege requirement. No CISA KEV listing indicates this is not being exploited at scale. Public exploit code exists via the referenced GitHub commits showing the exact vulnerability pattern. Primary risk is insider threat or compromised service accounts with policy management permissions. For multi-tenant Kubernetes environments where multiple teams manage their own policies via isolated namespaces, this becomes more concerning as any tenant with ClusterPolicy permissions can DOS the entire cluster. Organizations without strict RBAC controls on policy creation face higher practical risk than the 7.7 score alone suggests.

An attacker with Policy creation permissions (either through compromised credentials or insider access) crafts a Kyverno policy with a malformed forEach mutation structure that triggers the unchecked type assertion. Upon policy creation, the cluster-wide background controller attempts to reconcile the policy, encounters the type assertion failure, and crashes into CrashLoopBackOff. Simultaneously, the admission webhook fails when processing any resources matching the policy's criteria, blocking legitimate operations like pod deployments. The denial of service persists across controller restarts until an administrator identifies and deletes the malicious policy, during which time affected workload deployments are completely blocked.