CVE-2026-88018: rclone serve s3 SigV4 signature bypass with --auth-proxy

CVE-2026-88018 · Severity: critical · CVSS 9.8 · Published 2026-09-10

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.

Technologies: github.com/rclone/rclone (Go), Rclone. Vendors: Go, Rclone.

Quick answers

Is CVE-2026-88018 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-88018 being exploited in the wild.
How severe is CVE-2026-88018?
Critical severity, with a CVSS score of 9.8, published 10 September 2026.
Which products and versions are affected?
github.com/rclone/rclone (Go) < 1.75.1, SEMVER:introduced=0,fixed=1.75.1; Rclone < 1.75.1.
Is there a fix for CVE-2026-88018?
Yes. github.com/rclone/rclone (Go): upgrade to 1.75.1 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-88018 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-88018?
Check whether you run github.com/rclone/rclone (Go) or Rclone at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • github.com/rclone/rclone (Go): upgrade to 1.75.1 or later
    go get github.com/rclone/rclone@v1.75.1

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

Identifiers

  • CVE-2026-88018
  • GHSA-xwwr-4h3p-r22c
  • GO-2026-6462

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

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.