CVE-2026-88014: Path Traversal (Zip Slip) and Directory Boundary Bypass in rclone ZIP Backend

The open-source command-line utility rclone allows users to manage and synchronize files across local and cloud storage backends. Within versions 1.72.0 up to (but excluding) 1.75.1, the archive ZIP backend implementation contains a path traversal vulnerability. When mounting, reading, copying, or syncing from an archive using this backend, rclone fails to ensure that the parsed file paths remain within the destination namespace.\n\nThis lack of strict namespace boundary verification enables directory traversal sequences, such as relative dot-dot (..), to bypass safety checks. The issue primarily affects the readZip function in backend/archive/zip/zip.go. An attacker who can influence the ZIP archive supplied to rclone can execute arbitrary file write operations on the destination filesystem.\n\nIn addition to path traversal, a secondary logic flaw exists within the subdirectory containment mechanism. If a subdirectory root is specified to limit operations, rclone uses prefix matching without a trailing slash delimiter. This allows directories sharing a prefix (e.g., 'foobar' and 'foo') to overlap, resulting in unauthorized folder inclusion and exposure.\n\nmermaid\ngraph LR\n A["ZIP Entry: ../../file"] --> B["path.Clean()"]\n B --> C["Result: ../../file"]\n C --> D["Target System Root Escape"]\n

The core vulnerability lies in how rclone processes metadata returned by the Go standard library's archive/zip package. The standard library provides the file.Name field exactly as it appears in the ZIP file central directory header, without performing any validation or filtering on relative path components.\n\nIn the vulnerable implementation, the readZip method processes each entry using Go's lexical path utility: path.Clean(file.Name). While path.Clean collapses intermediate directory levels and removes duplicate separators, it does not neutralize leading relative path segments if there are no preceding directories to offset them. For example, path.Clean('../../etc/cron.d/evil') resolves exactly to ../../etc/cron.d/evil.\n\nBecause the empty root configuration is the default mode when extracting a ZIP file, these unneutralized parent directory markers flow directly into rclone's synchronization and copy engines. If the destination storage backend lacks independent confinement, the file paths resolve relative to the system root, permitting arbitrary file creation or overwrite.\n\nFurthermore, the subdirectory isolation checks used a simple strings.HasPrefix(remote, f.root) call. Without verifying that the match is followed by a path separator, a configured root of foo matches any sibling beginning with those three letters, such as foobar/data.txt.

Below is the relevant segment of the vulnerable code in backend/archive/zip/zip.go before the patches were applied:\n\ngo\n// Vulnerable implementation\nfor _, file := range zr.File {\n\tremote := strings.Trim(path.Clean(file.Name), "/")\n\tif remote == "." {\n\t\tremote = ""\n\t}\n\tremote = path.Join(f.prefix, remote)\n\tif f.root != "" {\n\t\t// Ignore all files outside the root\n\t\tif !strings.HasPrefix(remote, f.root) {\n\t\t\tcontinue\n\t\t}\n\t}\n}\n\n\nIn the patched code, the utility sanitize.Path is introduced. This function identifies and blocks absolute paths and directory traversal structures, such as those targeting parent namespaces via .. delimiters:\n\ngo\n// Patched implementation\nfor _, file := range zr.File {\n\t// Skip entries whose name escapes the archive's own namespace\n\tremote, err := sanitize.Path(file.Name)\n\tif err != nil {\n\t\tskipped++\n\t\tcontinue\n\t}\n\tremote = path.Join(f.prefix, remote)\n\tif f.root != "" {\n\t\t// Ignore all files outside the root, requiring a path\n\t\t// boundary so that root "foo" does not also match a\n\t\t// sibling entry such as "foobar"\n\t\tif remote != f.root && !strings.HasPrefix(remote, f.root+"/") {\n\t\t\tcontinue\n\t\t}\n\t}\n}\n\n\nThe revised logic ensures that all relative trajectories are safely trapped, and that subdirectory isolation is guaranteed by appending the / path delimiter during the prefix comparison step.

An attacker must craft a ZIP archive where the central directory header contains one or more file names embedded with path traversal components. Since standard compression tools often automatically strip relative paths, the malicious archive must be generated programmatically or modified using hex-editing techniques.\n\nFor example, an entry named ../../../../etc/cron.d/malicious_job is packaged inside payload.zip. The target user must then execute an rclone operation against the archive, using either the copy, sync, or mount functions. An example command sequence is shown below:\n\nbash\nrclone copy :zip:payload.zip /home/user/target_directory\n\n\nUpon execution, rclone reads the metadata, resolves the target destination relative to the output root, and processes the relative markers. This shifts the target file write outside of /home/user/target_directory and directs it straight to /etc/cron.d/malicious_job. If the rclone command is executed with sufficient host permissions, the file is successfully created, potentially leading to privilege escalation or arbitrary command execution via cron.

The impact of CVE-2026-88014 is primarily classified as an Integrity compromise, rated with a CVSS v3.1 base score of 6.3. The attack complexity is low, but exploitation is contingent on user interaction, as a victim must run rclone on a crafted zip file.\n\nThe potential consequences are dictated by the permissions of the user running the rclone process. If executed within an automated backup pipeline or system task running as the root user, an attacker can modify sensitive files such as shell profiles, cron directories, systemd service units, or authorization keys.\n\nThe secondary path matching issue compromises Confidentiality and Integrity by allowing a user restricted to folder foo to read and write files within folder foobar. This exposes shared multi-tenant environments to cross-directory access and unexpected data manipulation.

The primary remediation strategy is upgrading all rclone clients and installations to version 1.75.1 or later. The patch completely sanitizes relative path sequences in ZIP entry extraction and implements strict path-delimiter checking on subdirectory matching.\n\nIf immediate software upgrade is not possible, the following defensive configurations should be established:\n\n* Restrict user access to the ZIP backend implementation by filtering or blocking the :zip: remote scheme in untrusted environments.\n* Execute rclone operations inside sandboxed environments or under low-privileged accounts using system controls like AppArmor, SELinux, or Docker boundaries.\n* Implement strict write restrictions on the directory target, ensuring the execution process cannot write outside of its specified home directory or workspace.