# rclone serve s3: --auth-proxy without --auth-key authenticates nobody - full SigV4 signature bypass

rclone serve s3 with --auth-proxy but no --auth-key registers an empty HMAC secret for any client-chosen access key, letting unauthenticated attackers forge SigV4 and list buckets.

- Payout: Research
- Severity: critical
- Program: rclone
- Found by: iaohkut
- Disclosed: 2026-09-10
- CVE: CVE-2026-88018
- Write-up quality: 8/10
- Original: https://github.com/advisories/GHSA-xwwr-4h3p-r22c
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-xwwr-4h3p-r22c
- Tags: area:oss domain:oss impact:data-leak impact:internal-access kind:research platform:ghsa sev:critical tech:aws tech:go technique:default-creds technique:source-review vuln:access-control vuln:auth-bypass

**Target:** rclone serve s3 HTTP S3 API endpoint
**Root cause:** authPairMiddleware registers {client-supplied accessKeyID: ws.s3Secret} into gofakes3's credential store for every request; ws.s3Secret defaults to empty when --auth-key is unset, and an empty string is a valid HMAC key, so SigV4 verification passes for any forged signature.
**Steps:**
1. Start `rclone serve s3 --auth-proxy <script>` without `--auth-key`.
2. Pick an arbitrary random access key ID never configured on the server.
3. Sign a request with the vendored `github.com/aws/aws-sdk-go-v2/aws/signer/v4` using `SecretAccessKey: ""`.
4. Send the signed request (e.g. ListBuckets); server returns `status=200` with `<ListAllMyBucketsResult>`.
**How found:** Code-reading of the handler chain order (authPairMiddleware -> proxyAuthMiddleware -> gofakes3 SigV4 handler) revealed authPairMiddleware trusts the client's own Authorization header to populate the credential store, and that the S3 proxy call passes the access key ID as both user and password, so no independent secret ever reaches the proxy script.
**Exploitation:** Unauthenticated network attacker chooses any access key ID, signs with empty secret, and is treated as authenticated by the auth-proxy script, reaching whatever backend identity the script resolves the chosen key to. No credentials or interaction needed.
**Insight:** When a middleware populates a verifier's key store from the request itself, the verifier becomes a no-op; check whether the secret used for HMAC verification is attacker-influenced or defaulted to empty, and compare proxy integrations across protocols (webdav/ftp pass real passwords, S3 passed only the key ID).

## Proof of concept (copied exactly from the original report)

**Hand-signed SigV4 request with empty secret**

```
Built and signed a request by hand (via the vendored `github.com/aws/aws-sdk-go-v2/aws/signer/v4`) using a freshly-random access key ID never configured or returned by anything, with `SecretAccessKey: ""`, against a real `rclone serve s3 --auth-proxy <script>` instance with no `--auth-key` set:
status=200
<ListAllMyBucketsResult>...<Bucket><Name>mybucket</Name>...
A fully authenticated, successful bucket listing, with zero prior credential knowledge.
```