CVE-2026-50565: Fission Information Disclosure Flaw

CVE-2026-50565 Overview

CVE-2026-50565 affects Fission, an open-source Kubernetes-native serverless framework for deploying functions and applications. Versions prior to 1.24.0 create builder pods with ServiceAccountName: fission-builder without setting AutomountServiceAccountToken: false. The kubelet auto-mounts the service account token into every container in the pod, including the user-supplied builder image. An attacker with control over a builder image can read this token and act with the privileges of the fission-builder service account. The issue is fixed in version 1.24.0. This weakness is classified under [CWE-250: Execution with Unnecessary Privileges].

Critical Impact
A malicious or compromised builder image can exfiltrate the auto-mounted Kubernetes service account token and authenticate to the cluster API as fission-builder, exposing in-cluster resources.

Affected Products

Fission (Kubernetes-native serverless framework) versions prior to 1.24.0
Fission builder pods using the fission-builder ServiceAccount
Kubernetes clusters running vulnerable Fission deployments

Discovery Timeline

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

Technical Details for CVE-2026-50565

Vulnerability Analysis

Fission creates builder pods to compile user source code into deployable function artifacts. These pods run under the fission-builder ServiceAccount. Kubernetes mounts the associated token into every container in the pod by default unless automountServiceAccountToken: false is set on the pod or service account. Fission did not set this field on builder pods before version 1.24.0. The builder container runs a user-supplied image, which means untrusted code executes alongside a mounted credential at /var/run/secrets/kubernetes.io/serviceaccount/token. Code inside that image can read the token and call the Kubernetes API as fission-builder. The impact depends on the roles bound to that ServiceAccount, but any access beyond minimum requirements becomes attacker-reachable.

Root Cause

The root cause is missing least-privilege configuration on builder pod specs. Fission relied on Kubernetes defaults, which auto-mount service account tokens. The framework did not explicitly disable token automounting on builder pods that execute untrusted code, violating the principle of running with minimum necessary privilege.

Attack Vector

An attacker requires high privileges to supply or modify a builder image used by Fission. Once that image runs as a builder pod, embedded code reads the mounted token file and uses it to authenticate against the Kubernetes API server. The attacker can then enumerate or access resources permitted to the fission-builder ServiceAccount over the network from inside the cluster. No user interaction is required after the malicious image is scheduled.

No verified proof-of-concept code is published. See the GitHub Security Advisory GHSA-8wcj-mfrc-jx5q and the GitHub Pull Request for technical details on the fix.

Detection Methods for CVE-2026-50565

Indicators of Compromise

Builder pods running Fission versions earlier than 1.24.0 with no automountServiceAccountToken: false field set on the pod spec or fission-builder ServiceAccount.
Unexpected Kubernetes API requests authenticating as system:serviceaccount:<namespace>:fission-builder originating from builder pod IP ranges.
Outbound network connections from builder containers to the cluster API endpoint outside of normal build operations.

Detection Strategies

Audit pod specs in namespaces running Fission for the automountServiceAccountToken field and flag builder pods that omit it or set it to true.
Enable Kubernetes audit logging at the Metadata or RequestResponse level and alert on API calls authenticated by the fission-builder ServiceAccount that exceed expected build workflows.
Inspect RoleBindings and ClusterRoleBindings referencing fission-builder to map blast radius if the token is exfiltrated.

Monitoring Recommendations

Forward Kubernetes audit logs and pod runtime telemetry to a centralized analytics platform and correlate builder pod activity with API server authentication events.
Monitor container processes for reads of /var/run/secrets/kubernetes.io/serviceaccount/token from images that should not require API access.
Track Fission version inventory across clusters and alert when nodes run releases earlier than 1.24.0.

How to Mitigate CVE-2026-50565

Immediate Actions Required

Upgrade Fission to version 1.24.0 or later in all clusters running the framework.
Review and tighten the RBAC permissions bound to the fission-builder ServiceAccount to enforce least privilege.
Restrict who can submit builder images by limiting access to Fission build APIs to trusted developers.

Patch Information

The fix is shipped in Fission 1.24.0, which sets AutomountServiceAccountToken: false on builder pods so the kubelet no longer mounts the token into user-supplied containers. See the GitHub Release v1.24.0 and the corresponding GitHub Pull Request for the code change.

Workarounds

Patch the fission-builder ServiceAccount manifest to set automountServiceAccountToken: false until the cluster can be upgraded.
Apply a Kubernetes admission policy (for example, an OPA Gatekeeper or Kyverno rule) that rejects builder pods unless token automounting is explicitly disabled.
Reduce the RBAC scope of the fission-builder ServiceAccount to the minimum required for builder operations.

bash

# Configuration example: disable token automounting on the fission-builder ServiceAccount
kubectl patch serviceaccount fission-builder \
  -n fission \
  -p '{"automountServiceAccountToken": false}'