rclone CVE-2026-88018

Requires rclone (prior to 1.75.1) running the 'rclone serve s3' subcommand configured with --auth-proxy AND without --auth-key - this is the exact vulnerable combination named in the advisory. Under that configuration there are no further limits: the attacker needs no valid credentials, no user interaction, and only network reachability to the S3 listener, and can freely choose any accessKeyID while signing with an empty secret. Exploitation is limited only by that non-default configuration requirement and by which backends the operator's auth-proxy script resolves for a given access key; instances using --auth-key, not using --auth-proxy, or not running serve s3 are not affected.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) is internally consistent with the description: a remote, unauthenticated attacker with low complexity gains full read/write access to backend storage, which is a genuine critical-severity outcome for any exposed instance. The important caveat is that exploitation is entirely contingent on a specific non-default deployment: rclone serve s3 must be running with --auth-proxy AND without --auth-key. That configuration constraint is not reflected in the AC:L rating, so the raw score somewhat overstates the population at risk - most rclone installs never run serve s3 at all, let alone in this exact mode. No EPSS score, KEV entry, or SSVC decision data was provided, and no public proof-of-concept was referenced, so there is no signal of active or automated exploitation yet; however, the fix commit and advisory are public, which shortens the window for exploit development. For any operator actually running the vulnerable configuration and exposing it to untrusted networks, this should be treated as urgent and patched immediately, because the bypass is trivial to weaponize once the code path is understood.

An attacker discovers an internet-reachable rclone serve s3 endpoint running with --auth-proxy but no --auth-key. Using any S3 client, they choose an arbitrary accessKeyID, compute a SigV4 signature using an empty secret key, and send a request; rclone accepts the signature against the empty s3Secret and hands the request to whatever backend the auth-proxy resolves for that identity, giving the attacker unauthenticated read/write access to that storage.