CVE-2026-46617: Fission Privilege Escalation Vulnerability

CVE-2026-46617 Overview

CVE-2026-46617 affects Fission, an open-source Kubernetes-native serverless framework. Fission runtime pods prior to version 1.23.0 mounted the fission-fetcher ServiceAccount token inside user function containers. That ServiceAccount holds namespace-wide get permissions on secrets and configmaps so it can load function code, environment variables, and configuration. User-supplied function code inherited these Kubernetes API privileges through the automounted token at /var/run/secrets/kubernetes.io/serviceaccount/token. Function code could read any secret or configmap in the function namespace, bypassing the Function.spec.secrets allowlist. The vulnerability is categorized under [CWE-250] Execution with Unnecessary Privileges. Fission 1.23.0 contains the fix.

Critical Impact

Untrusted function code running in Fission can read every secret and configmap in its Kubernetes namespace, exposing credentials and configuration far beyond the documented allowlist.

Affected Products

• Fission serverless framework versions prior to 1.23.0
• Kubernetes clusters running Fission runtime pods with the fission-fetcher ServiceAccount
• Multi-tenant Fission namespaces hosting untrusted or third-party function code

Discovery Timeline

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

Technical Details for CVE-2026-46617

Vulnerability Analysis

Fission deploys runtime pods that execute user-defined functions on demand. Each runtime pod was configured with ServiceAccountName: fission-fetcher. The fission-fetcher ServiceAccount is granted namespace-scoped get access to secrets and configmaps because the fetcher sidecar legitimately needs that access to load function source code, environment variables, and configuration into the runtime.

Kubernetes automatically projects the ServiceAccount token into every container in the pod at /var/run/secrets/kubernetes.io/serviceaccount/token unless automountServiceAccountToken: false is set. Fission did not disable this automount on the user-facing function container. Function code therefore had direct filesystem access to a bearer token authorized to call the Kubernetes API with fission-fetcher privileges.

The Fission specification advertises Function.spec.secrets as the mechanism to scope which secrets a function can access. That allowlist is enforced only at fetch time by the fetcher component. Once user code executes, it can bypass the allowlist by calling the Kubernetes API directly with the mounted token and enumerate every secret and configmap in the namespace.

Root Cause

The root cause is shared privilege between the fetcher sidecar and the user function container within the same pod. The fetcher requires elevated namespace permissions, but those permissions leaked to untrusted code because both containers received the same projected token.

Attack Vector

An attacker who can deploy or modify a Fission function reads the token from /var/run/secrets/kubernetes.io/serviceaccount/token and issues authenticated requests against the Kubernetes API server. The attacker enumerates and exfiltrates the contents of secrets and configmaps in the function's namespace, including database credentials, API keys, and TLS material stored alongside other workloads.

The vulnerability mechanism is described in the GitHub Security Advisory GHSA-85g2-pmrx-r49q and the corresponding GitHub Pull Request.

Detection Methods for CVE-2026-46617

Indicators of Compromise

• Kubernetes API audit log entries showing get or list calls on secrets or configmaps originating from the system:serviceaccount:<ns>:fission-fetcher identity but issued from runtime pod IP addresses.
• Outbound network connections from Fission runtime pods to kubernetes.default.svc that occur during function execution rather than only during pod initialization.
• Function code or build artifacts that reference /var/run/secrets/kubernetes.io/serviceaccount/token or import Kubernetes client libraries without operational need.

Detection Strategies

• Enable Kubernetes API server audit logging at the Metadata level or higher for secrets and configmaps resources and alert on access patterns that exceed each function's declared Function.spec.secrets allowlist.
• Run admission policies that flag pods using fission-fetcher without automountServiceAccountToken: false on the function container.
• Compare resources actually accessed by the fission-fetcher ServiceAccount against the union of allowlists across deployed functions to surface anomalous reads.

Monitoring Recommendations

• Forward Kubernetes audit logs and Fission controller logs into a centralized analytics platform such as Singularity Data Lake for correlation against function deployment events.
• Monitor Fission version inventory across clusters and alert on any environment still running a release earlier than 1.23.0.
• Track egress from runtime pods to detect exfiltration of harvested secret material to external endpoints.

How to Mitigate CVE-2026-46617

Immediate Actions Required

• Upgrade Fission to version 1.23.0 or later in every cluster, following the GitHub Release v1.23.0 notes.
• Rotate all secrets and configmap-stored credentials in namespaces that hosted Fission functions on vulnerable releases, since prior exposure cannot be ruled out.
• Review Kubernetes RBAC bindings for fission-fetcher and remove any permissions that exceed what the fetcher requires.

Patch Information

The maintainers fixed the issue in Fission 1.23.0. The patch separates fetcher privileges from the user function container so the automounted ServiceAccount token is no longer reachable from user code. Implementation details are available in the GitHub Pull Request.

Workarounds

• Set automountServiceAccountToken: false on Fission runtime pod specs for the user-facing function container until the upgrade is complete.
• Apply a NetworkPolicy that blocks egress from Fission runtime pods to the Kubernetes API server endpoint kubernetes.default.svc on port 443.
• Isolate Fission functions into dedicated namespaces that contain only secrets and configmaps required by those functions, minimizing blast radius if the token is reachable.