Skip to content

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

Critical severity GitHub Reviewed Published May 26, 2026 in fission/fission

Package

gomod github.com/fission/fission (Go)

Affected versions

<= 1.23.0

Patched versions

1.24.0

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

References

@sanketsudake sanketsudake published to fission/fission May 26, 2026
Published by the National Vulnerability Database Jun 10, 2026
Published to the GitHub Advisory Database Jun 30, 2026
Reviewed Jun 30, 2026

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(21st percentile)

Weaknesses

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. Learn more on MITRE.

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. Learn more on MITRE.

CVE ID

CVE-2026-50566

GHSA ID

GHSA-m63v-2g9w-2w6v

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.