GHSA-8wcj-mfrc-jx5q CVE-2026-50565 GO-2026-5850
Fission builder pods auto-mount the fission-builder ServiceAccount token in the user-supplied builder container
- Severity
- 4.9 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 0.26%
- Chance of exploitation in the next 30 days. Higher than 17.20% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-250 Execution with Unnecessary Privileges
- CWE-269 Improper Privilege Management
- CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory
- Fix
1.24.0- Upgrade github.com/fission/fission to this version or later
Description
Summary
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 versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/fission/fission | < 1.24.0 |
1.24.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
github.com/fission/fission Go → 1.24.0
- go
go get github.com/fission/fission@v1.24.0 && go mod tidy
Severity breakdown
CVSS 3.1 4.9
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- High
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-250: Execution with Unnecessary Privileges
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
How to prevent it
- Architecture and Design, Operation: Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
- Architecture and Design: Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.
- Architecture and Design: Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.
- Implementation: Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements.
- Implementation: When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed.
- Implementation: If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else [REF-76]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place.
- Operation, System Configuration: Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
CWE-269: Improper Privilege Management
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
How to prevent it
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
- Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
CWE-538: Insertion of Sensitive Information into Externally-Accessible File or Directory
The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.
How to prevent it
- Architecture and Design, Operation, System Configuration: Do not expose file and directory information to the user.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-7m8x-qg2j-4m3v Fission: MessageQueueTrigger scaler manager materializes Secret values into Deployment envvars and accepts arbitrary user PodSpec | High | Also affects github.com/fission/fission |
| GHSA-qf5v-m7p4-95rp Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption | High | Also affects github.com/fission/fission |
| GHSA-vchh-r53j-8mpw Fission: HTTPTrigger admission omits RelativeURL / Prefix validation; kubectl apply bypasses CLI checks | Medium | Also affects github.com/fission/fission |
| GHSA-r5jh-q2mw-gcx4 Fission: SanitizeFilePath lexical HasPrefix bypass permits sibling-directory escape | Low | Also affects github.com/fission/fission |
| GHSA-q6vm-xqc9-v3ff Fission: Zip Slip in pkg/utils/zip.go:Unarchive allows fetcher to write outside the destination directory | High | Also affects github.com/fission/fission |
| GHSA-m63v-2g9w-2w6v Fission: Environment Runtime.Container and Builder.Container SecurityContext bypass allows privileged pod creation | Critical | Also affects github.com/fission/fission |
| GHSA-gx55-f84r-v3r7 Fission Environment CRD podspec passthrough enables hostPID/hostNetwork/privileged pods, node escape | Critical | Also affects github.com/fission/fission |
| GHSA-v455-mv2v-5g92 Fission Container Executor Function PodSpec Injection Leading to Node Escape | Critical | Also affects github.com/fission/fission |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor