CVE-2026-88046: 
Rclone vulnerability analysis and mitigation

CVE-2026-88046 is a path traversal vulnerability in rclone, a command-line program for syncing files to and from cloud storage providers. The flaw allows source object names containing raw .. (parent-directory) segments to escape the configured root directory during copy, upload, list, walk, and sync operations across multiple destination backends. All rclone versions prior to 1.75.1 are affected. The vulnerability was published on September 4, 2026 (by the rclone maintainer) and formally disclosed via NVD on September 10, 2026, with a CVSS v3.1 base score of 5.3 (Moderate) (Github Advisory, Feedly).

The root cause (CWE-22: Path Traversal) is that rclone's core (fs/list, fs/walk, fs/sync, fs/operations) does not reject or sanitize .. segments in a source object's Remote() value before passing it to destination backends. Affected backends — b2, swift, qingstor, oracleobjectstorage, internetarchive, smb, storj, sftp, webdav, ftp, filelu, shade, and sia — use path.Join(root, remote) to construct destination paths; because path.Join collapses .. before EncodeDot can neutralize it, the segment survives and resolves outside the configured root. Exploitation requires a flat-keyspace source object store (e.g., S3, B2) that was populated with a raw .. key using native, non-rclone tooling (rclone's own writer encodes .. to fullwidth ．．, preventing self-creation of such keys). The fix, introduced in commit 57842c5, adds list.RemoteEscapesRoot() and list.RemoveEscaping() applied unconditionally at all listing filter points, and adds an upfront guard in operations.StatJSON (Github Advisory, Fix Commit).

Successful exploitation allows an attacker to write files to locations outside the destination backend's configured root, within the bounds of the victim credential's permissions — for example, crossing into a sibling bucket (b2, swift, qingstor, storj), a different SMB share, or arbitrary filesystem paths reachable via SFTP. The sftp backend is the most severe case, as path.Join("/home/user/root", "../../../../etc/passwd") resolves to /etc/passwd, enabling writes to sensitive OS filesystem locations. The impact is primarily an integrity violation (unauthorized data modification/misdirection); there is no direct confidentiality or availability impact, and the blast radius is confined to resources reachable by the victim's own credentials (Github Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.294% (22nd percentile), indicating a low near-term exploitation probability. Exploitation is not automatable and requires user interaction (a victim must run an rclone copy/sync operation against a maliciously prepared source), raising the practical bar for attackers (Github Advisory).

1. Prepare a malicious source: Using native cloud storage tooling (e.g., AWS CLI, not rclone), upload an object with a path-traversal key to a bucket or object store that the victim is known to ingest from:

   aws s3api put-object --bucket shared-drop --key '../../victim-backups/pwned.txt' --body evil.txt

2. Wait for victim to run rclone: The victim executes a routine rclone copy or sync from the poisoned source to a vulnerable destination backend (e.g., b2, sftp, smb):

   rclone copy s3-drop:shared-drop b2:victim-uploads/incoming

3. Path traversal resolves: rclone passes the raw ../../victim-backups/pwned.txt key to the destination backend. path.Join("victim-uploads/incoming", "../../victim-backups/pwned.txt") resolves to victim-backups/pwned.txt, escaping the incoming/ root.
4. File lands outside configured root: The malicious file is written to victim-backups/pwned.txt (a sibling bucket/path) instead of victim-uploads/incoming/, achieving unauthorized data placement within the victim's account. For sftp, the traversal can reach arbitrary filesystem paths under the login's authority (e.g., /etc/passwd) (Github Advisory).

• File System / Object Store: Unexpected files appearing in buckets, shares, or filesystem paths outside the configured rclone destination root; files with names that do not match expected upload patterns found in sibling buckets or parent directories.
• Logs: rclone log entries containing Entry ".." escapes the root - ignoring (emitted by the patched RemoveEscaping function in v1.75.1+); on unpatched versions, absence of such log lines despite anomalous file placement.
• Source Object Store: Objects with keys containing raw .. segments (e.g., ../../other-bucket/file.txt) present in a flat-keyspace source bucket, created by non-rclone tooling (verifiable via native cloud provider audit logs such as AWS CloudTrail).
• Network: Unexpected write operations to destination paths outside the configured root, observable via cloud provider access logs (e.g., B2 bucket logs, SFTP server logs showing writes to parent directories) (Github Advisory).

Upgrade rclone to version 1.75.1 or later, which introduces centralized path confinement via list.RemoveEscaping() applied at all listing filter points, preventing any ..-escaping object from reaching destination backends (rclone v1.75.1, Fix Commit). As a workaround prior to patching, restrict rclone credentials to the minimum required permissions and audit source object stores for keys containing .. segments before running copy or sync operations. When ingesting from shared or untrusted sources, verify that no objects with path-traversal keys exist using native cloud provider tooling before initiating rclone transfers (Github Advisory).

The vulnerability was reported by researcher iaohkut and remediated by rclone maintainer Nick Craig-Wood (ncw), who published the advisory and patch simultaneously on September 4, 2026 (Github Advisory). Red Hat tracked the issue via Bugzilla (Bug 2531548) and assigned it medium severity, reflecting the constrained blast radius (Red Hat Bugzilla). No significant broader media coverage or notable community controversy has been observed beyond standard vulnerability database indexing.