Skip to content

GHSA-m63v-2g9w-2w6v CVE-2026-50566 GO-2026-5857

Fission: Environment Runtime.Container and Builder.Container SecurityContext bypass allows privileged pod creation

Critical Go
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
Weakness
CWE-250 Execution with Unnecessary Privileges
CWE-269 Improper Privilege Management
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 ValidateContainerSafety in pkg/apis/core/v1/podspec_safety.go applies the per-container SecurityContext denylist (privileged, allowPrivilegeEscalation, dangerous capabilities) to a standalone container, and is called from Environment.Validate() for Runtime.Container and Builder.Container.
  • Merge layer (defence in depth): sanitizeContainerSecurityContext() is now invoked inside MergeContainer() 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

PackageVulnerableFixed 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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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
Is this in your code?

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