CVE-2026-50565Medium· 4.9▾ SunlitFission builder pods auto-mount the fission-builder ServiceAccount token in the user-supplied builder container
▾ Sunlit zone — Low / medium · no exploitation signal
impact 27 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 4.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.3%
0.3% → 0.3%
Fission builder pods were created with ServiceAccountName: fission-builder and no AutomountServiceAccountToken: false, so the kubelet auto-mounted the service-account token into every container in the pod — including the
user-supplied builder image.
The user controls the builder container image, command, and podspec through Environment.spec.builder.image / .container / .podspec. With the SA token auto-mounted at /var/run/secrets/kubernetes.io/serviceaccount/token inside that
container, any code running there inherited the fission-builder identity. The fission-builder SA holds namespace-wide get on secrets and configmaps (pkg/utils/serviceaccount.go), so the user-controlled builder container
could read every Secret in the builder namespace by name.
This is 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.
A subject with create/update on Environment CRDs in a namespace observed by the buildermgr could read every Secret and ConfigMap in the builder namespace via the auto-mounted fission-builder token.
Fixed in #3390 and released in v1.24.0. In createBuilderDeployment:
AutomountServiceAccountToken=false on the initial PodSpec and add the projected fetcher SA-token volume.AutomountServiceAccountToken=false after every MergePodSpec call so a user-supplied podspec cannot restore the kubelet automount.Reuses the projected-volume helpers from pkg/executor/util/satoken.go introduced by the GHSA-85g2-pmrx-r49q fix.
The user-supplied builder container no longer receives an auto-mounted SA token. The fetcher sidecar still gets its token via a projected volume.
github.com/fission/fission <= 1.23.0Upgrade to a patched release:
github.com/fission/fission 1.24.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-50545Critical· 9.9Fission Environment CRD PodSpec Injection Leading to Node Escape and Cluster Takeover
CVE-2026-50566Critical· 9.9Fission: Environment Runtime.Container and Builder.Container SecurityContext bypass allows privileged pod creation
GHSA-7m8x-qg2j-4m3vHigh· 8.1Fission: MessageQueueTrigger scaler manager materializes Secret values into Deployment envvars and accepts arbitrary user PodSpec
CVE-2026-50563Critical· 9.9Fission Container Executor Function PodSpec Injection Leading to Node Escape
CVE-2026-50564Critical· 9.9Fission Environment CRD podspec passthrough enables hostPID/hostNetwork/privileged pods, node escape
CVE-2026-50570High· 8.5Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption