Brief Summary: CVE-2026-50566 — Fission Kubernetes Serverless Framework SecurityContext Bypass Enables Cluster Compromise

Introduction

A tenant in a multi-tenant Kubernetes cluster running Fission can escalate from serverless function deployment privileges to full node and cluster compromise by setting a single field on a Custom Resource that the framework's security hardening never thought to check. CVE-2026-50566, scored at CVSS 9.9, is the fourth documented bypass of Fission's container security hardening. It points to a systemic gap in how the project validates user-supplied container configurations before turning them into pod specifications.

Fission is an open-source, Kubernetes-native serverless framework that lets developers write short-lived functions in any language and map them to HTTP requests or event triggers. With approximately 8,900 GitHub stars and 786 forks, it has moderate-to-strong adoption in the Kubernetes serverless ecosystem. Platform9 originally created Fission, and it sits alongside projects like Knative and OpenFaaS as infrastructure between developer experience and Kubernetes orchestration.

Technical Information

Root Cause: Dual Configuration Surfaces, Single Validation Path

The Fission Environment CRD exposes two distinct paths for configuring how function and builder containers behave:

1. PodSpec path: spec.runtime.podSpec and spec.builder.podSpec
2. Container path: spec.runtime.container and spec.builder.container

Prior hardening rounds (documented in advisories GHSA-gx55-f84r-v3r7, GHSA-wmgg-3p4h-48x7, and GHSA-v455-mv2v-5g92) added validation and sanitization for the PodSpec path. The Container path got none of it. That left two specific code gaps, which together enable the exploit.

Gap 1: Admission Layer

The Environment.Validate() method calls ValidatePodSpecSafety() only on PodSpec fields. Admission validation never inspects the standalone Container.SecurityContext field exposed through spec.runtime.container and spec.builder.container. An Environment resource with a malicious Container.SecurityContext passes validation without triggering any security checks.

Gap 2: Merge Layer

The sanitizeContainerSecurityContext() function ran only inside MergePodSpec(), and when a user sets Runtime.Container while Runtime.PodSpec is nil, MergePodSpec() is never invoked. In that case MergeContainer() handles the container merge, and it performed no sanitization at all. Dangerous SecurityContext values pass unmodified into the pod specification that the executor creates.

Attack Flow

Exploitation is direct and needs no sophisticated tooling:

Step 1: The attacker, who holds RBAC permissions to create or update environments.fission.io resources, crafts a Fission Environment resource. The payload sits in the runtime.container.securityContext field, set to privileged: true, allowPrivilegeEscalation: true, or capabilities.add: ["SYS_ADMIN"] (or other dangerous Linux capabilities).

Step 2: The attacker applies this Environment resource with kubectl or the Fission CLI. The admission webhook calls Environment.Validate(), which checks only PodSpec fields. Nothing inspects the malicious Container SecurityContext, and the resource is accepted.

Step 3: When a function or builder pod is created from this Environment, the executor merges the container configuration. Because Runtime.PodSpec is nil, MergePodSpec() is skipped and MergeContainer() runs without sanitization. The resulting pod inherits the dangerous SecurityContext and runs under the executor's high-privilege service account.

Step 4: The attacker now has a fully privileged container. Standard container escape techniques apply from here: mounting the host filesystem, accessing the host network stack, reading Kubernetes secrets through the executor service account, and pivoting to other nodes in the cluster.

Compound Risk with CVE-2026-46617

A concurrently disclosed vulnerability, CVE-2026-46617, shows that Fission runtime pods automount the fission-fetcher service-account token into user function containers. This gives function code namespace-wide read access to secrets and configmaps. Together the two CVEs form a compound attack path. CVE-2026-50566 provides the container escape and host-level access, and CVE-2026-46617 provides credential material for further lateral movement within the Kubernetes namespace.

Classification

The vulnerability is classified under two CWEs:

• CWE-250 (Execution with Unnecessary Privileges): The resulting pod runs with privileges far beyond what a serverless function requires.
• CWE-269 (Improper Privilege Management): The framework fails to enforce privilege restrictions across all configuration paths.

Affected Systems and Versions

All versions of Fission prior to v1.24.0 are affected. The vulnerability exists in any Fission installation where:

• The Fission Environment CRD is in use (the standard deployment model).
• At least one principal has RBAC permissions to create or update environments.fission.io resources.
• The executor's service account keeps its default high-privilege configuration.

The fix shipped in Fission v1.24.0 on May 26, 2026 (commit ce61712). It arrived through Pull Request #3406, which adds a new ValidateContainerSafety function at the admission layer and sanitization within MergeContainer() at the merge layer.

Organizations running any Fission version below 1.24.0 should treat remediation as a critical priority. For those who cannot upgrade immediately, three workarounds are available:

• Restrict environments.fission.io RBAC to trusted administrators.
• Deploy Kyverno or OPA Gatekeeper policies that reject dangerous Container SecurityContexts on Environment CRDs.
• Label function/builder namespaces with pod-security.kubernetes.io/enforce: restricted.

Vendor Security History

CVE-2026-50566 belongs to a documented pattern of security hardening bypasses in Fission. The advisory describes it as "a follow-up bypass of the round-4 PodSpec hardening" and references three prior advisories:

Each prior hardening round fixed the specific bypass vector reported but did not audit every configuration path that feeds into pod creation. The Container path (spec.runtime.container and spec.builder.container) stayed unprotected through all four rounds of fixes.

Several other Fission CVEs were disclosed in the same May 2026 window:

• CVE-2026-46612 (GHSA-chf8-4hv6-8pg6): StorageSvc /v1/archive endpoint exposes unauthenticated CRUD operations.
• CVE-2026-46614 (GHSA-3g33-6vg6-27m8): Router exposes /fission-function/ on its public listener.
• CVE-2026-46617: Runtime pods automount the fission-fetcher service-account token into user function containers.

This cluster of disclosures suggests an ongoing security audit of the project. That is a good sign, but it also indicates that significant vulnerabilities had been present across multiple releases. The project appears to rely mainly on external security researchers to find vulnerabilities rather than on a formal internal security audit process.

References

• NVD Entry for CVE-2026-50566
• GitHub Security Advisory GHSA-m63v-2g9w-2w6v
• Pull Request #3406: fix(security): validate Runtime/Builder Container SecurityContext
• Fission v1.24.0 Release
• Fission GitHub Repository
• CVE-2026-46617 Advisory (GitLab)
• GHSA-chf8-4hv6-8pg6: Fission StorageSvc Unauthenticated CRUD
• GHSA-3g33-6vg6-27m8: Fission Router Public Endpoint Exposure
• CISA Known Exploited Vulnerabilities Catalog
• Proofpoint: 2026 Vulnerability Exploitation in the Wild
• SentinelOne: Kubernetes Privilege Escalation Patterns
• Fission PodSpec Documentation