CVE-2026-71313: Local Directory Traversal in rclone via Unsafe Encoding Configurations

The affected component is rclone's local backend implementation. Rclone is a widely used command-line utility designed to synchronize files and directories between local storage and various cloud storage providers. The local backend manages direct file and directory read/write operations when syncing files onto the host operating system. This component exposes a critical attack surface whenever rclone operates on untrusted remote repositories.

The vulnerability is classified under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory / 'Path Traversal'). When certain non-default local destination encoding configurations are enabled, rclone maps standard-encoded fullwidth dot sequences into directory traversal path components. The local directory boundary constraint is not validated during this decoding process, which allows remote storage sources to write to arbitrary paths.

The vulnerability has an impact on file integrity and availability. An attacker who controls a synchronized remote repository can construct specific filenames that escape the intended local destination directory when downloaded by a vulnerable client configuration. This enables unauthorized write operations to administrative or critical system paths on the target machine.

To safely process object names across disparate file storage platforms, rclone uses a standardized transformation architecture. Many cloud storage providers allow characters that are restricted on local host filesystems, such as backslashes, colons, or relative directory markers. Rclone translates these dangerous remote characters into safe Unicode equivalent representations during standard operation to prevent directory traversal and file corruption during synchronization.

Specifically, a double-dot relative reference (..) is translated into fullwidth double dots (．．) during transmission. Under default configurations, when the local backend writes these files to the local disk, the standard encoder (defined by encoder.OS) maintains safety by preserving the fullwidth characters or applying safe transformations. This translation logic is handled by the FromStandardPath function, which maps normalized paths back to native representations.

However, if the local backend's encoding is manually configured to exclude the Dot flag, such as with --local-encoding Slash, None, or Raw, FromStandardPath translates the safe fullwidth dot sequence (．．) back into native literal dots (..). This output is then passed to Go's filepath.Join function alongside the target root path of the synchronization directory.

Go's filepath.Join automatically cleans the combined string to evaluate relative path segments. While filepath.Join removes redundant path separators and simplifies relative steps, it does not restrict the resolved path from climbing past the parent boundaries of the root folder. If the relative input contains sufficient parent directory sequences, the final clean path is resolved entirely outside of the intended target directory.

Prior to version v1.75.0, the path resolution in rclone's local backend relied entirely on the encoding subsystem to prevent traversal. The following snippet illustrates the vulnerable path calculation logic within backend/local/local.go:

// Vulnerable path calculation in local.go
func (f *Fs) localPath(name string) string {
	// f.opt.Enc.FromStandardPath decodes fullwidth characters based on configuration
	// filepath.FromSlash converts forward slashes to native OS separators
	// filepath.Join resolves the combined path but lacks boundary validation
	return filepath.Join(f.root, filepath.FromSlash(f.opt.Enc.FromStandardPath(name)))
}

If the configuration excludes the Dot flag, the returned path escapes the designated root without raising an error. The patch in version v1.75.0 addresses this by introducing a post-resolution verification check. This check computes the relationship between the final path and the intended destination root using the standard library's filepath.Rel function:

// Patched path calculation in local.go
func (f *Fs) localPath(name string) (string, error) {
	native := filepath.FromSlash(f.opt.Enc.FromStandardPath(name))
	localPath := filepath.Join(f.root, native)
	
	// Calculate the relative path from the root to the target path
	rel, err := filepath.Rel(f.root, localPath)
	
	// If the calculation fails, or if the relative path resolves to parent directories,
	// return an explicit path escape error
	if err != nil || rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator)) {
		return "", fserrors.NoRetryError(fmt.Errorf("%q: %w", name, errPathEscapes))
	}
	return localPath, nil
}

This refactoring changes the function signature to return both the path string and an error. When the path resolution escapes the directory boundary, the function returns a non-retryable error (errPathEscapes). Every caller within local.go that accesses the filesystem was updated to handle this error and abort the write transaction immediately.

Exploitation of this vulnerability requires a set of specific execution criteria. First, an attacker must control or gain write access to a remote repository that is synchronized by a target user. The attacker populates this remote source with objects containing encoded traversal patterns. For instance, the attacker creates an object named ．．/．．/etc/cron.d/malicious_cron within the remote cloud bucket.

Second, the victim must run rclone with a command-line configuration that overrides the default safe encoding of the local destination. The command must specify an encoding that omits the standard Dot translation, as shown in the following example execution:

rclone sync remote:source /var/tmp/sync_destination --local-encoding Slash

During synchronization, rclone fetches the object list and decodes the standard fullwidth dot sequence into native directory traversal characters (..). Because the destination path is resolved purely via filepath.Join without containment checks, the local backend writes the attacker-supplied file content to the host directory, bypasses the /var/tmp/sync_destination boundary, and deposits the payload directly in /etc/cron.d/.

The security consequences of a successful path traversal exploit are significant and depend on the execution privileges of the rclone process. If the command runs with administrative or root permissions, the attacker can overwrite sensitive system files or inject executable scripts into system-wide directories such as /etc/cron.d or /etc/profile.d. This results in arbitrary code execution with the permissions of the host operating system.

In environments where rclone runs as an unprivileged user, the exploit remains highly impactful. The attacker can modify or overwrite user configuration files like ~/.bashrc, ~/.ssh/authorized_keys, or local application files. These modifications allow for local privilege escalation, persistent access, or lateral movement within the network.

The CVSS v3.1 base score of 6.9 is characterized by a network attack vector and high integrity impact, but requires high attack complexity because the vulnerability depends on specific user configuration choices. The scope of the attack is changed because the security controls separating the synchronized directory from the surrounding operating system filesystem are bypassed entirely.

The most effective remediation is to upgrade rclone to version v1.75.0 or later. In these updated versions, the local backend natively implements the filepath.Rel validation step, terminating the sync operation and throwing a path escape error before executing any local file creation or modification commands.

If immediate system upgrades are not feasible, administrators must audit all automated scripts, cron tasks, and user configuration files to ensure that custom local encoding options are disabled. In particular, configurations must not define --local-encoding or the equivalent configuration keys with parameters such as Slash, None, or Raw. The default encoder settings must be restored to guarantee standard safety protections.

As a defense-in-depth practice, rclone processes should be executed under restricted user profiles or containerized sandboxes. Restricting the file system access of the process using mechanisms like AppArmor, SELinux, or lightweight containers limits the impact of potential directory traversals by ensuring the process cannot write to critical administrative system directories even if a path escape occurs.