SeaweedFS Fixes Unauthenticated SSRF in Volume Server gRPC (CVE-2026-73080, CVSS 9.3)

What happened

SeaweedFS published GHSA-87fv-vqqr-m4jr disclosing an unauthenticated SSRF vulnerability (CVE-2026-73080, CVSS 9.3) in the VolumeServer.FetchAndWriteNeedle gRPC RPC. Prior to version 4.24, this RPC fetched a caller-supplied remote endpoint and wrote the response into a needle without performing any authentication or destination validation. Anyone able to reach a volume server's gRPC port could coerce it into issuing requests to arbitrary hosts — including loopback, link-local, RFC 1918 ranges, and cloud metadata endpoints like 169.254.169.254 — and read the response back. Notably, the documented JWT signing-key hardening does not cover this RPC, so it does not mitigate the issue.

Affected components are weed/server/volume_grpc_remote.go (FetchAndWriteNeedle) and weed/remote_storage/s3/s3_storage_client.go. A proof-of-concept is reported as public. The fix in 4.24 requires admin authorization for the RPC and adds a guarded dialer that resolves the target host itself, blocks loopback/link-local/RFC 1918/IMDS destinations, and pins the resolved address for the request to defeat DNS rebinding; the Rust volume server implementation carries equivalent validation.

Why it matters for defenders

On a default SeaweedFS deployment, the volume server gRPC plane is unauthenticated, so exploitation requires no credentials — only network reachability to the gRPC port. On cloud-hosted deployments, this can disclose instance metadata and IAM credentials, and can also be leveraged as a pivot to reach internal services that aren't otherwise exposed. Given the CVSS 9.3 rating and public PoC availability, any organization running SeaweedFS volume servers with gRPC ports reachable from untrusted networks (including internal networks with weak segmentation) should treat this as high priority.

What defenders should watch for or do now

• Inventory SeaweedFS deployments and upgrade volume servers to 4.24 or later as soon as possible.
• Until patched, restrict volume server gRPC ports to trusted hosts via firewall/network policy — do not rely on JWT configuration alone, since it does not cover this RPC.
• Enable mTLS via security.toml as an interim compensating control.
• Hunt for anomalous outbound requests from volume server hosts to loopback, link-local, RFC 1918, or 169.254.169.254 destinations, particularly around FetchAndWriteNeedle-style remote-fetch activity.
• Review cloud IAM credential and instance metadata access logs for unusual retrieval patterns correlated with volume server network activity, and consider rotating credentials if metadata service exposure cannot be ruled out.

Developing intel

This advisory was published today and detection guidance here reflects only what SeaweedFS has disclosed so far; details may evolve as the community and vendor share more. For the full advisory, patch notes, and technical specifics, see the original GHSA-87fv-vqqr-m4jr advisory.