GHSA-8WCJ-MFRC-JX5Q
Vulnerability from github – Published: 2026-06-30 18:20 – Updated: 2026-06-30 18:20Summary
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.
Details
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.
Impact
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.
Fix
Fixed in #3390 and released in v1.24.0. In createBuilderDeployment:
- Set pod-level
AutomountServiceAccountToken=falseon the initial PodSpec and add the projected fetcher SA-token volume. - Re-clamp
AutomountServiceAccountToken=falseafter everyMergePodSpeccall 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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.23.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/fission/fission"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50565"
],
"database_specific": {
"cwe_ids": [
"CWE-250",
"CWE-269",
"CWE-538"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T18:20:03Z",
"nvd_published_at": "2026-06-10T18:17:12Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nFission 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 \u2014 including the\nuser-supplied builder image.\n\n### Details\n\nThe 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\n 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\ncould read every Secret in the builder namespace by name.\n\nThis 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`.\n\n### Impact\n\nA 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.\n\n### Fix\n\nFixed in [#3390](https://github.com/fission/fission/pull/3390) and released in [v1.24.0](https://github.com/fission/fission/releases/tag/v1.24.0). In `createBuilderDeployment`:\n\n- Set pod-level `AutomountServiceAccountToken=false` on the initial PodSpec and add the projected fetcher SA-token volume.\n- Re-clamp `AutomountServiceAccountToken=false` after every `MergePodSpec` call so a user-supplied podspec cannot restore the kubelet automount.\n- Mount the token via a projected volume on the fetcher sidecar only, so the legitimate build \u2192 archive-upload flow keeps its cluster API access.\n\nReuses the projected-volume helpers from `pkg/executor/util/satoken.go` introduced by the GHSA-85g2-pmrx-r49q fix.\n\n### Behavioural change\n\nThe user-supplied builder container no longer receives an auto-mounted SA token. The fetcher sidecar still gets its token via a projected volume.",
"id": "GHSA-8wcj-mfrc-jx5q",
"modified": "2026-06-30T18:20:03Z",
"published": "2026-06-30T18:20:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fission/fission/security/advisories/GHSA-8wcj-mfrc-jx5q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50565"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/pull/3390"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/commit/8fa799417c77ce8a0189d9858bfe11ece29b84a6"
},
{
"type": "PACKAGE",
"url": "https://github.com/fission/fission"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/releases/tag/v1.24.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Fission builder pods auto-mount the fission-builder ServiceAccount token in the user-supplied builder container"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.