CVE-2026-41485: 
Wolfi vulnerability analysis and mitigation

CVE-2026-41485 is a Denial of Service vulnerability in Kyverno, a policy engine for cloud-native Kubernetes environments, caused by an unchecked type assertion in the forEach mutation handler. Any authenticated user with permission to create a Policy or ClusterPolicy resource can trigger a persistent CrashLoopBackOff in the cluster-wide background controller and cause the admission controller to drop connections, blocking all matching resource operations. The vulnerability affects Kyverno versions 1.13.0 through 1.16.3 and 1.17.0 through 1.17.1; CEL-based policies are unaffected. It was published on April 22–24, 2026, and carries a CVSS v3.1 base score of 7.7 (High) (GitHub Advisory).

The root cause is a bare (unchecked) Go type assertion classified as CWE-617 (Reachable Assertion). In pkg/engine/mutate/mutation.go, the ForEach function performs fe["patchesJson6902"].(string) without checking whether the interface value is nil first. When a forEach rule uses a patchesJson6902 field containing a variable substitution (e.g., {{ element.nonexistent }}) that resolves to nil at runtime, the assertion triggers an unrecoverable Go panic: panic: interface conversion: interface {} is nil, not string. For mutateExisting rules, the admission controller creates a persistent UpdateRequest resource that the background controller re-processes on every restart, sustaining the crash loop until the policy or UpdateRequest is manually deleted. The admission controller itself survives via Go's net/http panic recovery but drops the connection, effectively blocking all matching webhook operations. The vulnerable code was introduced in PR #10702 (GitHub Advisory, Patch Commit).

Successful exploitation results in a persistent, cluster-wide Denial of Service affecting Kyverno's background controller (halting all background processing including generate rules, mutateExisting rules, and cleanup) and the admission controller (dropping connections for all matched resource kinds). A namespace-scoped user with only Policy creation rights can crash the background controller across all namespaces, not just their own, due to the cluster-wide scope of the background controller. With ClusterPolicy creation rights, the admission block extends cluster-wide, potentially preventing creation or modification of critical Kubernetes resources (e.g., Secrets) until the malicious policy is deleted. There is no confidentiality or integrity impact (GitHub Advisory).

A proof-of-concept exploit consisting of concrete YAML manifests is publicly available in the official GitHub Security Advisory, demonstrating both background controller crash and admission controller connection-drop scenarios (GitHub Advisory). Exploitation requires only low privileges (permission to create Policy or ClusterPolicy) and no user interaction, making it accessible to any namespace-level user in a misconfigured cluster. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.037% (very low probability of exploitation in the near term), and the vulnerability is not listed in the CISA KEV catalog (Feedly).

1. Reconnaissance: Identify a Kyverno deployment running a vulnerable version (1.13.0–1.16.3 or 1.17.0–1.17.1) using the legacy engine. Confirm you have RBAC permission to create a Policy (namespaced) or ClusterPolicy (cluster-scoped) resource.
2. Craft malicious Policy: Create a Policy or ClusterPolicy manifest with a mutateExisting or inline mutate rule using a forEach block where patchesJson6902 contains a variable that will resolve to nil at runtime, such as {{ element.nonexistent }}.
3. Apply the manifest: Submit the policy to the cluster (e.g., kubectl apply -f malicious-policy.yaml). For the background controller attack, also create the target ConfigMap and a trigger ConfigMap to activate the mutateExisting rule, which causes Kyverno to create a persistent UpdateRequest.
4. Trigger the panic: The background controller processes the UpdateRequest, hits the nil type assertion in ForEach, and panics. The k8s.io/apimachinery crash handler re-panics, killing the process. The controller enters CrashLoopBackOff and re-panics on every restart.
5. Verify impact: Confirm the background controller is in CrashLoopBackOff with kubectl get pods -n kyverno -l app.kubernetes.io/component=background-controller. For admission controller impact, attempt kubectl create secret generic test-secret --from-literal=key=value and observe EOF errors from the webhook.
6. Sustain the DoS: The crash loop is self-sustaining as long as the poisoned UpdateRequest and policy remain. The cluster is restored only when an administrator deletes the malicious policy and associated UpdateRequest (GitHub Advisory).

• Logs (Background Controller): Repeated log entries containing panic: interface conversion: interface {} is nil, not string in the Kyverno background controller pod logs; stack traces referencing pkg/engine/mutate/mutation.go:81 and ForEach.
• Logs (Admission Controller): Entries such as http: panic serving <IP>:<port>: interface conversion: interface {} is nil, not string in the admission controller logs, with goroutine stack traces referencing mutation.go and forEachMutator.
• Kubernetes Events: CrashLoopBackOff events for the pod labeled app.kubernetes.io/component=background-controller in the kyverno namespace; repeated container restarts with increasing back-off intervals.
• Kubernetes Resources: Presence of a Policy or ClusterPolicy with a forEach rule where patchesJson6902 contains a variable expression (e.g., {{ element.nonexistent }}); orphaned UpdateRequest resources in the kyverno namespace referencing the malicious policy.
• Network: Webhook calls to mutate.kyverno.svc-fail returning EOF errors for matched resource kinds (e.g., Secret create/update operations failing cluster-wide) (GitHub Advisory).

Upgrade Kyverno to version 1.17.2 or 1.16.4, which replace the bare type assertion with a safe assertion (jsonPatch, _ := fe["patchesJson6902"].(string)) so nil values are handled as errors rather than panics (Patch Commit, GitHub Advisory). As an interim workaround, restrict Policy and ClusterPolicy creation permissions to trusted administrators only via RBAC, preventing untrusted namespace users from submitting malicious policies. If exploitation is suspected, immediately identify and delete the malicious Policy/ClusterPolicy and any associated UpdateRequest resources in the kyverno namespace to restore controller functionality. CEL-based policies are unaffected and can be used as an alternative where feasible.

The vulnerability was reported by researcher thevilledev and the advisory was published by Kyverno maintainer realshuting on April 22, 2026 (GitHub Advisory). A technical write-up was published at infinitsec.net shortly after disclosure, covering the controller denial-of-service via forEach mutation panic. No significant broader media coverage or notable social media reactions have been identified beyond standard CVE tracking and aggregator sites.