CVE-2026-88046 in rcloneinfo

Summary

by MITRE • 09/10/2026

rclone is a command-line program to sync files and directories to and from different cloud storage providers. Prior to 1.75.1, rclone core does not reject parent-directory segments in source Object.Remote() values before fs/list, fs/walk, fs/sync, and fs/operations pass those values to destination backends. A flat-keyspace source object store populated with native non-rclone tooling can contain a raw .. key segment, and affected b2, swift, qingstor, oracleobjectstorage, internetarchive, smb, storj, sftp, webdav, ftp, filelu, shade, and sia destinations use path.Join(root, remote) before EncodeDot can neutralize the segment. A copy or upload can therefore escape the configured root into another bucket, share, or path reachable by the victim credential, with sftp and smb potentially reaching other filesystem or share locations under the same login authority. This issue is fixed in version 1.75.1.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 09/10/2026

The vulnerability identified in rclone prior to version 1.75.1 represents a critical path traversal flaw within the core synchronization logic, specifically affecting how source object keys are processed before being passed to destination backends. Rclone is widely utilized for synchronizing files and directories across various cloud storage providers, relying on the assumption that input paths are sanitized or inherently safe when interacting with remote filesystems. However, in versions preceding 1.75.1, the core component failed to reject parent-directory segments, denoted by double dots (..), within source Object.Remote() values during critical operations such as listing, walking, syncing, and general file operations. This oversight creates a significant security gap because it allows an attacker or malicious actor to manipulate the intended directory structure of the destination storage system through carefully crafted input paths originating from the source side.

The technical root cause lies in the order of operations within the rclone codebase for several specific backend implementations, including b2, swift, qingstor, oracleobjectstorage, internetarchive, smb, storj, sftp, webdav, ftp, filelu, shade, and sia. These backends utilize a path joining mechanism that combines the configured root directory with the remote source path using standard library functions like path.Join before applying encoding or sanitization routines such as EncodeDot. When a flat-keyspace source object store is populated by native tools outside of rclone's control, it may contain raw key segments containing double dots. Because the destination backends process these paths without prior validation against parent-directory traversal sequences, the resulting joined path can escape the intended root directory boundary. This behavior effectively bypasses access controls that rely on restricting operations to a specific subdirectory or bucket within the storage provider.

The operational impact of this vulnerability is severe, as it enables unauthorized data exfiltration and potential compromise of broader infrastructure depending on the destination type. For cloud object stores such as b2, swift, oracleobjectstorage, internetarchive, storj, filelu, shade, and sia, a successful exploitation allows an attacker to write files into other buckets or shares that are accessible by the victim's credentials but were not intended for this specific rclone instance. This can lead to data leakage if sensitive information is written to publicly accessible locations within those broader storage accounts, or it may allow attackers to overwrite critical configuration files or application assets in unintended directories. In scenarios involving smb and sftp destinations, the risk escalates significantly because these protocols interact with underlying operating system file systems rather than isolated object stores. Consequently, path traversal can lead to writing files into arbitrary locations on the server's filesystem under the same login authority, potentially allowing for remote code execution if writable script or configuration directories are targeted, or facilitating further lateral movement within the network by placing malicious payloads in accessible paths.

This vulnerability aligns with Common Weakness Enumeration (CWE) categories such as CWE-22: Improper Limitation of a Pathname to a Restricted Directory and CWE-73: External Control of File Name or Path. From an adversary perspective, this technique corresponds to ATT&CK tactic T1083: File and Directory Discovery, specifically the subtechnique involving path traversal for unauthorized access, as well as potential data exfiltration vectors under T1567 if sensitive files are written to accessible external locations. The lack of input validation on source-side paths before backend processing is a classic example of trusting untrusted inputs in security-critical operations, highlighting the necessity for strict sanitization at the earliest possible point in the request lifecycle.

To mitigate this risk, organizations must immediately upgrade rclone to version 1.75.1 or later, where the issue has been resolved by implementing proper rejection logic for parent-directory segments before they are passed to destination backends. In environments where upgrading is not immediately feasible, administrators should enforce strict input validation on any scripts or tools that generate source paths fed into rclone, ensuring that no double-dot sequences are present in remote object keys. Additionally, applying principle of least privilege by restricting the permissions of the service account used for synchronization can limit the blast radius if a traversal attempt occurs, particularly preventing write access to critical system directories when using smb or sftp backends. Regular auditing of rclone configurations and source data integrity checks should also be implemented to detect any anomalies in path structures that might indicate exploitation attempts.

Responsible

GitHub M

Reservation

09/09/2026

Disclosure

09/10/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you know our Splunk app?

Download it now for free!