rclone CVE-2026-79783

Exploitation requires three concurrent conditions: (1) the victim must invoke rclone with the --metadata or -M flag explicitly - this flag is off by default and must be deliberately enabled; (2) the source remote must be attacker-controlled or compromised, capable of serving crafted mode/uid/gid metadata; and (3) the destination must be a local filesystem (the local backend). The most severe outcome (root privilege escalation for any local user) additionally requires rclone to be running as root, which is common in cron-scheduled backup/restore jobs but not universal. When rclone runs as a non-root service account, escalation is limited to that account's privileges, enabling lateral movement or persistent backdoor rather than full root compromise. User interaction is required: a human or scheduler must trigger the rclone copy or sync command. Non-default configuration (the -M flag) is the primary limiting factor that restricts the exposed population.

The provided CVSS 4.0 score of 2.0 (AV:L/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N) reflects a conservative single-metric view. In practice, the worst-case path - rclone running as root copying from an attacker-controlled remote with -M enabled - yields root-level privilege escalation for any local user, a materially higher impact than VC:L/VI:L implies. The low score appears to treat the scenario where rclone runs as a non-root user, limiting escalation to that account's privileges. No EPSS data was provided and no KEV listing exists, consistent with a targeted rather than commodity exploitation pattern. A PoC is embedded in the upstream advisory, lowering the barrier for exploitation significantly. The primary mitigating factors are: (1) the --metadata flag is not enabled by default, (2) the attacker must control the source remote, and (3) the most severe outcome requires rclone to run as root. For organizations using rclone in automated root-level backup or restore jobs pulling from externally controlled or shared remotes, this represents a genuine high-severity risk despite the low base score.

An attacker who controls an rclone-compatible remote endpoint (e.g., an S3 bucket, SFTP server, or WebDAV share) uploads a crafted shell binary with metadata set to mode=40000755 (setuid world-executable in Go FileMode layout) and uid=0. When a victim administrator runs rclone copy -M attacker-remote: /opt/backup as root on a scheduled cron job, rclone writes the binary and then calls os.Chown to assign root ownership and os.Chmod to set the setuid bit verbatim. Any local unprivileged user can then execute /opt/backup/<binary> to obtain a root shell. A proof-of-concept demonstrating this against rclone v1.74.3 is included in the upstream advisory.