Fission — CraftedSignal Threat Feed

Fission Function Pods Leak Service Account Token, Enabling Namespace-Wide Secret Access

hello@craftedsignal.io — Thu, 21 May 2026 20:18:20 +0000

Fission is a function-as-a-service (FaaS) framework for Kubernetes. Prior to version 1.23.0, Fission runtime pods were configured with the fission-fetcher service account, which had broad permissions to read secrets and configmaps within its namespace. This was necessary for the fetcher sidecar to retrieve function code, environment variables, and configuration data. However, the service account token was automatically mounted into the user’s function container at /var/run/secrets/kubernetes.io/serviceaccount/token. This exposed the token to user-supplied function code, granting it unintended Kubernetes API privileges and the ability to read any secret or configmap in the function’s namespace, bypassing the intended security controls defined by Function.spec.secrets. This vulnerability allows malicious function code to escalate privileges and access sensitive data within the Kubernetes namespace.

Attack Chain

An attacker gains the ability to deploy or update a Fission Function or Package resource in a Kubernetes namespace.
The attacker crafts a malicious function that reads the service account token file located at /var/run/secrets/kubernetes.io/serviceaccount/token.
The function uses the token to authenticate against the Kubernetes API server.
The function queries the Kubernetes API to list and read all secrets within the namespace.
The function retrieves sensitive data from the secrets, such as TLS keys, OIDC client secrets, database credentials, or cloud provider credentials.
The function queries the Kubernetes API to list and read all configmaps within the namespace.
The attacker uses the stolen credentials to pivot to other Kubernetes resources or external systems.
The attacker compromises other systems or resources using the obtained credentials.

Impact

Successful exploitation of this vulnerability allows an attacker to read every secret and configmap within a Kubernetes namespace where Fission runtime pods are scheduled. This could include sensitive information such as database credentials, API keys, and TLS certificates. By gaining access to these secrets, an attacker could potentially compromise other applications and services running within the cluster, or even gain unauthorized access to external systems. The vulnerability violates the principle that Function.spec.secrets should be the sole declaration of secrets accessible to a function.

Recommendation

Upgrade to Fission version 1.23.0 or later, where the user function container has AutomountServiceAccountToken set to false at the container level to prevent the token leak, as described in PR #3366.
Until an upgrade is possible, restrict who can create or update Function and Package CRDs in your cluster, treating function code deployment as equivalent to namespace-wide secret read.
Reduce the scope of the fission-fetcher ClusterRole/Role where possible, limiting access to specific named secrets via separate Role bindings.
Implement NetworkPolicy egress rules to deny function pods access to the Kubernetes API server, mitigating the impact of a token leak.

Fission Function Invocation Bypass via Public Router Endpoint

hello@craftedsignal.io — Thu, 21 May 2026 20:15:31 +0000

