GHSA-m63v-2g9w-2w6v CVE-2026-50566 GO-2026-5857
Fission: Environment Runtime.Container and Builder.Container SecurityContext bypass allows privileged pod creation
- Severity
- 9.9 / 10
- Critical · CVSS 3.1
- Exploit chance (EPSS)
- 0.29%
- Chance of exploitation in the next 30 days. Higher than 21.61% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
1.24.0- Upgrade github.com/fission/fission to this version or later
Description
Summary
A follow-up bypass of the round-4 PodSpec hardening (GHSA-gx55-f84r-v3r7, GHSA-wmgg-3p4h-48x7, GHSA-v455-mv2v-5g92). Those advisories validate and sanitize the PodSpec (spec.runtime.podSpec / spec.builder.podSpec /
function.spec.podSpec), but the Environment CRD also exposes spec.runtime.container and spec.builder.container — a standalone Container merged into the runtime/builder pod whose SecurityContext bypassed both layers.
Details
Admission-layer gap. Environment.Validate() calls ValidatePodSpecSafety() on Runtime.PodSpec and Builder.PodSpec only. That function takes a *PodSpec, so it never inspects the standalone Runtime.Container.SecurityContext
or Builder.Container.SecurityContext.
Merge-layer gap. sanitizeContainerSecurityContext() ran only inside MergePodSpec(). The container field is merged via MergeContainer(), which did not sanitize. With only Runtime.Container set and Runtime.PodSpec nil,
MergePodSpec is never invoked, so the sanitizer never ran.
Affected merge sites: poolmgr (gp_deployment.go), newdeploy (newdeploy.go), and buildermgr (envwatcher.go).
Proof of concept
apiVersion: fission.io/v1
kind: Environment
metadata:
name: priv-escape-test
namespace: default
spec:
version: 3
runtime:
image: "ghcr.io/fission/python-env:latest"
container:
name: priv-escape-test
securityContext:
privileged: true
poolsize: 1
The admission webhook accepts this Environment and the resulting pool pod runs with privileged: true. Equivalent bypasses: allowPrivilegeEscalation: true, capabilities.add: ["SYS_ADMIN"], capabilities.add: ["NET_ADMIN","SYS_PTRACE"]. The same attack applies to Builder.Container.
Impact
A tenant with environments.fission.io create/update RBAC can run privileged / allowPrivilegeEscalation / dangerous-capability containers in the Fission function or builder namespace, scheduled under the executor's high-privilege
service account — enabling container-sandbox escape, host filesystem and network access, and potential node- and cluster-level compromise. Identical blast radius to GHSA-gx55-f84r-v3r7.
Fix
Fixed in #3406 and released in v1.24.0.
- Admission layer (primary defence): a new
ValidateContainerSafetyinpkg/apis/core/v1/podspec_safety.goapplies the per-container SecurityContext denylist (privileged,allowPrivilegeEscalation, dangerous capabilities) to a standalone container, and is called fromEnvironment.Validate()forRuntime.ContainerandBuilder.Container. - Merge layer (defence in depth):
sanitizeContainerSecurityContext()is now invoked insideMergeContainer()itself, covering all three executor/builder call sites.
Workarounds
- Restrict Environment create/update RBAC to trusted administrators.
- Deploy a Kyverno / OPA Gatekeeper policy rejecting dangerous Container SecurityContext on Environment CRDs.
- Label the function/builder namespaces with
pod-security.kubernetes.io/enforce: restricted.
References
- GHSA-gx55-f84r-v3r7, GHSA-wmgg-3p4h-48x7, GHSA-v455-mv2v-5g92 — the round-4 PodSpec fixes this advisory bypasses (#3391,
e484df84).
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 9.9
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- High
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.
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-8wcj-mfrc-jx5q Fission builder pods auto-mount the fission-builder ServiceAccount token in the user-supplied builder container | Medium | 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