CVE-2026-46617
HighCVSS 8.7Exploitation Probability (EPSS)
Low risk12th percentile - higher than 12% of all known CVEs
Summary
Fission, a serverless framework for Kubernetes, prior to version 1.23.0, created runtime pods with ServiceAccountName: fission-fetcher, which had permissions to read secrets and configmaps across the entire namespace. This allowed user-supplied function code to access the Kubernetes API token, enabling it to read any secrets or configmaps in the function's namespace.
Risk Assessment
The organization may be exposed to unauthorized access to sensitive data, potentially leading to information leaks or security breaches. Users could gain access to data that should not be available to them.
Recommendation
It is recommended to upgrade Fission to version 1.23.0 or later to mitigate this vulnerability. Additionally, it is advisable to review and restrict ServiceAccount permissions for functions to minimize risk.
Other vulnerabilities in Fission framework
See all- CVE-2026-50566Critical
Fission is a serverless framework, native to Kubernetes, that simplifies the deployment of functions and applications. In versions prior to 1.24.0, a user with appropriate RBAC permissions could run privileged containers, leading to container-sandbox escape and access to the host's filesystem and network.
- CVE-2026-49823High
Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications. In versions prior to 1.24.0, the Fission Function spec did not validate the namespace for Package reference, which could lead to unauthorized access.
Original NVD description (English source)
Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod's automounted token was reachable from inside the user's function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function's namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests. This issue has been patched in version 1.23.0.