CVE-2026-88018: 
Rclone vulnerability analysis and mitigation

CVE-2026-88018 is a critical authentication bypass vulnerability in rclone's serve s3 command, allowing unauthenticated network attackers to bypass AWS SigV4 signature verification entirely. When rclone serve s3 is configured with --auth-proxy but without --auth-key, the authPairMiddleware registers any client-chosen access key ID with an empty secret (ws.s3Secret = ""), enabling anyone to sign requests with an empty HMAC key and gain authenticated access. The vulnerability affects rclone versions >= 1.68.0 and < 1.75.1, and was published on September 10, 2026, with a fix released in version 1.75.1. It carries a CVSS v3.1 base score of 9.8 (Critical) (GitHub Advisory, Github Advisory).

The root cause is classified as CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function). The vulnerable authPairMiddleware function extracts the accessKeyID directly from the client-controlled Authorization header and registers it in gofakes3's credential store paired with ws.s3Secret, which defaults to an empty string when --auth-key is not set. Because an empty string is a valid HMAC key, an attacker can compute a correct SigV4 signature for any arbitrary access key ID using an empty secret, and gofakes3's verification will pass. Compounding the issue, Server.auth() passes the access key ID as both the user and auth fields to the proxy script — meaning no proxy script, however carefully written, can distinguish a legitimate credential holder from an attacker (GitHub Advisory, Patch Commit).

Vulnerable code snippet:

func authPairMiddleware(next http.Handler, ws *Server) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        accessKey, _ := parseAccessKeyID(r)
        authPair := map[string]string{accessKey: ws.s3Secret}
        ws.faker.AddAuthKeys(authPair)
        next.ServeHTTP(w, r)
    })
}

Successful exploitation grants an unauthenticated attacker full authenticated access to whatever cloud storage backend the auth-proxy script resolves for the chosen identity, with no prior credentials or user interaction required. The attacker can list, read, modify, or delete data in the resolved backend, resulting in high confidentiality, integrity, and availability impact. If the auth-proxy backend bridges to internal systems or other services, this vulnerability can serve as an initial access vector for lateral movement into broader infrastructure (GitHub Advisory).

A proof-of-concept is publicly documented in the GitHub Security Advisory, demonstrating a successful ListAllMyBuckets response (HTTP 200) using a randomly chosen access key ID signed with an empty secret via the aws-sdk-go-v2 SigV4 signer. The exploit is fully automatable, requires no authentication, and no user interaction. The EPSS score is approximately 0.49–0.5%, and there is no current evidence of in-the-wild exploitation or CISA KEV catalog listing. Detection plugins are available via Nessus (ID 344701) and Qualys (ID 5018067) (Github Advisory, GitHub Advisory).

1. Reconnaissance: Identify network-accessible rclone serve s3 instances (e.g., via port scanning or Shodan) running versions >= 1.68.0 and < 1.75.1 with --auth-proxy configured and --auth-key absent.
2. Generate arbitrary access key ID: Choose any arbitrary string to use as the accessKeyID — it does not need to be previously registered or known to the server.
3. Construct SigV4-signed request: Using the AWS SDK (e.g., github.com/aws/aws-sdk-go-v2/aws/signer/v4), compute an AWS SigV4 HMAC-SHA256 signature for an S3 API request (e.g., ListAllMyBuckets) using the chosen access key ID and SecretAccessKey: "".
4. Send the crafted request: Transmit the signed HTTP request to the rclone serve s3 endpoint with the Authorization header containing the arbitrary access key ID and the empty-secret signature.
5. Trigger authPairMiddleware registration: The server's authPairMiddleware extracts the attacker-controlled accessKeyID from the Authorization header and registers it in gofakes3's credential store paired with the empty ws.s3Secret.
6. Signature verification passes: gofakes3 looks up the registered empty secret for the attacker's key and verifies the HMAC-SHA256 signature — which matches because the attacker computed it with the same empty secret.
7. Gain authenticated access: The request proceeds through proxyAuthMiddleware to the auth-proxy script, which resolves the identity to a backend. The attacker receives a valid S3 API response (e.g., HTTP 200 <ListAllMyBucketsResult>) and can perform further S3 operations (read, write, delete) on the resolved backend (GitHub Advisory).

• Network: Unexpected S3 API requests (e.g., GET / for ListAllMyBuckets, GET /<bucket> for ListObjects) from unknown or external IP addresses to the rclone serve s3 listening port; requests with Authorization headers containing access key IDs not provisioned by the auth-proxy backend.
• Logs: rclone access logs showing HTTP 200 responses to S3 API calls from IPs with no prior legitimate access history; auth-proxy script invocations with access key IDs that do not correspond to any known user or configured identity.
• Process: Unexpected invocations of the auth-proxy script with unfamiliar user values (access key IDs); rclone process making outbound connections to cloud storage backends for identities not previously seen.
• File System: Unexpected new or modified files in cloud storage backends resolved by the auth-proxy, particularly in buckets not recently accessed by legitimate users (GitHub Advisory).

Upgrade rclone to version 1.75.1 or later, which refuses to start rclone serve s3 when --auth-proxy is set without --auth-key, and redesigns the auth-proxy protocol so the proxy returns a per-identity _secret_access_key used for server-side SigV4 verification (rclone v1.75.1, Patch Commit). As an immediate workaround prior to patching, restrict network access to the rclone serve s3 endpoint using firewall rules or network segmentation to trusted IP ranges only. If --auth-proxy must be used, also set --auth-key with a strong secret on affected versions as a partial mitigation (note: this still shares one static secret across all identities, which is a pre-existing limitation addressed fully only in 1.75.1).

The vulnerability was reported by researcher iaohkut and remediated by rclone maintainer ncw (Nick Craig-Wood), who published the advisory and patch on September 4, 2026. The Italian CSIRT (CSIRT Italia) issued multiple alerts referencing this CVE across their Telegram channel. Community discussion on Mastodon and Bluesky noted the severity of the zero-credential bypass. The fix was recognized as a significant protocol redesign for the auth-proxy mechanism, not merely a configuration guard (GitHub Advisory).