External risk intelligence

Fission Container Executor PodSpec Injection Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-50563

A critical vulnerability in Fission, a Kubernetes-native serverless framework, allows authenticated users to inject malicious specifications into container execution. This could lead to unauthorized code execution or access to cluster resources. The issue is present in versions prior to 1.24.0, and has been patched in

3Halo Surface Signal

External exposure likelihood

Halo Surface Signal score for CVE-2026-50563

Fission is a Kubernetes-native serverless framework. This vulnerability exists within the container executor path where authenticated tenants define pod specifications. Access typically requires internal authorization within the Kubernetes cluster, making direct public internet exposure uncommon, though the framework itself is designed for function deployment.

PCI scan relevance

PCI Relevance for CVE-2026-50563

Yes

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

This vulnerability in Fission's container executor allows a tenant to supply a Function.spec.podspec directly, potentially leading to unauthorized access and modification of data. It impacts versions prior to 1.24.0 and is critical due to its network-accessible nature and severe

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

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a critical vulnerability within the Fission open-source serverless framework for Kubernetes. The issue allows authenticated users to potentially execute arbitrary code by manipulating container specifications. While direct external exposure is less likely, the framework's function is to deploy code, making this a significant internal risk if not properly managed.

Fission allows code execution via container settings.
Critical flaw impacts Kubernetes serverless deployments.
Confirm relevance and assess internal exposure.

Attack Path

How an attacker could exploit the issue

An attacker with authenticated access to a Kubernetes cluster running Fission could leverage this vulnerability by supplying a custom pod specification. This allows the attacker to influence the pods created by Fission's Container Executor, potentially leading to elevated privileges or execution of unintended code within the cluster.

Authenticated access to Kubernetes cluster required.
Tenant supplies custom pod specification.
Risk of unauthorized code execution.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, a tenant could potentially gain unauthorized access to Kubernetes cluster resources and data by supplying a custom pod specification. This could lead to significant disruption of service behavior and exposure of sensitive information within the cluster.

Unauthorized access to cluster resources.
Tenant supplies custom pod specification.
Compromise of service integrity and data.

Priority actions

Operational Fix

Recommended remediation, mitigation, and detection steps

This critical vulnerability in Fission's Container Executor impacts deployments where tenants can supply `Function.spec.podspec` directly, allowing for potential code execution within the executor-built podspec. Given Fission's role as a Kubernetes-native serverless framework, the platform or infrastructure teams managing Kubernetes deployments are likely responsible for assessing and remediating this issue. The first practical step involves identifying all Fission deployments, determining their reachability and business criticality, locating the accountable owner for each instance, and then prioritizing remediation efforts based on risk.

Platform/Infrastructure teams own the fix.
Verify Fission deployments and their reachability.
Plan remediation based on identified risk.

Frequently asked questions

What is Fission and how does it work?

Fission is an open-source, serverless framework built specifically for Kubernetes. It is designed to simplify the process of deploying and managing code functions or applications in containerized environments. By abstracting away much of the underlying infrastructure complexity, it allows developers to focus on writing code that executes on-demand within a cluster.

What is the vulnerability in CVE-2026-50563?

This vulnerability involves Improper Privilege Management and Improper Access Control (CWE-269 and CWE-284). It stems from how Fission’s Container Executor handles user-provided pod specifications. Because the executor merges these custom settings into the pod configuration without sufficient restrictions, it allows a user to influence how containers are created and run, potentially leading to unauthorized code execution.

How can an attacker trigger this Fission vulnerability?

An attacker needs authenticated access to the Kubernetes cluster to exploit this. They trigger the flaw by supplying a malicious `Function.spec.podspec` when deploying or configuring a function. This bug is not triggered by standard public access to the finished function endpoints; it requires the ability to interact with the Fission deployment process to inject custom container specifications.

Is my Fission deployment at risk?

According to Halo Surface Signal, this vulnerability is most relevant to those running Fission where tenants have authorization to define pod specifications. While direct public internet exposure is less common because the vulnerability requires internal Kubernetes authorization, any cluster where users can submit custom function specifications is a target for privilege escalation.

How do I secure my environment against this flaw?

The primary response is to update your Fission installation to version 1.24.0 or later, which contains the fix for the Container Executor path. Infrastructure teams should first inventory all active Fission instances, assess which environments allow tenant-provided pod specifications, and prioritize updating these instances to eliminate the possibility of unauthorized pod configuration manipulation.

References

Written by Nicholas Merritt

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