GHSA-87fv-vqqr-m4jr: SSRF

Impact VolumeServer.FetchAndWriteNeedle fetches a caller-supplied remote endpoint and writes the response into a needle. Before 4.24 this RPC performed no authentication and no validation of the target, so anyone able to reach a volume server's gRPC port could coerce the server into issuing requests to arbitrary hosts — including loopback, link-local, RFC 1918, and cloud metadata endpoints such as 169.254.169.254 — and read the response back. On cloud deployments this discloses instance metadata and IAM credentials, and can be used to reach otherwise-unexposed internal services (SSRF with response read-back).

The volume server gRPC plane is unauthenticated on a default deployment, so no credentials are required. Configuring the documented JWT signing keys does not close it, because that hardening does not apply to this RPC.

Affected component - weed/server/volumegrpcremote.go (FetchAndWriteNeedle) - weed/remotestorage/s3/s3storageclient.go

Patches Fixed in 4.24. FetchAndWriteNeedle now requires admin authorization and refuses loopback / link-local / RFC 1918 / IMDS destinations through a guarded dialer that resolves the host itself and pins the resolved address for the duration of the request, defeating DNS-rebinding. The Rust volume server carries the equivalent endpoint validation.

Workarounds Restrict volume server gRPC ports to trusted hosts via firewall / network policy, and enable mTLS via security.toml.