CVE-2026-50565: Fission Kubernetes Service Account Token Exposure

Technical summary

Prior to version 1.24.0, Fission's builder pod creation lacked the AutomountServiceAccountToken: false setting, causing the kubelet to automatically inject the fission-builder service account token into all containers within the pod, including user-defined builder images. This exposed the service account token as a readable file (typically at /var/run/secrets/kubernetes.io/serviceaccount/token) accessible to code executing inside the builder container. Given that service account tokens provide direct authentication to the Kubernetes API server, an attacker or compromised build image could use this token to interact with cluster resources according to the fission-builder role's permissions. The vulnerability is classified under improper privilege management (CWE-250), improper restriction of rendered UI layers (CWE-269), and sensitive information exposure (CWE-538).

Business impact

Organizations running Fission to orchestrate serverless workloads face a credential exposure risk during the function-building phase. If a user deploys a malicious or compromised builder image, or if a legitimate build process is intercepted, the attacker gains API credentials to the Kubernetes cluster. Depending on the fission-builder role's permissions, this could enable lateral movement, unauthorized cluster enumeration, secret extraction, or persistent access. In multi-tenant or shared Kubernetes environments, this exposure is particularly severe, as it could compromise cluster-wide security posture. Unpatched Fission deployments should be considered a priority for remediation, especially in production settings.

Affected systems

Fission versions prior to 1.24.0 are affected. The vulnerability impacts all Kubernetes clusters running vulnerable Fission versions, regardless of Kubernetes distribution (managed services, on-premises, or hybrid). Any organization using Fission to manage serverless functions is potentially at risk. Organizations running Fission 1.24.0 or later are not affected.

Exploitability

Exploitation requires high privilege (PR:H in the CVSS vector), meaning an attacker needs the ability to deploy or supply a builder image through Fission—typically a developer or operator role. No user interaction is needed, and the attack is network-accessible. Once a malicious or compromised image is supplied, the service account token is automatically available at runtime, making credential theft trivial. The attack surface is limited to users with the capability to trigger function builds, but in open-team or third-party function scenarios, this can be broad. Public exploit code is not known, though weaponization would be straightforward for anyone with basic Kubernetes API knowledge.

Remediation

Upgrade Fission to version 1.24.0 or later. Verify the upgrade by confirming that builder pod specifications include AutomountServiceAccountToken: false and that existing builder pods are recreated with the corrected configuration. In the interim, if upgrading is not immediately possible, manually review and restrict the fission-builder service account's RBAC permissions to the minimum required for your deployment, and limit which users can deploy functions to trusted operators only.

Patch guidance

Apply the Fission 1.24.0 release or any subsequent version. Consult the official Fission release notes and GitHub repository for download and installation instructions. Confirm via kubectl that builder pod templates no longer auto-mount the service account token (verify the pod spec includes automountServiceAccountToken: false). Test function builds after patching to ensure no regressions. For air-gapped or restricted environments, verify patch availability through your Fission mirror or distribution channel before planning upgrades.

Detection guidance

Audit existing Fission builder pods in your cluster using kubectl describe pod or examining pod YAML to check whether AutomountServiceAccountToken is explicitly set to false. Review RBAC bindings for the fission-builder service account to understand what API permissions are exposed. Monitor Kubernetes API audit logs for any suspicious activity using the fission-builder credentials, such as unexpected list, get, or watch operations. Examine function deployment workflows to identify any instances of user-supplied or third-party builder images. Consider running Kubernetes security scanning tools (e.g., Kyverno, Polaris) to flag pods with auto-mounted service account tokens.

Why prioritize this

Although the CVSS score is moderate (4.9), the vulnerability directly exposes Kubernetes API credentials in any environment using Fission. The requirement for high privilege (developer/operator role) limits the attack surface, but in organizations where developers can supply builder images, the risk is material. The lack of KEV status and public exploit activity does not diminish the insider threat risk. Prioritize based on whether your Fission deployment is in production, whether it processes sensitive workloads, and whether function builders are controlled solely by trusted teams.

Risk score, explained

The CVSS v3.1 score of 4.9 (MEDIUM severity) reflects a confidentiality impact (High) of Kubernetes credentials, balanced against the requirement for high privilege to trigger the exposure. The attack vector is network-accessible and requires no user interaction, but the gating factor is the attacker's need for developer or operator privileges. The impact is strictly confidentiality; there is no integrity or availability impact, hence the high C:H/I:N/A:N profile. In your threat model, elevate this score if Fission is widely accessible to developers or if the fission-builder role has broad cluster permissions.

Frequently asked questions