CVE-2026-93986
LowCVSS 3.1Exploitation Probability (EPSS)
Low risk10th percentile - higher than 10% of all known CVEs
Summary
rclone before 1.75.1 fails to confine names from server and third-party listing responses to the listed directory, allowing path traversal sequences in object names. Attackers can craft special names containing forward slashes and parent directory references to potentially write outside the destination root, though downstream protections in the local backend currently block actual file escape.
Risk Assessment
An attacker may attempt to write files outside the destination directory, which could lead to overwriting or exposing data if backend protections are absent. The local backend currently blocks actual escape, but other backends may be vulnerable.
Recommendation
Upgrade rclone to version 1.75.1 or later. Avoid using untrusted remote sources and validate object names before writing.
Other vulnerabilities in rclone
See all- CVE-2026-88044Critical
rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.70.0 until 1.75.1, the serve/start RC interface accepts per-server proxyOpt.AuthProxy settings, and the FTP and S3 constructors in cmd/serve/ftp/ftp.go and cmd/serve/s3/server.go incorrectly check the process-global proxy.Opt.AuthProxy value instead. When the global value is empty, the request-local authentication proxy is ignored: FTP falls back to the fixed filesystem with username anonymous and any password, while S3 with AuthKey serves the fixed RC fs rather than the backend selected by the proxy. The dedicated command-line servers that configure the global option are not affected. This issue is fixed in version 1.75.1.
- CVE-2026-88018Critical
rclone is a command-line program to sync files and directories to and from different cloud storage providers. Prior to 1.75.1, rclone serve s3 configured with --auth-proxy but without --auth-key allows authPairMiddleware to register any client-chosen accessKeyID with an empty ws.s3Secret. gofakes3 then verifies the request’s SigV4 signature against that same empty secret, while Server.auth passes the access key identifier as both the user and authentication value to the proxy without an independent per-identity secret. An unauthenticated network attacker can therefore choose an arbitrary access key, sign with an empty secret, and reach whatever backend the auth-proxy script resolves for that identity. This issue is fixed in version 1.75.1.
- CVE-2026-49980Critical
Rclone versions 1.46.0 through 1.74.2 have a vulnerability in server mode (rcd --rc-serve) that allows unauthenticated GET and HEAD requests to execute arbitrary system commands. An attacker can craft a URL containing remote storage configuration that executes local commands during initialization.
- CVE-2026-41179Critical
In Rclone from version 1.48.0 to 1.73.4, the RC endpoint `operations/fsinfo` is exposed without `AuthRequired: true` and accepts attacker-controlled `fs` input. An unauthenticated attacker can exploit this to execute arbitrary local commands on the server via the WebDAV backend, which runs `bearer_token_command` during initialization.
- CVE-2026-41176Critical
In Rclone, the RC endpoint `options/set` is exposed without `AuthRequired: true`, allowing modification of global runtime configuration. An unauthenticated attacker can set `rc.NoAuth=true`, disabling the authorization gate for many RC methods that normally require authentication, leading to unauthorized access to sensitive administrative functionality.
- CVE-2026-93987Low
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 to make the privileged rclone plugin process create a directory and mount a remote filesystem at an arbitrary host path. Volume.restoreState() had the same missing validation when reloading persisted volume state. Fixed in 1.75.1.
- CVE-2026-88046Medium
Prior to rclone 1.75.1, the core does not reject parent-directory segments in source Object.Remote() values before fs/list, fs/walk, fs/sync, and fs/operations pass them to destination backends. A flat-keyspace source object store can contain a raw ".." key segment, and affected destinations use path.Join(root, remote) before EncodeDot can neutralize the segment, allowing a copy or upload to escape the configured root. This issue is fixed in version 1.75.1.
- CVE-2026-88045High
rclone from 1.75.0 until 1.75.1, in the serve S3 streamed multipart path, passes attacker-controlled contentLength to multipart.NewRW().Reserve before reading request-body bytes. A network client can retain or multiply these reservations without sending the declared body, exhausting process or host memory or permanently blocking request handlers. This is fixed in 1.75.1.
- CVE-2026-88017High
rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.64.0 until 1.75.1, the FTP auth-proxy driver in cmd/serve/ftp/ftp.go stores one obscured password per username in the server-wide userPass map[string]string instead of binding the credential or VFS to the authenticated session. If two accepted credentials use the same username but resolve to different proxy backends, a later CheckPasswd login overwrites userPass[user], and subsequent getVFS operations on the first session are reauthorized with the later password. The first session can then read, create, overwrite, rename, or delete objects using the second credential’s backend authority. Exploitation requires the later same-username login to occur while the first session remains open. This issue is fixed in version 1.75.1.
- CVE-2026-88016High
rclone is a command-line program to sync files and directories to and from different cloud storage providers. Prior to 1.75.1, when backend/local runs with --links, a source .rclonelink object can plant a symlink in the destination and later directory metadata is applied through that path. MkdirMetadata, writeMetadataToFile, and setTimes operate when Directory.translatedLink=false, so os.Chown, os.Chmod, os.Chtimes, and birth-time handling can bypass os.Root confinement and follow the symlink. An attacker controlling source contents can therefore apply selected ownership, permissions, modification times, or birth times to a file or directory outside the destination, with --metadata required for chmod and chown while modification time is applied by the normal directory workflow. This issue is fixed in version 1.75.1.
Original NVD description (English source)
rclone before 1.75.1 fails to confine names from server and third-party listing responses to the listed directory, allowing path traversal sequences in object names. Attackers can craft special names containing forward slashes and parent directory references to potentially write outside the destination root, though downstream protections in the local backend currently block actual file escape.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

