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, all 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, represents the fourth documented bypass of Fission's container security hardening, revealing a systemic gap in how the project validates user-supplied container configurations before translating them into pod specifications.

Fission is an open-source, Kubernetes-native serverless framework that allows developers to 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. Originally created by Platform9, Fission occupies a niche alongside projects like Knative and OpenFaaS as infrastructure that bridges 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, however, was left entirely unprotected. This created two specific code gaps that together enable the exploit.

Gap 1: Admission Layer

The Environment.Validate() method calls ValidatePodSpecSafety() exclusively on PodSpec fields. The standalone Container.SecurityContext field exposed via spec.runtime.container and spec.builder.container is never inspected during admission validation. When an attacker submits an Environment resource with a malicious Container.SecurityContext, it passes validation without triggering any security checks.

Gap 2: Merge Layer

The sanitizeContainerSecurityContext() function ran only inside MergePodSpec(). This is the critical detail: when a user sets Runtime.Container while Runtime.PodSpec is nil, MergePodSpec() is never invoked. The MergeContainer() function, which handles the container merge path in this scenario, performed no sanitization whatsoever. Dangerous SecurityContext values propagate unmodified into the resulting pod specification that the executor creates.

Attack Flow

The exploitation path is direct and requires 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 key payload is 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 via kubectl or the Fission CLI. The admission webhook calls Environment.Validate(), which only checks PodSpec fields. The malicious Container SecurityContext is not inspected, and the resource is accepted.

Step 3: When a function or builder pod is created using 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. From here, standard container escape techniques apply: mounting the host filesystem, accessing the host network stack, reading Kubernetes secrets via 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, reveals that Fission runtime pods automount the fission-fetcher service-account token into user function containers. This grants function code namespace-wide secret and configmap read access. The combination of both CVEs creates a compound attack path: CVE-2026-50566 provides the container escape and host-level access, while 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 exceeding 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 (which is the standard deployment model).
• At least one principal has RBAC permissions to create or update environments.fission.io resources.
• The executor's service account retains its default high-privilege configuration.

The fix was released in Fission v1.24.0 on May 26, 2026 (commit ce61712). The patch was delivered via Pull Request #3406, which implements both 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 this as a critical priority for remediation. Three workarounds are available for those unable to upgrade immediately: restricting environments.fission.io RBAC to trusted administrators, deploying Kyverno or OPA Gatekeeper policies to reject dangerous Container SecurityContexts on Environment CRDs, and labeling function/builder namespaces with pod-security.kubernetes.io/enforce: restricted.

Vendor Security History

CVE-2026-50566 is part of a documented pattern of security hardening bypasses in Fission. The advisory explicitly describes this vulnerability as "a follow-up bypass of the round-4 PodSpec hardening," referencing three prior advisories:

Each prior hardening round addressed the specific bypass vector reported but failed to comprehensively audit all configuration paths that feed into pod creation. The Container path (spec.runtime.container and spec.builder.container) was left unprotected through all four rounds of fixes.

Beyond the SecurityContext bypass pattern, multiple additional Fission CVEs were disclosed concurrently in May 2026:

• 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, which is a positive development, but also indicates that significant vulnerabilities had been present across multiple releases. The project appears to rely primarily on external security researchers for vulnerability discovery rather than maintaining 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