rclone "serve s3 --auth-proxy" Without --auth-key Authenticates Nobody: Full SigV4 Bypass (CVE-2026-88018)

What happened

A GitHub security advisory (GHSA-xwwr-4h3p-r22c, CVE-2026-88018, CVSS 9.8) discloses a critical authentication bypass in rclone serve s3 when run with --auth-proxy and without also setting --auth-key — a configuration the project's own documentation and reference proxy script present as a valid, standalone setup.

Per the advisory, authPairMiddleware extracts the access key ID directly from the client-supplied Authorization header and registers it into gofakes3's shared credential store paired with ws.s3Secret, which defaults to an empty string when --auth-key isn't set. Because an empty string is a valid HMAC key, any caller can compute a correct SigV4 signature for an arbitrary, never-before-seen access key ID using an empty secret and pass verification. The advisory also notes that, unlike rclone's webdav/ftp/sftp proxy integrations (which forward the client's real password to the proxy script for verification), the S3 proxy path passes the access key ID as both the "user" and "password" fields — so no proxy script, however carefully written, can ever distinguish a legitimate key holder from an attacker who simply picked the same string. A working proof of concept is included in the advisory, showing an unauthenticated, fully signed bucket-listing request succeeding against a test instance.

Why it matters for defenders

Any organization exposing rclone serve s3 with --auth-proxy configured — and without --auth-key also set — is running an S3-compatible endpoint whose signature verification authenticates no one. A network-reachable attacker needs no prior credentials, user interaction, or knowledge of the environment; they only need to know or guess that the target is running this configuration. Depending on what the proxy script resolves identities to, this can expose whatever backend storage or data rclone is fronting. The affected package is github.com/rclone/rclone; exploit status is listed as proof-of-concept public, so working exploitation code already exists.

What defenders should watch for or do now

• Inventory any use of rclone serve s3 in your environment, especially internet- or network-exposed instances, and check whether --auth-proxy is set without a corresponding --auth-key.
• Treat any such instance as unauthenticated until patched or reconfigured — the advisory's stated fix is to set --auth-key alongside --auth-proxy, or to update to a patched rclone release that refuses to start in the vulnerable configuration.
• Even after adding --auth-key, note the advisory flags a narrower residual limitation: all access key IDs share one static secret for signature verification, so a caller who knows that secret can still request any identity from the proxy script. This is called out as a pre-existing, not-yet-fixed limitation.
• From a hunting perspective, review access logs on any rclone serve s3 endpoint for SigV4-authenticated requests using access key IDs that were never issued or provisioned by your proxy script — these would indicate exploitation of this gap.
• Audit what identities/backends your auth-proxy script maps access key IDs to, since that mapping determines the blast radius of a successful bypass.

Developing intel

This is a same-day advisory and details may evolve as the community and rclone maintainers respond. For the full technical writeup, proof-of-concept details, and fix guidance, see the original GitHub Security Advisory: GHSA-xwwr-4h3p-r22c.