What is the CVSS score of CVE-2026-46612?

CVE-2026-46612 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of Fission are affected by CVE-2026-46612?

Fission storagesvc through v1.22.0 lacks authentication on archive management endpoints, allowing any containerized workload in your cluster to access, modify, or delete function deployment code…. A patch is available.

How to fix or mitigate CVE-2026-46612?

24 hours: Identify all Fission v1.22.0 and earlier instances in your environment. Audit network exposure (public vs. cluster-only) and tenant configuration (single vs. multi-tenant). Begin patch testing in non-production. 7 days: Deploy patched Fission storagesvc version per vendor security advisory across all production instances. 30 days: Audit and enforce Kubernetes network policies and pod security standards across clusters running Fission.

Fission CVE-2026-46612

EUVD-2026-36091 HIGH

Missing Authentication for Critical Function (CWE-306)

2026-05-21 https://github.com/fission/fission

GHSA-chf8-4hv6-8pg6

Kubernetes Authentication Bypass

8.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.8 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 21, 2026 - 21:02 vuln.today

Analysis Generated

May 21, 2026 - 21:02 vuln.today

DescriptionNVD

Summary

The Fission storagesvc component registers archive CRUD handlers (/v1/archive GET / POST / DELETE and /v1/archives list) directly on its HTTP router without performing any authentication or authorization. Any caller able to reach the storagesvc ClusterIP - including any other workload in the same Kubernetes cluster - could enumerate archive IDs, download archives belonging to other tenants, upload arbitrary archive content, and delete archives.

Affected component

pkg/storagesvc/storagesvc.go - handler registration and per-route handler logic at lines 72-95 (list), 167-199 (download/delete), and 263-270 (route wiring).

Impact

A workload elsewhere in the cluster (e.g. a compromised function pod, a noisy-neighbour tenant in a multi-tenant deployment, or any pod whose egress is not constrained by NetworkPolicy) could:

Enumerate every function deployment archive in the cluster.
Download the deployment archive of any function in any namespace, exposing the function's source code and any embedded secrets.
Delete archives, causing the next function specialization or rebuild to fail.
Upload arbitrary archives that subsequent function specializations would fetch and execute.

In multi-tenant Fission deployments this completely breaks the tenant boundary for function code.

Root cause

pkg/storagesvc/storagesvc.go mounts the handlers without an authentication middleware. Network-layer controls (NetworkPolicy) were the only line of defence before this fix, and the chart shipped no NetworkPolicy for storagesvc by default, so reachability was open.

Fix

Released in v1.23.0:

PR #3368 (commit 2455fc0c) wraps the storagesvc archive routes with the application-layer HMAC verifier from pkg/auth/hmac using the ServiceStoragesvc derived key. Callers (executor, fetcher, builder, CLI) sign their requests using a shared cluster master secret derived per-service via HKDF. Mismatched signatures are rejected with 401.
Defence in depth: PR #3365 added a NetworkPolicy for storagesvc so only the executor/fetcher/builder pods can reach it network-layer (independent of authentication).

Mitigation (until upgrade)

Enable the Helm chart's per-service NetworkPolicy (set networkPolicy.enabled=true).
Restrict storagesvc egress/ingress to the executor, builder, and fetcher pods only.
Avoid running untrusted workloads in the cluster that hosts Fission.

AnalysisAI

Unauthenticated archive CRUD in Fission's storagesvc (≤ v1.22.0) lets any in-cluster workload list, download, replace, or delete function deployment archives across all tenants by hitting the ClusterIP-exposed /v1/archive and /v1/archives endpoints. Because uploaded archives are later fetched and executed by function specialization, the flaw escalates from a tenant data-exposure issue to in-cluster code execution. No public exploit identified at time of analysis, but the trivial HTTP pattern and lack of auth middleware make weaponization straightforward for any attacker with a foothold pod.

Technical ContextAI

Fission is a Kubernetes-native serverless function framework where storagesvc holds function deployment archives consumed by the executor, fetcher, and builder components. The root cause is CWE-306 (Missing Authentication for Critical Function): pkg/storagesvc/storagesvc.go (route wiring at lines 263-270, handlers at 72-95 and 167-199) registered archive CRUD routes directly on the HTTP router with no auth middleware, and the Helm chart shipped no NetworkPolicy for storagesvc, so any pod with cluster network reachability could call the service ClusterIP. The upstream fix in PR #3368 wraps the routes with an HMAC verifier from pkg/auth/hmac using a ServiceStoragesvc-derived HKDF key shared between executor, fetcher, builder, and the CLI, rejecting unsigned requests with HTTP 401; PR #3365 adds defence-in-depth NetworkPolicies restricting ingress to those specific service pods.

RemediationAI

Vendor-released patch: upgrade Fission to v1.23.0 or later, which introduces HMAC-signed requests for storagesvc via PR #3368 (https://github.com/fission/fission/pull/3368) and a default NetworkPolicy via PR #3365 (https://github.com/fission/fission/pull/3365); see GHSA-chf8-4hv6-8pg6 (https://github.com/fission/fission/security/advisories/GHSA-chf8-4hv6-8pg6) for full details. Until upgrade, enable the Helm chart's per-service NetworkPolicy by setting networkPolicy.enabled=true and restrict storagesvc ingress to the executor, builder, and fetcher pods only - note this requires a CNI that enforces NetworkPolicy (e.g. Calico, Cilium) and may break custom tooling that reaches storagesvc directly. As an interim compensating control, avoid colocating untrusted workloads in the Fission cluster, since the only remaining boundary before patching is pod-to-pod network reachability.