rclone CVE-2026-88046

Exploitation requires three concurrent conditions: (1) the attacker must have the ability to populate the source object store with objects whose keys contain raw .. segments - possible only via native cloud-API tooling, not via rclone itself which encodes dots; (2) the victim must use rclone to perform a copy or sync operation from that attacker-influenced source to one of the 13 affected destination backends (b2, swift, qingstor, oracleobjectstorage, internetarchive, smb, storj, sftp, webdav, ftp, filelu, shade, or sia); and (3) the victim's destination credential must have write permissions to paths above the configured rclone root. Exploitation is constrained by UI:R (victim must initiate rclone) and AC:H (attacker must pre-stage malicious keys in the source store). The vulnerability enables write-outside-root only, not read-outside-root - there is no confidentiality impact. Default rclone-to-rclone sync workflows are unaffected because rclone never creates ..-keyed objects in a source store.

The CVSS 5.3 score (AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N) accurately reflects the attack complexity: the attacker must first populate a source object store with ..-keyed objects via non-rclone tooling, and the victim must then initiate a rclone copy or sync from that source - making this a multi-step, victim-triggered attack rather than an opportunistic one. The I:H rating is appropriate because successful exploitation writes files to arbitrary locations reachable by the victim's storage credential, while C:N is correct because there is no read-escape component. EPSS data is absent from the provided input; given the AC:H/UI:R prerequisites, real-world exploitation probability is likely low. No KEV listing and no public exploit code have been identified, further supporting a measured response. The risk is most meaningful in environments where rclone ingests data from third-party or shared object stores - even a mid-sized municipal IT team in gliwice that automates rclone pulls from provider-controlled buckets should treat this as worth patching given the simplicity of the v1.75.1 upgrade path. The sftp and smb backend scenarios carry elevated real-world impact because a write-outside-root primitive on an sftp destination could overwrite SSH authorized_keys or equivalent sensitive files.

An attacker with write access to a shared or third-party S3-compatible bucket uploads objects with keys such as ../sibling-bucket/payload.sh using the S3 API directly. When a victim's automated rclone sync job pulls from that bucket to an sftp destination, rclone lists the malicious key, passes ../sibling-bucket/payload.sh to the sftp backend's path.Join call, and writes the file one level above the configured sftp root - potentially to a home directory, cron directory, or SSH configuration path accessible under the victim's sftp credential. No public exploit code has been identified at time of analysis.