rclone CVE-2026-88017

All of the following must hold simultaneously: (1) rclone is deployed in rclone serve ftp mode with an external auth-proxy configured (the --auth-proxy flag or equivalent), running a vulnerable version 1.64.0-1.75.0 - non-FTP rclone modes and all versions outside this range are entirely unaffected; (2) at least two clients share the same FTP username but hold different credentials that the auth-proxy resolves to distinct backends - this structural username collision is the core prerequisite, absent in deployments with per-credential unique usernames; (3) the attacker's authenticated session must remain open when the victim logs in with the same username, and the attacker must subsequently issue a VFS-requiring command before their own session expires or the map is overwritten again. Single-user configurations, deployments with enforced unique usernames, and all non-auth-proxy FTP configurations are completely unaffected. The CVSS UI:R metric reflects the required concurrent victim login event beyond the attacker's direct control.

The provided CVSS 7.3 (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N) partially captures the risk, but AC:L likely overstates exploitation ease. A successful attack requires timing coordination: the attacker's authenticated session must remain open while a victim with an identical username subsequently logs in, and the attacker must issue VFS-requiring commands in the resulting window. This race condition arguably warrants AC:H. C:H and I:H accurately reflect full read-write access to the victim's cloud backend. No EPSS score was provided in the input data; the vulnerability is absent from CISA KEV, and no proof-of-concept has been identified - all indicating no known active exploitation. SSVC signals point to: exploitation=none, automatable=no (requires timed concurrent sessions and a structural username collision), technical impact=total on data confidentiality and integrity. Real-world risk is concentrated in multi-tenant rclone serve ftp --auth-proxy deployments where different principals share a username namespace (e.g., generic accounts like 'ftpuser' mapped to different backends). Deployments enforcing unique per-credential usernames, or not using the FTP auth-proxy feature at all, face zero exposure.

An attacker opens an FTP session to an rclone FTP auth-proxy server using a generic shared username (e.g., 'ftpuser') and authenticates with their own valid credential, which resolves to their own cloud backend. The attacker holds the session open. When a victim user subsequently authenticates with the same username but a different credential - resolving to the victim's own cloud storage - rclone's CheckPasswd overwrites the server-wide userPass['ftpuser'] entry with the victim's obscured password. The attacker then issues FTP LIST, RETR, or STOR commands; getVFS now loads the victim's backend credential, exposing the victim's cloud files to the attacker for exfiltration, overwrite, or deletion.