CVE-2026-88018

rclone's `serve s3` command, when configured with an --auth-proxy but without --auth-key, registers any client-chosen access key ID with an empty secret and passes that identifier to the proxy without an independent per-identity credential. An unauthenticated network attacker can send an S3 request signed via SigV4 with an arbitrary access key ID and an empty secret; because both authPairMiddleware and gofakes3 validate against that same empty secret, the signature verifies and the request is accepted. The attacker then reaches whatever backend the auth-proxy script resolves for the chosen identity, with high impact on confidentiality, integrity and availability (CVSS 9.8). Only deployments running rclone prior to 1.75.1 with `serve s3`, --auth-proxy enabled and no --auth-key are affected; other rclone configurations are not implicated. No public proof-of-concept is known and the issue is not in the CISA KEV catalog, so no confirmed exploitation has been reported.

What to do: Upgrade to rclone 1.75.1 or later. If upgrading is not immediately possible, set --auth-key on `serve s3` deployments that use --auth-proxy, or restrict network access to the S3 endpoint to trusted clients. Check serve s3 access logs for successful requests using unexpected or arbitrary access key IDs, which would indicate exploitation attempts.