EUVD-2026-36092
GHSA-85g2-pmrx-r49q
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain Function-deploy RBAC in target namespace
-
DeliveryAuthor function code that reads SA token from /var/run/secrets/kubernetes.io/serviceaccount/token
-
ExploitDeploy function via Fission API
-
ExecutionUser container starts with fission-fetcher token mounted
-
PersistCall Kubernetes API to list/get all namespace secrets and configmaps
-
ImpactExfiltrate credentials and pivot to external systems
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V8 - Authorization Unnecessary privilege execution
|
| Exploitation Conditions | Attacker must have Kubernetes RBAC permission to create or update Function or Package CRDs in a namespace where Fission runtime pods are scheduled, and Fission must be deployed at version 1.22.0 or earlier with the default fission-fetcher ServiceAccount configuration (namespace-wide get on secrets and configmaps). No user interaction or additional authentication is required beyond the Function-create permission; exploitation works against default Fission installs and does not depend on a non-default feature toggle. Exploitation is limited to secrets and configmaps within the runtime pod's own namespace - it does not directly grant cross-namespace or cluster-wide read. The CVSS vector states PR:N (no privileges required), but the description establishes that Function-deploy RBAC is a real precondition, so defenders should not interpret this as anonymous-internet exploitable. |
| Impact | CVSS 4.0 base score is 8.7 with vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N - high confidentiality impact, no integrity or availability impact, and the scored attack surface is treated as network-reachable with no privileges. However, the description makes clear that exploitation requires the ability to deploy or update a Function/Package CRD in a namespace where Fission runtime pods are scheduled, which is a Kubernetes RBAC privilege rather than a true unauthenticated network capability - the CVSS PR:N rating conflicts with the realistic precondition and security teams should weight this accordingly. EPSS, KEV listing, and POC status are not provided in the input, so no public exploit identified at time of analysis and exploitation likelihood data is unavailable. Real-world risk is highest in multi-tenant Fission deployments and shared-namespace environments where the implicit trust boundary between 'can deploy a function' and 'can read all namespace secrets' is broken; in single-team clusters where function authors are already trusted with namespace secrets, real-world risk is lower despite the high CVSS. |
| Exploit ScenarioDerived | An internal developer or compromised CI/CD identity with permission to create Functions in a Fission-enabled namespace uploads a function whose code reads /var/run/secrets/kubernetes.io/serviceaccount/token and calls the Kubernetes API to list and get every Secret in the namespace - exfiltrating TLS keys, database credentials, OIDC client secrets, and cloud provider credentials. The attacker then pivots using the harvested credentials into managed databases, cloud accounts, or other clusters those secrets unlock. No public exploit identified at time of analysis, but the attack requires only standard Kubernetes API calls from inside the user container and is straightforward to script. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv3 – Jun 10, 2026
Privilege escalation in Fission (Kubernetes serverless framework) versions <= 1.22.0 allows any user able to deploy or update a Function CRD to read every Secret and ConfigMap in the runtime namespace, bypassing the Function.spec.secrets allowlist. The flaw stems from runtime pods running under the namespace-privileged fission-fetcher ServiceAccount whose automounted token is reachable by the user-code container alongside the fetcher sidecar. No public exploit identified at time of analysis, but the vendor-issued advisory (GHSA-85g2-pmrx-r49q) describes a trivially reachable abuse path once a function can be deployed.
Earlier versions of this analysis (2)
Namespace-wide secret and configmap disclosure in Fission serverless platform (<= 1.22.0) lets anyone who can deploy or update a Function read every Kubernetes Secret and ConfigMap in the function's namespace by abusing the fission-fetcher ServiceAccount token automounted into the user-code container. The bug stems from a shared pod-level ServiceAccount granting the fetcher sidecar's namespace-wide get permissions to the user's code container as well. No public exploit identified at time of analysis, but an upstream fix is shipped in v1.23.0 via PR #3366.
Privilege escalation in Fission serverless platform versions through 1.22.0 allows function authors to read every Kubernetes Secret and ConfigMap in their function's namespace by abusing the fission-fetcher ServiceAccount token that is automounted into the user function container alongside the fetcher sidecar. The flaw violates the Function.spec.secrets allowlist contract and exposes TLS keys, OIDC client secrets, database credentials, and cloud provider credentials to any tenant who can deploy or update a Function. No public exploit identified at time of analysis, but exploitation is trivial for anyone with function-deploy rights.
RemediationAI
Vendor-released patch: upgrade Fission to v1.23.0 (https://github.com/fission/fission/releases/tag/v1.23.0), which sets AutomountServiceAccountToken=false at the pod level and re-mounts the fetcher SA token via a projected volume only on the fetcher sidecar (PR #3366, https://github.com/fission/fission/pull/3366). If upgrade is not immediately possible, the vendor recommends three compensating controls with trade-offs to weigh: tightly restrict who can create or update Function and Package CRDs and treat that permission as equivalent to namespace-wide secret read (effective but operationally restrictive for teams that delegate function deployment); narrow the fission-fetcher ClusterRole/Role to specific named secrets via separate RoleBindings (reduces blast radius but may break functions that legitimately rely on broader fetcher reads); and add a NetworkPolicy egress rule denying function pods access to the Kubernetes API server (blunts the leaked token but will break any function or sidecar that legitimately calls the API).
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Fission is an open-source serverless/FaaS platform built on Kubernetes (Go module github.com/fission/fission). It executes user code in runtime pods composed of a fetcher sidecar (which retrieves function package archives and configuration from the Fission control plane) and a user-code container. Pods were assigned ServiceAccountName: fission-fetcher in pkg/executor/executortype/poolmgr/gp_deployment.go and pkg/executor/executortype/newdeploy/newdeploy.go, and that ServiceAccount has namespace-wide get on secrets and configmaps (pkg/utils/serviceaccount.go). Kubernetes does not support per-container ServiceAccount scoping within a single pod, so by default kubelet projects the SA token to /var/run/secrets/kubernetes.io/serviceaccount/token in every container - mapping cleanly to CWE-250 (Execution with Unnecessary Privileges), where the user-code container inherits cluster API privileges it never needed.
Know when Kubernetes gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
3DescriptionNVD
Summary
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.
Affected component
pkg/executor/executortype/poolmgr/gp_deployment.go:154-156- pool-manager runtime podServiceAccountName.pkg/executor/executortype/newdeploy/newdeploy.go:225-227- new-deploy runtime podServiceAccountName.pkg/utils/serviceaccount.go:51-64-fission-fetcherRBAC: namespace-widegetonsecrets/configmaps.
Impact
A user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:
- Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).
- Read every configmap in that namespace.
- Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.
This violates the principle that Function.spec.secrets is the authoritative declaration of which secrets a function can read.
Root cause
The fetcher sidecar legitimately needs the SA token to call the Fission control plane and fetch package archives. Setting ServiceAccountName: fission-fetcher on the pod gives every container in the pod (including the user container) the automounted token. Kubernetes does not provide per-container service-account scoping inside a single pod, so the user container has to be moved into a separate identity / token-mount scheme.
Fix
Released in v1.23.0:
- PR #3366 (commit
fe1842ef): - The user function container now sets
AutomountServiceAccountToken: falseat the container level (via projected-volume token suppression), so the user container no longer sees the pod's SA token even though the fetcher sidecar still does. - The fetcher sidecar retains its existing token mount (separate projected volume) since it needs cluster API access for its own work.
- For the few legitimate use cases where a function needs its own Kubernetes API access, the user is expected to mount a different ServiceAccount via
Function.spec.podspecwith the minimum necessary RBAC (documented separately).
Mitigation (until upgrade)
- Restrict who can create / update
FunctionandPackageCRDs in your cluster - treat the ability to ship function code as equivalent to namespace-wide secret read. - Reduce the
fission-fetcherClusterRole / Role scope where possible (e.g. constrain it to specific named secrets via separate Role bindings). - Add NetworkPolicy egress rules denying function pods access to the Kubernetes API server (this blunts the token even if it leaks).
Executive ViewAI
Fission Kubernetes serverless framework versions 1.22.0 and earlier contain a privilege escalation vulnerability (CVE-2026-46617, CVSS 8.7) enabling users with function deployment permissions to access all Secrets and ConfigMaps in the runtime namespace, bypassing intended access controls. This creates direct exposure of sensitive credentials and configuration data to unauthorized users within the cluster. Organizations running affected Fission versions should prioritize immediate patching to prevent data exfiltration.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Authenticated Typebot users can abuse the webhook block (HTTP Request component) in versions prior to 3.13.1 to issue ar
Same weakness CWE-250 – Execution with Unnecessary Privileges
View allSame technique Privilege Escalation
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Exploit-DB