External risk intelligence

Fission Kubernetes Serverless Framework Privilege Escalation Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-50566

A critical vulnerability in the Fission Kubernetes serverless framework allows authenticated users with specific RBAC permissions to run privileged containers. This could enable container escape, granting access to the host filesystem and network, potentially leading to node or cluster compromise.

1Halo Surface Signal

External exposure likelihood

Halo Surface Signal score for CVE-2026-50566

This vulnerability requires an authenticated tenant with specific RBAC permissions within a Kubernetes cluster to exploit. The attack vector is internal to the cluster management layer and requires existing access to the Fission framework, making it highly unlikely to be reachable from the public internet.

PCI scan relevance

PCI Relevance for CVE-2026-50566

Yes

CVE-2026-50566 — Halo PCI Relevance: Yes. Under typical PCI ASV external scan criteria, this issue may be flagged for scan prioritization.

This vulnerability allows for container-sandbox escape and host filesystem access, which could lead to cluster-level compromise and would likely cause a PCI ASV scan to fail.

Scan-prioritization guidance only—not a PCI DSS certification or ASV attestation.

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability exists in the Fission serverless framework, affecting deployments on Kubernetes. If exploited, it could allow unauthorized access to sensitive host system resources, potentially leading to a compromise of the entire node or cluster. The main concern is confirming relevance and exposure.

Allows privileged container escape.
Impacts Kubernetes cluster security.
Assess Fission framework exposure.

Attack Path

How an attacker could exploit the issue

An attacker with existing access to a Kubernetes cluster and the ability to create or update environments within Fission could potentially run privileged containers. These containers, scheduled with elevated permissions by Fission's executor, could break out of their sandbox, gaining access to the host system's files and network, and potentially compromising the entire node or cluster.

Authenticated tenant with specific RBAC.
Running a privileged container.
Potential for node and cluster compromise.

Live Threat

Current exploitation, exposure, and threat context

A tenant with specific Kubernetes RBAC permissions could run privileged containers within the Fission function or builder namespace. This could allow these containers to escape their sandbox, potentially gaining access to the host filesystem and network, which could lead to node or cluster-level compromise when supported by the advisory.

Cluster node and network access.
Container sandbox escape.
Potential cluster compromise.

Priority actions

Operational Fix

Recommended remediation, mitigation, and detection steps

Security and Platform Engineering teams are likely responsible for addressing this vulnerability, given its impact on the Kubernetes-native Fission framework. The first practical step involves identifying all Fission deployments within your environment, confirming their exposure and criticality, and then coordinating with the accountable application or platform owners to plan remediation, which may involve vendor coordination or careful maintenance window planning.

Platform and Security teams should own.
Verify Fission deployment reachability and criticality.
Plan coordinated remediation actions.

Frequently asked questions

What is Fission?

Fission is an open-source framework built for Kubernetes. It simplifies how developers deploy serverless functions and applications, allowing code to run without managing the underlying infrastructure. It is designed to handle the complexity of scheduling and executing tasks natively within a Kubernetes environment.

What is the vulnerability in CVE-2026-50566?

This vulnerability involves an issue with privilege assignment, classified as CWE-250 and CWE-269. Essentially, Fission allows certain users to launch containers with dangerous, elevated privileges. These containers can break out of their intended sandbox, gaining unauthorized access to the host's files and network, which could potentially grant control over the entire cluster.

How does an attacker trigger this issue?

An attacker must already have authenticated access to the Kubernetes cluster with specific permissions to create or update Fission environments. Simply using Fission to run standard, non-privileged functions does not trigger this vulnerability. The risk specifically arises when a user is able to define and run containers that intentionally use high-privilege settings.

Is my cluster at risk if it isn't internet-facing?

According to Halo Surface Signal, this vulnerability is considered very unlikely to be reachable from the public internet. Because the attack requires specific internal RBAC permissions and existing access to the Fission framework, it is an internal management layer issue rather than a standard web-facing exploit.

What should I do to address this CVE?

The primary fix is to update your Fission deployment to version 1.24.0 or later. Before patching, identify all instances of Fission running in your environment to understand your current footprint. Coordinate with your platform and security teams to verify your configurations and schedule the necessary maintenance to apply the update.

References

Written by Nicholas Merritt

External-surface CVE analysis and Halo Surface Signal prioritization for Halo Threat Intelligence.