Fission Environment CRD podspec passthrough enables Kubernetes host escape via privileged pod injection

Vulnerability Description

The vulnerability is a CRD validation bypass leading to arbitrary pod spec injection. Fission's Environment custom resource definition exposed spec.runtime.podSpec and spec.builder.podSpec fields intended for legitimate pod customization. However, the merge logic propagated security-critical pod attributes (hostNetwork, hostPID, hostIPC, container privileged mode, and serviceAccountName) without any filtering or admission validation. The Environment.Validate() webhook performed no checks on these fields, creating an unguarded escalation path from namespace-level RBAC (environments.fission.io create/update) to node-level compromise.

PoC Significance & Preconditions

An attacker requires only create or update permissions on environments.fission.io resources within a namespace—a role far less privileged than cluster-admin. The PoC demonstrates that by crafting a malicious Environment resource containing hostPID: true, hostNetwork: true, and privileged: true in the podspec, the admission controller would accept and merge these fields into actual Kubernetes pod specifications scheduled on worker nodes. No exploitation complexity exists; the vulnerability is reliably exploitable by any authenticated namespace user. The additional failure to apply Pod Security Admission labels (pod-security.kubernetes.io/enforce: restricted) to the fission-function and fission-builder namespaces during Helm chart installation removed a secondary containment layer.

Detection Guidance

Defenders should:

• Audit Environment CRDs: Query all environments.fission.io resources for hostPID, hostNetwork, hostIPC, or privileged fields in spec.runtime.podSpec or spec.builder.podSpec using kubectl get environments -o json | jq '.items[] | select(.spec.runtime.podSpec.hostPID==true or .spec.builder.podSpec.hostPID==true)'.
• Monitor pod creation: Alert on pods created in fission-function or fission-builder namespaces with hostPID, hostNetwork, or securityContext.privileged: true.
• RBAC audit logs: Review audit.k8s.io logs for create/update verbs on environments resources; correlate to subsequent pod creation events.
• Node escape indicators: Monitor for nsenter, unshare, or host filesystem mounts (/proc/1/root, /host) from containers in Fission namespaces.

Mitigation Steps

1. Immediate: Upgrade to Fission v1.24.0 or later, which implements admission denylist validation.
2. Short-term workaround (pre-patch): Apply Pod Security Admission labels to affected namespaces: kubectl label namespace fission-function fission-builder pod-security.kubernetes.io/enforce=restricted.
3. RBAC hardening: Restrict environments.fission.io create/update to service accounts and users who absolutely require it; use least-privilege role bindings.
4. Admission controller: Deploy a validating webhook (before patch) that rejects any Environment with security-sensitive pod fields set.
5. Network policies: Isolate Fission namespaces from host network access using Kubernetes NetworkPolicies.

Risk Assessment

This vulnerability has high exploitation likelihood in mixed-trust environments (multi-tenant clusters or those with delegated namespace management). Threat actors with namespace-level access—common in CI/CD platforms, managed Kubernetes services, or compromised applications—can directly escalate to node root. Cloud-native threat actors actively target Kubernetes control-plane escapes; node compromise enables lateral movement to metadata services, kubelet APIs, and cluster federation. Organizations running Fission on shared or untrusted infrastructure should treat this as an immediate patch priority. The combination of low exploitation complexity, pre-patch missing validation, and high blast radius (full node compromise) makes this a critical risk.