Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-50564

CVE-2026-50564: Fission Privilege Escalation Vulnerability

CVE-2026-50564 is a privilege escalation vulnerability in Fission's Kubernetes-native serverless framework that allows unauthorized pod specification modifications. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-50564 Overview

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. CVE-2026-50564 is a privilege escalation vulnerability [CWE-269] affecting Fission versions prior to 1.24.0. The Environment Custom Resource Definition (CRD) exposes spec.runtime.podSpec and spec.builder.podSpec, which Fission merges into Kubernetes pod specifications for runtime and builder pods. The merge logic propagates hostNetwork, hostPID, hostIPC, container privileged, and serviceAccountName from user-supplied PodSpecs without filtering. The Environment.Validate function performs no security checks on these fields. An authenticated user with permission to create Environment resources can escalate to cluster-level access.

Critical Impact

An attacker with low-privilege Environment CRD access can spawn privileged pods that share the host network, PID, and IPC namespaces, breaking Kubernetes namespace isolation and enabling full node and cluster compromise.

Affected Products

  • Fission versions prior to 1.24.0
  • Fission Environment CRD spec.runtime.podSpec handling
  • Fission Environment CRD spec.builder.podSpec handling

Discovery Timeline

  • 2026-06-10 - CVE-2026-50564 published to NVD
  • 2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-50564

Vulnerability Analysis

Fission allows users to define serverless function Environments through a Kubernetes CRD. The CRD includes optional spec.runtime.podSpec and spec.builder.podSpec fields that customize the underlying pods running user code. Fission merges these user-supplied PodSpecs directly into the templates used to launch runtime and builder workloads. The merge logic copies sensitive fields verbatim, including hostNetwork, hostPID, hostIPC, container securityContext.privileged, and serviceAccountName. None of these fields trigger validation or admission checks inside Environment.Validate. A tenant who can create or modify an Environment resource gains the ability to launch pods that bypass standard container isolation boundaries.

Root Cause

The root cause is improper privilege management [CWE-269] in the Environment merge path. Fission treats the user-supplied PodSpec as trusted configuration data rather than untrusted input requiring policy enforcement. Security-sensitive fields are not stripped, rejected, or constrained before the merged PodSpec reaches the Kubernetes API server.

Attack Vector

An attacker with permission to create Fission Environment resources submits a manifest that sets hostNetwork: true, hostPID: true, privileged: true, or assigns a high-privilege serviceAccountName. When Fission instantiates the runtime or builder pod, the resulting workload runs with host-level access to the underlying node. The attacker can then read host filesystems, inspect other containers, access kubelet credentials, or pivot to additional cluster resources. Because exploitation occurs entirely through standard Kubernetes API requests, no separate network exploit chain is required.

No public proof-of-concept code has been published. Refer to the GitHub Security Advisory GHSA-gx55-f84r-v3r7 for vendor-confirmed technical details.

Detection Methods for CVE-2026-50564

Indicators of Compromise

  • Fission Environment resources containing hostNetwork: true, hostPID: true, or hostIPC: true in spec.runtime.podSpec or spec.builder.podSpec
  • Runtime or builder pods running with securityContext.privileged: true that were not authorized by platform operators
  • Environment CRDs referencing serviceAccountName values tied to cluster-admin or other elevated roles
  • Unexpected outbound traffic from Fission runtime pods using the node's host network interface

Detection Strategies

  • Audit all Environment CRDs across cluster namespaces for the sensitive PodSpec fields listed above
  • Inspect Kubernetes API audit logs for create and update actions on environments.fission.io resources, correlating with the submitted PodSpec content
  • Deploy admission policies, such as Kyverno or OPA Gatekeeper, that flag pods spawned by Fission controllers carrying host-level namespaces or privileged containers

Monitoring Recommendations

  • Forward Kubernetes audit logs and Fission controller logs to a centralized analytics platform for continuous review
  • Alert on any pod creation in Fission-managed namespaces that sets privileged, hostNetwork, hostPID, or hostIPC
  • Track ServiceAccount token usage from runtime and builder pods to identify lateral movement attempts

How to Mitigate CVE-2026-50564

Immediate Actions Required

  • Upgrade Fission to version 1.24.0 or later, which removes propagation of the affected fields
  • Restrict RBAC permissions on the environments.fission.io resource to trusted operators only
  • Review existing Environment manifests and remove any unauthorized use of host namespaces, privileged containers, or elevated serviceAccountName values
  • Rotate ServiceAccount tokens and node credentials if unauthorized privileged pods are discovered

Patch Information

Fission release 1.24.0 patches the vulnerability by filtering sensitive fields from user-supplied PodSpecs during the merge process. See the GitHub Release v1.24.0 notes and the GitHub Pull Request that introduces the fix.

Workarounds

  • Apply a Kubernetes admission controller policy that rejects pods with hostNetwork, hostPID, hostIPC, or privileged: true in namespaces managed by Fission
  • Use Pod Security Admission with the restricted profile on Fission runtime and builder namespaces
  • Limit who can create or modify environments.fission.io resources through namespaced RBAC bindings
bash
# Example Kyverno policy fragment blocking host-level escalation in Fission pods
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-fission-host-escalation
spec:
  validationFailureAction: Enforce
  rules:
    - name: deny-host-namespaces-and-privileged
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces: ["fission-function", "fission-builder"]
      validate:
        message: "hostNetwork, hostPID, hostIPC, and privileged are not allowed."
        pattern:
          spec:
            =(hostNetwork): false
            =(hostPID): false
            =(hostIPC): false
            containers:
              - =(securityContext):
                  =(privileged): false

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.