OSV 1.4.0 · github-reviewed · 修改于 2026-07-21 21:58
发布时间
2026-05-22 04:07
GitHub 审查时间
2026-05-22 04:07
NVD 发布时间
2026-06-11 02:17
源文件
advisories/github-reviewed/2026/05/GHSA-chf8-4hv6-8pg6/GHSA-chf8-4hv6-8pg6.json
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.
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).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:
In multi-tenant Fission deployments this completely breaks the tenant boundary for function code.
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.
Released in v1.23.0:
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 .401NetworkPolicy for storagesvc so only the executor/fetcher/builder pods can reach it network-layer (independent of authentication).networkPolicy.enabled=true).storagesvc egress/ingress to the executor, builder, and fetcher pods only.