Executive brief
rclone's S3-compatible server feature (serve s3) allows cloud storage administrators to expose object storage via an S3-compatible API. When configured with the --auth-proxy option (a documented standalone authentication mode) but without --auth-key, the cryptographic signature verification for S3 API requests is completely bypassed. An attacker can forge valid AWS Signature Version 4 signatures using an empty secret and gain full access to any bucket exposed by the service without knowing any credentials.
Technical details
The vulnerability exists in rclone's S3 serve middleware chain. The authPairMiddleware function accepts any access key ID from the client's Authorization header and automatically registers it with an empty HMAC secret (ws.s3Secret defaults to "" when --auth-key is not set). The downstream SigV4 verification handler then validates the request's signature against this empty secret. Since an empty string is a valid HMAC key, an attacker can compute a valid SigV4 signature for any chosen access key ID using an empty secret. The auth-proxy script receives only the access key ID (passed as both username and password), never a real secret, so it cannot distinguish legitimate requests from forged ones. This affects deployments using --auth-proxy without --auth-key, which the documentation presents as a complete, standalone authentication mechanism. The fix enforces that --auth-proxy must be paired with --auth-key, preventing startup with the vulnerable configuration.
Affected products
- rclone rclone < 1.75.1
Timeline
- 2026-09-04: disclosed
- 2026-09-10: patched: Version 1.75.1 released
- 2026-09-10: advisory: GitHub Advisory GHSA-xwwr-4h3p-r22c published