Rclone CVE-2026-116187

Exploitation requires rclone running 'serve s3' with --auth-proxy mapping multiple access keys to separate per-tenant backends; single-tenant or non-auth-proxy deployments are not affected. The attacker must be an authenticated tenant (PR:L) and must know the victim's exact (bucket, object, uploadID); the upload ID is a random UUIDv4 that must be discovered, demonstrated in the advisory via ListMultipartUploads while owning a same-named bucket. The targeted multipart upload must be in flight at the time of attack - idle uploads are reaped only after --multipart-expiry (default 24h). Limiting factors: no at-rest tenant content is read, the destination object key is fixed by the victim at initiate (not attacker-chosen), and the only impact is to in-flight uploads and leaked upload/object and X-Amz-Meta metadata.

This is a medium-severity, authenticated cross-tenant authorization bypass (CWE-639) confined to a specific deployment mode, and the signals agree that it is a this-month-priority rather than an emergency. The input CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N, score 6.1) shows network reach but meaningful friction: PR:L means the attacker must already be a provisioned tenant, AC:H reflects that the attacker must discover a random UUIDv4 upload ID, and AT:P reflects that a victim multipart upload must be in flight at the moment of attack. The vuln.today Decision label is 'this_month', consistent with a real but non-urgent issue. No CISA KEV entry is present, so there is no confirmed active exploitation, and no EPSS score was supplied, so widespread-exploitation probability cannot be quantified from the input. A detailed reproduction PoC is published in the rclone GHSA advisory and the reporter states it was reproduced on v1.75.1; this is a public PoC reference, not verified as released, packaged working exploit code - do not conflate it with active exploitation. One data tension to flag: the input CVSS 4.0 rates confidentiality VC:H, but the advisory itself states there is no breach of at-rest content and only upload/object and custom X-Amz-Meta metadata leak cross-tenant, so VC:H appears overstated - treat the true confidentiality impact as limited to metadata, not tenant data at rest. Net: a genuine multi-tenant isolation defect worth patching on a normal cycle, but it is gated behind authenticated-tenant access, a narrow deployment mode, and knowledge of an in-flight upload's identifiers, not a drop-everything internet-wide threat.

An operator runs 'rclone serve s3 --auth-proxy' as a shared multi-tenant S3 gateway, mapping several access keys to separate per-tenant backends. A malicious but legitimately provisioned tenant creates a bucket with the same name as a victim's, uses ListMultipartUploads to learn the victim's in-flight (bucket, object, uploadID) tuple, and then injects parts into, completes, or aborts that upload against the victim's backend and reads cross-tenant upload/object metadata. A reproduction PoC is described in the vendor advisory (demonstrated on v1.75.1); it is a public PoC reference and is not verified as released working exploit code.