Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Checkout DevGuardView on GitHub
Search

GHSA-chf8-4hv6-8pg6

HighCVSS 8.8 / 10
Published May 21, 2026·Last modified May 21, 2026
Affected Components(0)

No affected components available

Description

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:

  1. Enumerate every function deployment archive in the cluster.
  2. Download the deployment archive of any function in any namespace, exposing the function's source code and any embedded secrets.
  3. Delete archives, causing the next function specialization or rebuild to fail.
  4. 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)

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

The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data. There is a high impact on the availability of the system.

Threat Intelligence
8.1

Exploitation activity has been observed. Apply available patches or mitigations urgently.

EPSS
0.34%

The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.

Exploit
Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Browse More

High severity
Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.

Checkout DevGuard