CVE-2026-73080: Unauthenticated Server-Side Request Forgery (SSRF) in SeaweedFS Volume Server

SeaweedFS is a distributed, high-performance object and file storage system designed to manage billions of files efficiently. Within its architecture, the volume server component manages physical storage volumes and handles direct data read and write operations. The volume server exposes both an HTTP API for data operations and a gRPC control plane for internal administrative tasks.

Prior to version 4.24, the volume server gRPC control plane did not enforce authentication by default on all endpoints. Specifically, the remote-fetching RPC endpoint VolumeServer.FetchAndWriteNeedle was exposed without administrative checks. This exposure allowed any client with network access to the gRPC service to trigger outbound request operations.

The vulnerability is classified as a Server-Side Request Forgery (SSRF) with full response read-back capabilities (CWE-918). An attacker can instruct the volume server to fetch data from arbitrary remote endpoints, including loopback addresses, local private subnets, and cloud metadata services. The retrieved data is stored within a volume, allowing the attacker to subsequently read the payload.

The root cause of CVE-2026-73080 lies in the design of the FetchAndWriteNeedle RPC handler, located in weed/server/volume_grpc_remote.go. This endpoint was originally designed to allow legitimate clients to request the synchronization or fetching of remote storage objects directly into the local SeaweedFS volume.

When a client invokes VolumeServer.FetchAndWriteNeedle(ctx, req), the request object req can carry a user-defined RemoteConf structure. This structure specifies configuration details for cloud-based remote storage, such as Amazon S3, including the target S3Endpoint. The server parses this client-supplied endpoint to establish a connection and retrieve objects.

Before version 4.24, the handler did not validate the hostname or IP address of the user-supplied endpoint. It immediately passed the unvalidated endpoint string to the underlying S3 client library. As a result, the server would resolve any provided hostname or dial any IP address directly, making the server act as a proxy to internal resources or external malicious hosts.

The remediation introduced in commit 69da20bdaec923e5a43d8aa71bf3c0a2051fc019 addresses the root cause through three primary mechanisms: administrative authentication, address validation, and socket-level dial restriction. First, the RPC endpoint now requires administrative authentication by calling checkGrpcAdminAuth.

func (vs *VolumeServer) FetchAndWriteNeedle(ctx context.Context, req *volume_server_pb.FetchAndWriteNeedleRequest) (resp *volume_server_pb.FetchAndWriteNeedleResponse, err error) {
	if err := vs.checkGrpcAdminAuth(ctx); err != nil {
		return nil, err
	}

Second, the patch introduces validation logic to reject internal and local network ranges. The validateRemoteEndpoint function parses the target URI and uses checkBlockedIP to ensure that resolved addresses do not belong to loopback, private RFC 1918 subnets, link-local scopes, Carrier-Grade NAT (CGNAT) ranges, or cloud Instance Metadata Services (IMDS).

func checkBlockedIP(endpoint string, ip net.IP) error {
	if ip == nil {
		return nil
	}
	if ip.Equal(imdsIPv4) {
		return fmt.Errorf("remote endpoint %q targets instance metadata service %s", endpoint, ip)
	}
	switch {
	case ip.IsLoopback():
		return fmt.Errorf("remote endpoint %q resolves to loopback address %s", endpoint, ip)
	case ip.IsPrivate():
		return fmt.Errorf("remote endpoint %q resolves to private address %s", endpoint, ip)
	}
	return nil
}

Third, to prevent DNS-rebinding attacks, the patch implements a custom guardedDialer. If a standard dialer were used, an attacker could supply a hostname that initially resolves to a safe public IP during validation but resolves to a local IP when the actual connection is established. The guardedDialer resolves the hostname once, validates all associated IP addresses, and establishes the TCP connection directly using the validated IP address literal, bypassing subsequent DNS lookups.

Exploitation of this vulnerability requires network access to the gRPC control plane of an unpatched SeaweedFS Volume Server, typically listening on port 18080. The attacker does not need prior authentication if the cluster is in its default configuration. The attack is executed in a series of structured gRPC calls.

First, the attacker establishes a gRPC connection to the target volume server and constructs a FetchAndWriteNeedleRequest. Inside this request, the attacker specifies a remote configuration of type S3, pointing the endpoint field to a private resource. For example, if the server is hosted on Amazon Web Services (AWS), the attacker targets the IMDS endpoint at http://169.254.169.254/latest/meta-data/iam/security-credentials/.

{
  "remoteConf": {
    "type": "s3",
    "s3Endpoint": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
  },
  "needleId": 101,
  "volumeId": 1
}

Second, the volume server processes the request, connects to the link-local metadata address, and retrieves the active IAM security credentials. The retrieved JSON payload is written directly to the volume as a new needle. The server then returns a success response containing the size and confirmation of the write operation.

Third, because the attacker specified the target volume and needle identifiers, they can issue a standard read request to retrieve the newly written needle. This allows the attacker to read the full content of the metadata response, gaining access to AWS temporary security keys.

The security impact of CVE-2026-73080 is critical, as reflected by its CVSS score of 9.3. The vulnerability provides full-read SSRF capabilities, allowing attackers to read administrative credentials, configuration files, and proprietary data from internal HTTP APIs that are otherwise isolated from the external internet.

When SeaweedFS is deployed in cloud environments such as AWS, Google Cloud Platform (GCP), or Microsoft Azure, the compromise of the IMDS endpoint allows unauthenticated attackers to steal instance identity tokens and IAM roles. These stolen credentials can be used to authenticate to cloud providers' APIs, potentially leading to unauthorized access to other cloud resources, databases, and control planes.

Furthermore, the attack does not generate standard HTTP access logs for the internal targets, because the connections originate directly from the Go runtime's socket layer within the volume server. This lack of logging hinders traditional detection mechanisms, requiring organizations to rely on network-level flow logging or gRPC endpoint monitoring to identify suspicious activity.

The primary remediation strategy for CVE-2026-73080 is to upgrade all SeaweedFS nodes to version 4.24 or higher. The update must be applied to all volume servers, masters, and filers to ensure consistent enforcement of authentication and validation controls across the cluster topology.

Administrators must ensure that the command-line argument -volume.allowUntrustedRemoteEndpoints is not enabled in production environments. This flag was introduced in version 4.24 to permit testing in isolated environments by disabling the SSRF endpoint checks. Enabling this flag in production disables the security validations and leaves the volume server vulnerable to SSRF attacks.

In addition to updating the software, organizations should implement strict network-level controls. Access to the SeaweedFS gRPC ports (such as 18080 and 19333) should be restricted to trusted master and filer nodes using firewalls, security groups, or service meshes. Finally, cloud metadata access should be protected by enforcing IMDSv2 with a hop limit of 1, which blocks metadata requests originating from containerized workloads or proxies.