CVE-2026-93987 in rclone
Summary
by MITRE • 09/19/2026
rclone versions 1.56.0 through 1.75.0 contain a path traversal vulnerability in the `rclone serve docker` volume plugin. newVolume() in cmd/serve/docker/volume.go computes a volume's mountpoint as filepath.Join(drv.root, name) from the attacker-supplied `name` field of a Docker VolumeDriver.Create request without verifying that the result stays within drv.root (default /var/lib/docker-volumes/rclone), and checkMountpoint() then creates that directory with file.MkdirAll before mounting. A volume name containing enough `..` components (e.g. "../../../../../../etc") therefore resolves outside the base directory, allowing anyone able to submit a VolumeDriver.Create request to the plugin socket — normally the Docker daemon, or a workload that can request named volumes in a multi-tenant orchestration setup — to make the privileged rclone plugin process create a directory and mount a remote filesystem specified in the same request at an arbitrary host path, shadowing or disrupting system directories. The advisory notes Volume.restoreState() had the same missing validation when reloading persisted volume state. Fixed in 1.75.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/19/2026
The vulnerability identified in rclone versions 1.56.0 through 1.75.0 represents a critical path traversal flaw within the docker serve plugin, specifically affecting the newVolume function located in cmd/serve/docker/volume.go. This component is responsible for processing Docker VolumeDriver.Create requests and determining the local mount point for remote storage backends. The core technical failure lies in the method used to compute this mountpoint, which relies on filepath.Join combining a driver root directory with an attacker-supplied name field from the request payload without performing any validation to ensure the resulting path remains within the intended base directory. By default, this root is set to /var/lib/docker-volumes/rclone, but the lack of boundary checks allows for arbitrary manipulation of the file system hierarchy through relative path traversal sequences such as ../../../../etc.
The operational impact of this flaw is severe because it enables an attacker with access to submit VolumeDriver.Create requests to leverage a privilege escalation scenario. In typical Docker environments, only the Docker daemon or workloads operating within multi-tenant orchestration setups can issue these requests, meaning that if container isolation is compromised or misconfigured, any such workload gains significant influence over the host file system. The checkMountpoint function subsequently creates this directory using file.MkdirAll before attempting to mount the remote filesystem specified in the same request. Consequently, an attacker can force the privileged rclone plugin process to create directories and mount external storage at arbitrary locations on the host machine. This capability allows for shadowing critical system directories or disrupting essential services by mounting conflicting file systems over them, effectively bypassing standard container isolation mechanisms.
This vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it involves insufficient validation of user-supplied input against the expected directory structure. Furthermore, from an offensive security perspective, this technique corresponds to ATT&CK T1564.008: Host File System Discovery and potentially T1496: Resource Hijacking if used for denial-of-service or persistence through mounted volumes. The advisory also highlights that Volume.restoreState contained a similar missing validation when reloading persisted volume state, indicating a systemic design flaw in how path components are handled during both creation and restoration phases of the plugin's lifecycle.
Mitigation strategies primarily involve upgrading to rclone version 1.75.1 or later where this issue has been resolved through rigorous input sanitization and strict boundary enforcement for all path operations within the docker serve plugin. For environments that cannot immediately upgrade, restricting network access to the Docker socket is critical since only authorized processes should be able to interact with it. Additionally implementing least-privilege principles in container orchestration platforms can limit which workloads are permitted to request named volumes, thereby reducing the attack surface available for exploitation of this path traversal mechanism until a permanent patch is applied.