Listen to this Post
The vulnerability arises because Kyverno automatically injects its own service account bearer token into any `apiCall.servicecall` request that does not already include an `Authorization` header. The token is read from /var/run/secrets/kubernetes.io/serviceaccount/token. An attacker who can create or modify a `ClusterPolicy` (or a GlobalContextEntry) controls the `context.apiCall.service.url` field and can therefore force the Kyverno controller to send an HTTP request to an arbitrary, attacker‑controlled endpoint. Because the request will carry the controller’s own service account token (a “confused deputy” scenario), the attacker can exfiltrate that token and then use it to impersonate the Kyverno controller, potentially gaining access to any resource the controller’s RBAC permits. The vulnerable code is located in the `(executor).addHTTPHeaders` function, where the token is added unconditionally when no `Authorization` header is present. The proof of concept (poc.zip) demonstrates that an external HTTP receiver logs the injected `Authorization` header, confirming the token is sent out of the cluster. The issue is scoped to `ClusterPolicy` and global context usage because namespaced policies are blocked by a `urlPath` gate in pkg/engine/apicall/apiCall.go.
dailycve form
Platform: Kyverno
Version: prior to 1.16.3 / 1.15.3
Vulnerability : implicit bearer token injection
Severity: High
date: 2026-04-13
Prediction: patch within 2 weeks
What Undercode Say
Analytics:
- Attack surface increases when ClusterPolicy definitions are pulled from an untrusted GitOps repository.
- The automatic injection is silent and does not appear in audit logs unless explicit outbound traffic monitoring is in place.
- Exploitation does not require any additional privileges beyond the ability to create or update a ClusterPolicy or GlobalContextEntry.
Bash commands and codes related to the blog
bash
Clone the proof-of-concept and run the canonical test
unzip poc.zip -d poc
cd poc
make canonical
Expected output snippet:
bash: executor.addHTTPHeaders Authorization==”” -> read_serviceaccount_token=true
bash: authorization_header_injected=true token_nonempty=true
Control test (explicit Authorization header prevents injection)
make control
Expected output snippet:
bash: executor.addHTTPHeaders Authorization!=”” -> autoinject_skipped=true
Optional: verify the exfiltrated token’s permissions (without printing the token)
kubectl auth can-i –list –token=
[/bash]
Exploit
An attacker creates a `ClusterPolicy` that defines an `apiCall` with a `service.url` pointing to an external HTTP server they control. No `Authorization` header is set. When the policy is evaluated, Kyverno injects its own bearer token and sends it to the attacker’s server. The attacker captures the token and uses it to authenticate as the Kyverno controller, gaining all the RBAC permissions bound to that service account.
Protection from this CVE
- Do not auto‑inject the Kyverno service account token. Instead, require an explicit `Authorization` header in every `servicecall` policy.
- Enforce a strict allowlist of destinations to which `servicecall` requests may be sent, and never attach credentials to requests destined outside the cluster.
- Avoid using `servicecall` to arbitrary URLs in policies. If `servicecall` is necessary, always set an explicit dummy `Authorization` header (e.g.,
Authorization: none) to prevent the automatic injection. - Upgrade to a patched version of Kyverno once available (expected within two weeks).
Impact
Successful exploitation leads to exfiltration of the Kyverno controller’s service account token. The impact depends on the RBAC permissions of that service account in the target deployment. If the controller has broad permissions (e.g., cluster admin), the attacker can fully compromise the cluster. Even with limited permissions, the attacker may be able to read Secrets, modify resources, or escalate privileges further.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
