CVE-2026-88016: Arbitrary Filesystem Metadata Modification and Directory Traversal in rclone

Rclone is a command-line program used to manage and synchronize files across local filesystems and cloud storage providers. When executing directory synchronization, security constraints must ensure that file and directory operations remain confined within the specified destination path. Earlier security updates introduced an os.Root abstraction designed to restrict filesystem operations to a designated root directory.

CVE-2026-88016 represents a high-severity directory traversal and arbitrary metadata modification vulnerability in rclone versions prior to 1.75.1. The flaw occurs when rclone processes directory-level objects while operating with the --links (-l) flag. An attacker who controls the source of a synchronization run can manipulate filesystem metadata on arbitrary directories or files outside the intended destination directory.

This vulnerability is classified under CWE-59: Improper Link Resolution Before File Access ('Link Following') and CWE-281: Improper Preservation of Permissions. It allows an attacker to bypass the directory sandboxing mechanism (os.Root jail) and perform actions like arbitrary permissions modification (chmod), ownership changes (chown), and timestamp manipulation (chtimes or btime) on sensitive host target files.

The vulnerability originates in the architectural distinction between how rclone handles standard file objects and how it handles directory objects. For files that represent symbolic links, rclone tracks them using a .rclonelink suffix and marks them with the translatedLink attribute set to true. This attribute forces rclone to call secure, non-following system calls such as os.Lchown when modifying metadata, preventing the application from resolving the link.

However, directory objects created during synchronization do not feature the .rclonelink suffix. Consequently, their translatedLink attribute is always set to false. During a metadata synchronization run, the MkdirMetadata function in the local backend attempts to determine if the destination path already exists on the disk. It checks this state by executing a standard os.Lstat call.

If an attacker has previously planted a symbolic link at that destination path pointing to an external directory, the os.Lstat call succeeds. The error evaluation errors.Is(err, os.ErrNotExist) returns false, causing rclone to skip the secure, sandboxed f.Mkdir function. Rclone then creates a Directory object mapped directly to the path of the existing symbolic link.

Because translatedLink is false for this directory object, rclone drops through to the default, non-symlink execution branch inside writeMetadataToFile and setTimes. It invokes raw standard library calls such as os.Chmod, os.Chown, and os.Chtimes directly on the path. On POSIX-compliant systems, these system calls follow symbolic links, resulting in the modifications being applied directly to the external target instead of the link itself.

The core patch (commit a7ab39d3d1958afa1446982c1dc4e4a73a887e3e) resolves the flaw by introducing path-confinement checks for directory-level permissions, ownership, and time modifications. The patch implements secure chmod, chown, and chtimes wrappers inside backend/local/local.go. These wrappers dynamically fetch the secure os.Root instance if the TranslateSymlinks configuration option is enabled.

// Vulnerable implementation in backend/local/metadata.go
// Directly invoked standard library functions that follow symlinks
err = os.Chown(o.path, uid, gid)
err = os.Chmod(o.path, fileMode)

The patch changes these calls to go through the newly created local filesystem wrappers. The following code snippet shows the safe wrapper implementations added to backend/local/local.go:

// Patched wrappers in backend/local/local.go
func (f *Fs) chmod(localPath string, mode os.FileMode) (err error) {
    if !f.opt.TranslateSymlinks {
        return os.Chmod(localPath, mode)
    }
    root, rel, err := f.osRoot(localPath)
    if err != nil {
        return err
    }
    defer fs.CheckClose(root, &err)
    return root.Chmod(rel, mode)
}

Additionally, a secondary patch (commit 17b0c03338a857bcb0a68d2d4c82ddbdec3f7893) secures birth-time (btime) modifications on systems supporting it, such as Windows. Previously, rclone only checked the translatedLink attribute to decide whether to use the non-following lsetBTime function. The patch ensures that if symbolic link translation is active (o.fs.opt.TranslateSymlinks), rclone forces the use of lsetBTime, blocking out-of-bounds writes via symlink targets.

Exploitation of CVE-2026-88016 relies on a multi-stage synchronization attack path. To initiate the attack, the target system must execute rclone with the --links (or -l) flag, and the synchronization source must be under the control of the attacker. The target execution must also include the --metadata flag to trigger ownership and permission changes, although timestamp modifications can be triggered without it.

The attack begins with the placement phase. The attacker writes a symlink representation on the source repository, named pwn.rclonelink, pointing to a sensitive file or directory on the host filesystem (for instance, /etc/shadow or /home/victim/secret.d). When the victim executes the first synchronization run, rclone parses the link file and writes a physical symbolic link at /dest/pwn pointing to the target.

Once the symbolic link is planted at the destination, the attacker performs the swap phase. The attacker deletes the pwn.rclonelink file on the source and replaces it with a physical directory named pwn/. The attacker configures this directory's permissions on the source to be wide open (e.g., 0777) and modifies its owner or group IDs if targeting ownership.

When the victim performs a second synchronization run with metadata enabled, rclone processes /dest/pwn. Since a symbolic link already exists at /dest/pwn, the os.Lstat call returns success, skipping the safe creation function. Rclone then processes the path as a directory object, executing os.Chmod on /dest/pwn. The kernel resolves the symbolic link, modifying the file permissions of /etc/shadow to 0777, allowing low-privileged access.

The following diagram details the sequence of the attack chain and explains the logical breakdown where rclone bypasses its internal sandboxing environment:

The impact of CVE-2026-88016 is categorized as high, with a CVSS v3.1 base score of 7.1. The severity is driven by the potential for an attacker to break out of rclone's sandboxed environment and alter the security state of the underlying host operating system. The scope of the vulnerability is changed because the target of the manipulation is situated outside the designated destination folder.

In environments where rclone is executed with elevated permissions (such as a root-level system backup daemon or a cron job running as an administrator), the exploit path allows immediate local privilege escalation. By pointing the planted symbolic link to /etc/passwd or /etc/shadow and setting the directory permissions on the source to writable levels, an attacker can modify system account details or manipulate credentials.

For systems running rclone under lower-privileged service accounts, the impact remains significant. Attackers can gain unauthorized read or write access to confidential user configurations, SSH authorized keys, or operational environment files. This can lead to broader lateral movement and persistent access across the affected network infrastructure.

The primary remediation strategy is upgrading the installed rclone binaries to version 1.75.1 or later. The patch implements strict confinement checks on directory-level metadata operations, neutralizing the symbolic link following vector. Organizations should audit all scheduled sync workflows to ensure they use updated versions of the rclone tool.

For environments where immediate upgrading is not feasible, several temporary workarounds can mitigate the risk. The most effective mitigation is removing the --links (or -l) flag from any synchronization routines processing untrusted source directories. Without this flag, rclone will ignore symbolic link definitions on the source, preventing the planting phase of the attack.

Alternatively, if link replication is required, users should disable the --metadata flag. While this does not prevent modification of directory modification times (chtimes), it eliminates the risk of unauthorized permissions modifications (chmod) and ownership takeovers (chown). Running the sync process under a dedicated, low-privileged user account further restricts the write scope of followed symlinks.