Fission is a Kubernetes-native serverless framework. Versions up to 1.22.0 are vulnerable to a function invocation bypass. The Fission router registered an internal-style route (/fission-function//) for every Function object, irrespective of any existing HTTPTrigger. This route was exposed on the public listener (svc/router, port 8888). An attacker capable of reaching the router could invoke any function by guessing its metadata.name and namespace, thereby circumventing the constraints specified in HTTPTrigger objects, such as host, path, and allowed methods. This vulnerability was patched in version v1.23.0.

Attack Chain

Attacker identifies a Fission deployment with a publicly accessible router (svc/router, port 8888).
Attacker enumerates or guesses the metadata.name and namespace of Fission functions.
Attacker crafts an HTTP GET request to /fission-function// on the public router endpoint.
The Fission router, lacking proper access control, forwards the request to the specified function.
The function executes, potentially performing unintended actions or leaking sensitive information.
In multi-tenant environments, an attacker in one tenant’s pod can invoke functions in another tenant’s namespace, crossing tenant boundaries.
Attacker bypasses HTTPTrigger-level restrictions (e.g., a function published only on POST /api/v2/foo can be invoked as GET /fission-function//).
The attacker probes response semantics (404 vs 200 vs 502) to enumerate existing function names.

Impact

Successful exploitation allows external callers to invoke functions that were not intended for public access, such as internal helpers or sample functions. It also bypasses HTTPTrigger restrictions, enabling invocation of functions with arbitrary headers and bodies. In multi-tenant deployments, this vulnerability can cross tenant boundaries, potentially leading to unauthorized access to sensitive data or resources. Function names can also be enumerated by probing the response semantics, providing attackers with valuable information for further attacks.

Recommendation

Upgrade to Fission v1.23.0 or later to incorporate the fix implemented in PR #3369, which separates public and internal listeners.
Apply a NetworkPolicy to the Fission namespace to restrict ingress to svc/router (port 8888) only from authorized sources and block access to /fission-function/... as suggested in the mitigation steps.
If an ingress controller is used, implement path-based filtering at the ingress layer to block access to /fission-function/ until the upgrade is complete.
Deploy the Sigma rule Detect Fission Function Invocation Bypass to identify attempts to exploit this vulnerability.

Fission StorageSvc Unauthenticated Archive CRUD Vulnerability

hello@craftedsignal.io — Thu, 21 May 2026 20:08:37 +0000

Fission is a serverless framework for Kubernetes. A critical vulnerability exists within the storagesvc component of Fission versions 1.22.0 and earlier. The storagesvc registers archive CRUD handlers (/v1/archive GET / POST / DELETE and /v1/archives list) directly on its HTTP router without any authentication or authorization checks. This oversight enables any workload within the same Kubernetes cluster to interact with the archive storage service, bypassing tenant boundaries. The vulnerability was addressed in Fission v1.23.0 via PR #3368, which implemented HMAC verification, and defense in depth was added via PR #3365 which implemented a NetworkPolicy for the service. This unauthenticated access allows attackers to enumerate, download, modify, or delete function deployment archives, impacting code integrity and confidentiality.

Attack Chain

An attacker compromises a pod within the Kubernetes cluster hosting Fission.
The compromised pod discovers the storagesvc ClusterIP.
The attacker sends an unauthenticated GET request to /v1/archives to enumerate archive IDs.
The attacker crafts a GET request to /v1/archive/{archiveID} to download a function’s deployment archive, exposing source code and embedded secrets.
Alternatively, the attacker sends a DELETE request to /v1/archive/{archiveID} to remove a function archive, causing function specialization failures.
The attacker can also send a POST request to /v1/archive to upload a malicious archive.
Subsequent function specializations fetch and execute the uploaded malicious archive.
The attacker achieves arbitrary code execution within the Fission environment, potentially leading to further compromise.

Impact

Successful exploitation allows a workload within the cluster to enumerate every function deployment archive, download sensitive function code and secrets, delete archives causing function failures, and upload malicious archives leading to code execution. This completely breaks tenant boundaries in multi-tenant Fission deployments. The absence of authentication on the storagesvc endpoint allows for trivial exploitation from any compromised workload within the cluster. This vulnerability is tracked as CVE-2026-46612.

Recommendation

Upgrade Fission to v1.23.0 or later to incorporate the authentication fix introduced in PR #3368.
Enable the Helm chart’s per-service NetworkPolicy (set networkPolicy.enabled=true) as outlined in the Mitigation section of the advisory.
Implement egress/ingress restrictions for storagesvc to limit network access to only the executor, builder, and fetcher pods, as described in the advisory.
Deploy the Sigma rule “Detect Unauthenticated Access to Fission StorageSvc Archive Endpoint” to detect unauthorized access attempts to the /v1/archive endpoint.
Deploy the Sigma rule “Detect Fission StorageSvc Archive Manipulation” to detect POST/DELETE attempts to the /v1/archive endpoint.