critical · 9.9CVE-2026-50566Jun 30, 2026

CVE-2026-50566: Fission Environment Container SecurityContext Bypass Allows Privileged Pod Creation

Rohit Hatagale
AI Security Researcher, SecureLayer7

A gap in Fission's admission and merge-layer validation lets any tenant with Environment create/update access spin up fully privileged Kubernetes pods, enabling container escape and potential cluster

Packagegithub.com/fission/fission
Ecosystemgo
Affected<= 1.23.0
Fixed in1.24.0

The problem

Fission's `Environment.Validate()` called `ValidatePodSpecSafety()` only on `Runtime.PodSpec` and `Builder.PodSpec`. The standalone `Runtime.Container` and `Builder.Container` fields, which carry their own `SecurityContext`, were never inspected at the admission layer.

The merge-layer sanitizer (`sanitizeContainerSecurityContext`) ran only inside `MergePodSpec()`. When only `Runtime.Container` was set and `Runtime.PodSpec` was nil, `MergePodSpec` was never called, so the sanitizer never ran either. This left three executor/builder call sites (`gp_deployment.go`, `newdeploy.go`, `envwatcher.go`) fully exposed.

Proof of concept

A working proof-of-concept for CVE-2026-50566 in github.com/fission/fission, with the exact payload below.

text
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 payload sets `spec.runtime.container.securityContext.privileged: true` without touching `spec.runtime.podSpec` at all. Because `Environment.Validate()` only passed a `*PodSpec` to `ValidatePodSpecSafety()`, the standalone container field was invisible to the checker.

With `PodSpec` nil, `MergePodSpec` was never invoked, so `sanitizeContainerSecurityContext` also never ran, and the privileged flag reached the pool pod unchanged.

Equivalent bypasses using the same gap include `allowPrivilegeEscalation: true` and `capabilities.add: ["SYS_ADMIN"]` or `["NET_ADMIN","SYS_PTRACE"]`. The same attack path works via `spec.builder.container`.

PR #3406 closed both holes: a new `ValidateContainerSafety` function in `pkg/apis/core/v1/podspec_safety.go` applies the SecurityContext denylist to standalone containers at admission time, and `sanitizeContainerSecurityContext` was moved into `MergeContainer()` itself so all three call sites are covered regardless of whether a PodSpec is present.

The fix

Upgrade to Fission v1.24.0 (commit 695d3e97, PR #3406). Until you can upgrade, restrict Environment create/update RBAC to trusted administrators only, and enforce a Kyverno or OPA Gatekeeper policy rejecting dangerous `SecurityContext` fields on Environment CRDs.

Labelling function/builder namespaces with `pod-security.kubernetes.io/enforce: restricted` adds a further layer of defence.

Reported by sanketsudake.

References: [1][2][3][4][5][6]

Related research