# Fission runtime pods automount the fission-fetcher service-account token into the user function container, granting function code namespace-wide secret / configmap read

Fission runtime pods mounted the fission-fetcher SA token into the user function container, letting function code read all namespace secrets and configmaps.

- Payout: Research
- Severity: high
- Program: Fission
- Found by: FORIMOC, nnin-nnin
- Disclosed: 2026-05-21
- CVE: CVE-2026-46617
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-85g2-pmrx-r49q
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-85g2-pmrx-r49q
- Tags: area:cloud domain:cloud impact:data-leak impact:internal-access kind:research platform:ghsa sev:high tech:kubernetes technique:source-review vuln:access-control vuln:privilege-escalation vuln:secrets-leak

**Target:** Kubernetes runtime pod / function container service-account token mount
**Root cause:** Runtime pods set ServiceAccountName: fission-fetcher, whose RBAC grants namespace-wide get on secrets/configmaps; Kubernetes automounts the token into every container in the pod, including the user function container.
**Steps:**
1. Deploy or update a Function in a namespace where Fission runtime pods run.
2. From inside the function code, read `/var/run/secrets/kubernetes.io/serviceaccount/token`.
3. Use the token against the Kubernetes API to `get` any secret or configmap in the namespace, bypassing the Function.spec.secrets allowlist.
**How found:** Code review of runtime pod specs (gp_deployment.go, newdeploy.go) and the fission-fetcher RBAC in serviceaccount.go, noticing the fetcher SA is pod-wide and its token is reachable from the user container.
**Exploitation:** Attacker with Function/Package create rights ships code that reads the automounted token and calls the K8s API to exfiltrate all namespace secrets (TLS keys, OIDC client secrets, DB and cloud credentials), then pivots to other resources or external systems.
**Escalation:** Harvested secrets enable lateral movement to other Kubernetes resources and external systems unlocked by those credentials.
**Insight:** When a sidecar needs a privileged SA, check whether the pod-level ServiceAccountName leaks that identity into untrusted containers; per-container token suppression via projected volumes is the fix, and Function.spec.secrets allowlists are meaningless if the pod token grants broader RBAC.