GHSA-Q93Q-V844-JRQP
Vulnerability from github – Published: 2026-04-14 20:09 – Updated: 2026-04-24 21:10kyverno’s apiCall servicecall helper implicitly injects Authorization: Bearer ... using the kyverno controller serviceaccount token when a policy does not explicitly set an Authorization header. because context.apiCall.service.url is policy-controlled, this can send the kyverno serviceaccount token to an attacker-controlled endpoint (confused deputy).
namespaced policies are blocked from servicecall usage by the namespaced urlPath gate in pkg/engine/apicall/apiCall.go, so this report is scoped to ClusterPolicy and global context usage.
attacker model
the attacker can create or update a ClusterPolicy (or create a GlobalContextEntry) which uses context.apiCall.service.url and can choose the request URL and headers. a cross-boundary framing for real deployments is gitops: if the policy repo/controller is compromised, the ClusterPolicy/global context entry becomes untrusted input to kyverno.
relevant links
- repository: https://github.com/kyverno/kyverno
- commit: 17aeb52337fd66adb0c8126213ba076612a287a7
- callsite (token injection): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/executor.go#L150-L173
- namespaced policy gate (servicecall blocked): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/apiCall.go#L67-L83
root cause
in (*executor).addHTTPHeaders, kyverno reads the serviceaccount token from /var/run/secrets/kubernetes.io/serviceaccount/token and injects it when the outgoing request has no Authorization header:
if req.Header.Get("Authorization") == "" {
token := a.getToken()
if token != "" {
req.Header.Add("Authorization", "Bearer "+token)
}
}
proof of concept
the attached poc.zip is a reproducible cluster PoC. it uses an in-cluster HTTP receiver which logs the Authorization header it receives. the PoC does not print token bytes; it only checks that the received header is non-empty and not equal to the negative control.
run (one command):
unzip poc.zip -d poc
cd poc
make test
canonical (expected: implicit token injection):
unzip poc.zip -d poc
cd poc
make canonical
expected output includes:
[CALLSITE_HIT]: executor.addHTTPHeaders Authorization=="" -> read_serviceaccount_token=true
[PROOF_MARKER]: authorization_header_injected=true token_nonempty=true
control (expected: explicit Authorization header disables auto-injection):
unzip poc.zip -d poc
cd poc
make control
expected output includes:
[CALLSITE_HIT]: executor.addHTTPHeaders Authorization!="" -> autoinject_skipped=true
[NC_MARKER]: authorization_header_injected=false
optional: the canonical run may also print an [RBAC]: ... line using kubectl auth can-i with the exfiltrated token, to show concrete privileges without exposing the token.
impact
token exfiltration: the kyverno controller serviceaccount token is sent to a policy-controlled endpoint. impact depends on the rbac bound to that serviceaccount in the target deployment.
recommended fix
do not auto-inject the kyverno serviceaccount token into policy-controlled servicecall requests. require explicit Authorization configuration, or enforce a strict allowlist of destinations where credentials may be attached and document the behavior.
workarounds
- avoid using servicecall to arbitrary urls in policies.
- set an explicit Authorization header in servicecall policies to prevent implicit token injection.
oleh
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.17.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40868"
],
"database_specific": {
"cwe_ids": [
"CWE-441",
"CWE-922"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T20:09:00Z",
"nvd_published_at": "2026-04-21T19:16:18Z",
"severity": "HIGH"
},
"details": "kyverno\u2019s apiCall servicecall helper implicitly injects `Authorization: Bearer ...` using the kyverno controller serviceaccount token when a policy does not explicitly set an Authorization header. because `context.apiCall.service.url` is policy-controlled, this can send the kyverno serviceaccount token to an attacker-controlled endpoint (confused deputy).\n\nnamespaced policies are blocked from servicecall usage by the namespaced `urlPath` gate in `pkg/engine/apicall/apiCall.go`, so this report is scoped to ClusterPolicy and global context usage.\n\n## attacker model\n\nthe attacker can create or update a ClusterPolicy (or create a GlobalContextEntry) which uses `context.apiCall.service.url` and can choose the request URL and headers. a cross-boundary framing for real deployments is gitops: if the policy repo/controller is compromised, the ClusterPolicy/global context entry becomes untrusted input to kyverno.\n\n## relevant links\n\n- repository: https://github.com/kyverno/kyverno\n- commit: 17aeb52337fd66adb0c8126213ba076612a287a7\n- callsite (token injection): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/executor.go#L150-L173\n- namespaced policy gate (servicecall blocked): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/apiCall.go#L67-L83\n\n## root cause\n\nin `(*executor).addHTTPHeaders`, kyverno reads the serviceaccount token from `/var/run/secrets/kubernetes.io/serviceaccount/token` and injects it when the outgoing request has no Authorization header:\n\n```go\nif req.Header.Get(\"Authorization\") == \"\" {\n token := a.getToken()\n if token != \"\" {\n req.Header.Add(\"Authorization\", \"Bearer \"+token)\n }\n}\n```\n\n## proof of concept\n\nthe attached `poc.zip` is a reproducible cluster PoC. it uses an in-cluster HTTP receiver which logs the Authorization header it receives. the PoC does not print token bytes; it only checks that the received header is non-empty and not equal to the negative control.\n\nrun (one command):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake test\n```\n\ncanonical (expected: implicit token injection):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake canonical\n```\n\nexpected output includes:\n\n```\n[CALLSITE_HIT]: executor.addHTTPHeaders Authorization==\"\" -\u003e read_serviceaccount_token=true\n[PROOF_MARKER]: authorization_header_injected=true token_nonempty=true\n```\n\ncontrol (expected: explicit Authorization header disables auto-injection):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake control\n```\n\nexpected output includes:\n\n```\n[CALLSITE_HIT]: executor.addHTTPHeaders Authorization!=\"\" -\u003e autoinject_skipped=true\n[NC_MARKER]: authorization_header_injected=false\n```\n\noptional: the canonical run may also print an `[RBAC]: ...` line using `kubectl auth can-i` with the exfiltrated token, to show concrete privileges without exposing the token.\n\n## impact\n\ntoken exfiltration: the kyverno controller serviceaccount token is sent to a policy-controlled endpoint. impact depends on the rbac bound to that serviceaccount in the target deployment.\n\n## recommended fix\n\ndo not auto-inject the kyverno serviceaccount token into policy-controlled servicecall requests. require explicit Authorization configuration, or enforce a strict allowlist of destinations where credentials may be attached and document the behavior.\n\n## workarounds\n\n- avoid using servicecall to arbitrary urls in policies.\n- set an explicit Authorization header in servicecall policies to prevent implicit token injection.\n\n\n[poc.zip](https://github.com/user-attachments/files/25352288/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25352289/PR_DESCRIPTION.md)\n\noleh",
"id": "GHSA-q93q-v844-jrqp",
"modified": "2026-04-24T21:10:06Z",
"published": "2026-04-14T20:09:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-q93q-v844-jrqp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40868"
},
{
"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:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "kyverno apicall servicecall implicit bearer token injection leaks kyverno serviceaccount token"
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.