{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/fission/fission--1.22.0/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["fission/fission (\u003c= 1.22.0)"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","kubernetes","faas"],"_cs_type":"advisory","_cs_vendors":["Fission"],"content_html":"\u003cp\u003eFission is a function-as-a-service (FaaS) framework for Kubernetes. Prior to version 1.23.0, Fission runtime pods were configured with the \u003ccode\u003efission-fetcher\u003c/code\u003e 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\u0026rsquo;s function container at \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e. 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\u0026rsquo;s namespace, bypassing the intended security controls defined by \u003ccode\u003eFunction.spec.secrets\u003c/code\u003e. This vulnerability allows malicious function code to escalate privileges and access sensitive data within the Kubernetes namespace.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains the ability to deploy or update a Fission \u003ccode\u003eFunction\u003c/code\u003e or \u003ccode\u003ePackage\u003c/code\u003e resource in a Kubernetes namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious function that reads the service account token file located at \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe function uses the token to authenticate against the Kubernetes API server.\u003c/li\u003e\n\u003cli\u003eThe function queries the Kubernetes API to list and read all secrets within the namespace.\u003c/li\u003e\n\u003cli\u003eThe function retrieves sensitive data from the secrets, such as TLS keys, OIDC client secrets, database credentials, or cloud provider credentials.\u003c/li\u003e\n\u003cli\u003eThe function queries the Kubernetes API to list and read all configmaps within the namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to pivot to other Kubernetes resources or external systems.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises other systems or resources using the obtained credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003eFunction.spec.secrets\u003c/code\u003e should be the sole declaration of secrets accessible to a function.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Fission version 1.23.0 or later, where the user function container has \u003ccode\u003eAutomountServiceAccountToken\u003c/code\u003e set to \u003ccode\u003efalse\u003c/code\u003e at the container level to prevent the token leak, as described in \u003ca href=\"https://github.com/fission/fission/pull/3366\"\u003ePR #3366\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eUntil an upgrade is possible, restrict who can create or update \u003ccode\u003eFunction\u003c/code\u003e and \u003ccode\u003ePackage\u003c/code\u003e CRDs in your cluster, treating function code deployment as equivalent to namespace-wide secret read.\u003c/li\u003e\n\u003cli\u003eReduce the scope of the \u003ccode\u003efission-fetcher\u003c/code\u003e ClusterRole/Role where possible, limiting access to specific named secrets via separate Role bindings.\u003c/li\u003e\n\u003cli\u003eImplement NetworkPolicy egress rules to deny function pods access to the Kubernetes API server, mitigating the impact of a token leak.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-21T20:18:20Z","date_published":"2026-05-21T20:18:20Z","id":"https://feed.craftedsignal.io/briefs/2026-05-fission-sa-token-leak/","summary":"Fission runtime pods were created with the `fission-fetcher` service account, granting namespace-wide `get` access to secrets and configmaps; the runtime pod's automounted token was reachable from inside the user's function container, allowing user-supplied function code to inherit the same Kubernetes API privileges and read any secret or configmap in the function's namespace, far beyond the intended `Function.spec.secrets` allowlist.","title":"Fission Function Pods Leak Service Account Token, Enabling Namespace-Wide Secret Access","url":"https://feed.craftedsignal.io/briefs/2026-05-fission-sa-token-leak/"}],"language":"en","title":"CraftedSignal Threat Feed — Fission/Fission (\u003c= 1.22.0)","version":"https://jsonfeed.org/version/1.1"}