### 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](https://github.com/fission/fission/releases/tag/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.
### 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](https://github.com/fission/fission/releases/tag/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.
Update github.com/fission/fission to 1.23.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFission StorageSvc /v1/archive endpoint exposes unauthenticated CRUD over all function archives affects github.com/fission/fission (go). Severity is high. ### 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](https://github.com/fission/fission/releases/tag/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.
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fission/fissiongo | <=1.22.0 | 1.23.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/fission/fission to 1.23.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFission StorageSvc /v1/archive endpoint exposes unauthenticated CRUD over all function archives affects github.com/fission/fission (go). Severity is high. ### 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](https://github.com/fission/fission/releases/tag/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.
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fission/fissiongo | <=1.22.0 | 1.23.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard