Rclone
Monthly
Path traversal in rclone's local backend (versions through 1.75.1) allows an attacker who can plant a directory named '...rclonelink' inside a source tree to redirect directory metadata operations one level above the destination the operator selected. The flaw only triggers when a sync targets a local destination with both --links/-l and --metadata enabled, and it is metadata-only: content writes remain blocked by the earlier os.Root hardening, and ownership changes require rclone to run as root, while non-root runs are limited to rewriting timestamps and extended attributes of the destination's parent directory. Exploitation status at time of analysis: no public exploit code confirmed by intelligence sources, although the upstream advisory documents a working reproduction; the vendor has released rclone 1.75.2 as the fix, and priority is routine (patch within the current cycle).
Cross-site request forgery in the pCloud backend of Rclone 1.52.0 through 1.75.1 lets a malicious web page silently rebind a victim's pCloud remote to an attacker-controlled OAuth token and API host, so subsequent `rclone sync` transfers upload files to the attacker and return attacker-chosen content. The flaw is reachable only while the victim is actively running the interactive authorization flow (`rclone config` or `rclone authorize pcloud`), which leaves the localhost callback listener on the fixed port 127.0.0.1:53682 open; a single stateless cross-site GET to that port during the window is accepted because the pCloud backend is the only one in the tree that sets `StateBlankOK: true`, disabling the OAuth `state` check. No KEV entry and no confirmed active exploitation were reported, but a full local proof-of-concept reproduction is published in the upstream advisory, and Rclone 1.75.2 is the fixed release.
Server-side request forgery in rclone's read-only RC file server (--rc-serve) lets unauthenticated users who can reach an exposed RC listener redirect http and netstorage backend requests to attacker-chosen hosts by supplying a root that begins with a double slash on an existing named remote. Successful requests return the target's response body to the requester, leak the named HTTP remote's configured custom headers to the selected host, and - for netstorage remotes - yield valid, time-bound request signatures for attacker-chosen stat and download paths. Exploitation requires a non-default deployment (--rc-serve enabled, listener reachable, no RC HTTP authentication, a known http or netstorage remote name), which is why the supplied assessment scores it CVSS:3.1 5.9 with AC:H despite the 8.2 CVSS 4.0 vector; there is no CISA KEV entry, and the advisory publishes loopback mock reproduction scripts that demonstrate synthetic-credential impact only, so no confirmed exploitation in the wild is indicated.
Path traversal in rclone's `serve webdav` front-end, in every build up to and including 1.75.1, lets remote unauthenticated attackers write outside the directory rclone was told to serve: a single `MKCOL /..` request plants a VFS node whose backend path is literally `..`, after which PUT, MOVE, COPY, MKCOL and DELETE all resolve above the served root - creating, overwriting, moving out and (by known name, after a client PUT) deleting other tenants' files. Impact is integrity-only: reads and enumeration above the root still fail with 404 because the read path filters entries through the existing `RemoteEscapesRoot`/`RemoveEscaping` predicate while the write path never asks it. Vendor-released patch: 1.75.2; the GitHub advisory carries detailed public reproduction steps (a public PoC reference exists, not verified as working exploit code), there is no CISA KEV confirmation of active exploitation in the supplied data, and the vuln.today priority label is `this_week`.
Signature verification bypass in rclone stable selfupdate (versions 1.55.0 through 1.75.1) lets an attacker who controls the authenticated release-distribution responses prepend an unsigned SHA-256 checksum for a malicious archive ahead of the genuine PGP-clearsigned SHA256SUMS block, causing selfupdate to accept and extract an attacker-controlled rclone executable. Exploitation requires origin, CDN, or TLS-termination compromise or trusted-certificate interception plus a user running stable `rclone selfupdate` without `--check`; the beta channel is unaffected and ordinary unauthenticated interception is insufficient. The issue is rated High (CVSS 4.0 7.7; independent CVSS 3.1 7.5), fixed in 1.75.2, is not listed in CISA KEV in the supplied data, and has a public PoC reference that demonstrates the bypass and archive extraction but does not complete installation.
Memory exhaustion in rclone 1.75.0's serve S3 multipart upload handler allows remote attackers to exhaust process or host memory and permanently block request handlers by sending UploadPart requests that declare a large Content-Length but deliver no body bytes. The handler in cmd/serve/s3/multipart.go pre-allocates lib/pool pages sized to the attacker-controlled Content-Length header before any body bytes arrive, and the waitForTurn scheduling mechanism admits one additional oversized part even when --multipart-streaming-buffer-limit is active, partially bypassing the intended cap. The issue is fixed in rclone v1.75.1; no public exploit or CISA KEV listing has been identified.
Authentication/authorization bypass in rclone's dynamic serve interface (versions 1.70.0 through 1.75.0) lets remote attackers reach a fixed filesystem instead of the per-request backend the operator intended. When an FTP or S3 server is spun up via the serve/start RC (remote control) API with a per-server proxyOpt.AuthProxy, the FTP and S3 constructors mistakenly consult the empty process-global proxy.Opt.AuthProxy, so the request-local auth proxy is silently ignored: FTP accepts anonymous logins with any password against the fixed VFS, and S3 with AuthKey serves the fixed RC fs rather than the proxy-selected backend. There is no public exploit identified at time of analysis, and this is not in CISA KEV. Fixed in 1.75.1.
Authentication bypass in rclone's S3 server mode (rclone serve s3) allows any unauthenticated network attacker to impersonate arbitrary S3 access keys. When rclone serve s3 is started with --auth-proxy but without --auth-key, authPairMiddleware registers whatever accessKeyID the client chooses against an empty s3Secret, and gofakes3 then validates the request's SigV4 signature against that same empty secret - so an attacker can pick any access key, sign with an empty secret, and reach whatever backend the auth-proxy script resolves for that identity. Fixed in rclone 1.75.1; no public exploit identified at time of analysis, though the vendor security advisory (GHSA-xwwr-4h3p-r22c) and fix commit are public.
Cross-session credential isolation failure in rclone's FTP auth-proxy driver (versions 1.64.0-1.75.0) allows an authenticated network attacker to hijack a victim user's cloud storage backend by exploiting a server-wide, username-keyed credential map. When an attacker holds an open FTP session using a shared username and a victim subsequently authenticates with the same username, the victim's credential silently overwrites the server-wide map entry - causing the attacker's subsequent VFS operations to execute against the victim's backend, enabling reads, writes, renames, and deletions of the victim's cloud objects. No public exploit identified at time of analysis; vendor-released patch v1.75.1 resolves the issue.
Symlink escape in rclone's local backend (prior to v1.75.1) allows an attacker who controls sync source contents to apply metadata - ownership, permissions, or timestamps - to files and directories outside the intended destination root. When `--links` is enabled, a crafted `.rclonelink` entry plants a symlink in the destination; subsequent metadata routines (`MkdirMetadata`, `writeMetadataToFile`, `setTimes`) incorrectly skip the symlink guard and call `os.Chown`, `os.Chmod`, `os.Chtimes`, and birth-time syscalls through the planted link, bypassing `os.Root` confinement. Vendor-released patch is confirmed in v1.75.1; no active exploitation has been identified at time of analysis.
Cleartext disclosure of AWS STS session tokens affects rclone before 1.74.4 when its S3 backend follows a redirect that keeps the same host:port but downgrades the scheme from HTTPS to HTTP. The redirect-safety logic added in v1.74.3 (commit e7b1eb774) compares only URL.Host and ignores URL.Scheme, so the X-Amz-Security-Token header is re-sent over the now-plaintext connection, letting any passive observer on the path harvest the temporary credential. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Denial-of-service vulnerabilities in rclone's archive backend SquashFS parser allow an attacker with write access to rclone-exposed storage to crash the rclone process or exhaust CPU. Affected versions v1.72.0 through v1.74.4 fail to validate attacker-controlled superblock and inode metadata values sourced from the go-diskfs dependency before use, enabling three distinct panic/loop conditions. When the :archive: remote is exposed via 'rclone serve sftp', exploitation crashes the entire SFTP server. No public exploit has been identified at time of analysis, but the attack surface is concrete and parser triggering is straightforward once a malicious image is placed.
PowerShell smart-quote filename injection in rclone's SFTP backend allows an attacker who controls remote filenames to execute arbitrary PowerShell commands as the victim's SSH account on the server. All rclone versions prior to v1.75.0 are affected when the SFTP remote uses PowerShell as the SSH command shell and server-side hashing is invoked. A proof-of-concept was confirmed by the GHSA advisory author; no CISA KEV listing was present at time of analysis, but the specific attack conditions meaningfully constrain real-world exposure to Windows-hosted or PowerShell-shelled SFTP deployments.
Path traversal in the `rclone serve restic --private-repos` REST server (versions prior to 1.74.4) allows an authenticated low-privileged user to read, overwrite, or delete another tenant's private restic repository. Authorization is enforced against the routed user path segment, but the backend object key is built from the raw, uncleaned URL path, so a request such as `//..//config` passes the per-user check while resolving to a different user's data on storage backends that clean path components. No public exploit has been identified at time of analysis, but the fix and a regression test are public in the vendor commits, and EPSS risk is modest (0.52%).
Arbitrary file write via symlink traversal in Rclone prior to 1.74.4 lets an attacker-controlled remote escape the local sync destination when a victim runs a copy/sync with the -l/--links flag. Rclone stores symlinks as .rclonelink text objects and recreates them on the local target without validating the link target, so a malicious remote can plant an escaping symlink and have a subsequent object write land outside the chosen destination with attacker-chosen contents. Publicly available exploit code exists (GHSA PoC), but there is no evidence of active exploitation and EPSS is low (0.34%).
Rclone's Backblaze B2 backend sends the live account Authorization token and any configured SSE-C encryption key headers to a custom download host when --b2-download-url is set, and it follows redirects with Go's default policy that inspects host but not scheme. A same-host HTTPS-to-HTTP downgrade from that download host replays the full-capability B2 bearer token in cleartext to an on-path observer, while a cross-host redirect forwards the X-Bz-Server-Side-Encryption-Customer-* headers - and therefore the customer key - to an unrelated host. Only deployments using the non-default custom download host are reachable, and the redirect behaviour is controlled by the CDN/proxy rather than the attacker; the vendor fixed the issue in v1.75.2 and a proof-of-concept procedure is described in the public advisory, though it is not verified as working exploit code and no active exploitation is reported.
Rclone's `serve webdav` command from 1.64.0 through 1.75.1 grants unauthenticated namespace enumeration because both HTTP auth middlewares in `lib/http` short-circuit every OPTIONS request, not just genuine CORS preflights. A remote attacker with no credentials and no user interaction can send OPTIONS to any path and read the returned `Allow` header, whose value differs for an existing file, an existing collection and a missing path, revealing the existence and type of arbitrarily named files and directories. The exposure is metadata-only - no file contents, listings or writes are reachable - and the flaw does not affect `serve http`, `serve restic` or `rcd`; a vendor patch is available in 1.75.2 and the advisory includes public proof-of-concept reproduction steps verified by the reporter, while no confirmed active exploitation has been recorded (not in CISA KEV).
rclone's WebDAV backend (v1.56.0 through v1.75.1, fixed in v1.75.2) forwards operator-configured custom credential headers such as X-Auth-Token or X-Api-Key to a different host whenever the configured WebDAV server answers with a cross-host, non-downgrade HTTP 3xx redirect, disclosing a reusable credential to whoever controls or influences the redirect target. Only custom-named headers set via --webdav-headers are exposed, because Go's net/http strips Authorization, Www-Authenticate, Cookie and Cookie2 across registrable domains; the leak occurs in the default configuration and does not depend on the opt-in auth_redirect option. Exploitation requires an attacker-influenced redirect (open redirect, compromised or malicious endpoint, or on-path position on a cleartext or same-host hop), which is reflected in the assessed high attack complexity; a public PoC reference exists in the form of advisory reproduction steps, which were reviewed against the source trace but not verified as working exploit code, and no confirmed active exploitation was identified at time of analysis. Vendor-released patch: v1.75.2.
Unauthenticated memory exhaustion in 'rclone serve s3' (streaming multipart implementation shipped in 1.75.0 through 1.75.1) lets a network client defeat the configured multipart reorder-memory cap by holding two concurrent current-part PUT requests that each declare a 5e18-byte body, wrapping the signed int64 accounting counter negative so later out-of-order parts bypass the buffer check and are retained in RAM. Only availability is affected - the reporter demonstrated a bounded 1 MiB-limit run admitting six 8 MiB out-of-order parts and roughly 50 MiB of RSS growth, with no confidentiality or integrity impact shown. Exploitation requires the documented anonymous deployment (no --auth-key or --auth-proxy) with a reachable listener, and the attacker must actually transmit the body bytes; a public PoC reproducer accompanies the advisory, and no confirmed active exploitation (CISA KEV) or EPSS signal is present in the supplied data, so this is a genuine but bounded availability risk rather than a top-tier emergency.
Cross-tenant authorization bypass in rclone's 'serve s3 --auth-proxy' mode lets an authenticated tenant inject parts into, complete, or abort another tenant's in-flight multipart uploads, and read upload and custom object metadata belonging to that tenant. Only deployments that map multiple access keys to separate per-tenant backends through --auth-proxy are affected; tracked as affecting rclone 1.68.0 through 1.75.1, with a vendor fix in v1.75.2. The advisory includes a documented two-tenant reproduction; that PoC reference is not verified as publicly released working exploit code, and there is no confirmation of active exploitation. Impact is bounded - the destination key is fixed by the victim at initiate, no at-rest tenant content is read, and the target upload must still be in flight - so this rates as a medium-severity, this-month-priority issue rather than an emergency.
Path traversal in rclone's Docker volume plugin ('rclone serve docker', versions 1.56.0 through 1.75.0) lets an attacker who can submit a VolumeDriver.Create request to the plugin socket make the privileged rclone process create a directory and mount an attacker-specified remote filesystem at an arbitrary host path. The attacker must already be in a high-privileged, socket-scoped position (PR:H) - normally the Docker daemon itself or, in a multi-tenant orchestration environment, a workload allowed to request named volumes - and no user interaction is required. Impact is bounded to unauthorized directory creation and remote-filesystem mounting over host paths rather than arbitrary code execution, and no public exploit code or confirmed active exploitation was identified at time of analysis; a vendor patch is available in 1.75.1.
Path traversal in rclone before 1.75.1 allows object names returned in server or third-party directory-listing responses to contain forward slashes and '../' parent-directory references that are not confined to the listed directory, so a malicious or compromised source can attempt to steer writes outside the transfer destination root. Exploitation requires the victim to run rclone against an attacker-influenced remote (attacker-controlled source), user interaction to initiate the transfer, and high attack complexity; the local backend's existing downstream protections currently block actual file escape on the default local backend, keeping real-world impact limited. Rated only 2.3 (CVSS 4.0) and assessed as CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N, this is a low-priority defense-in-depth hardening issue rather than an actionable threat, and no public exploit code was identified at time of analysis (no CISA KEV listing).
Path traversal in rclone prior to 1.75.1 allows an attacker who can populate a source object store with raw `..` key segments to cause rclone to write files outside the configured destination root when a victim performs a copy or sync operation. Thirteen destination backends - including b2, swift, sftp, smb, webdav, ftp, storj, and others - are affected because they apply path.Join(root, remote) on unvalidated object keys before EncodeDot can neutralize parent-directory segments; sftp and smb destinations carry the highest impact since they can reach other filesystem paths or shares accessible under the victim's credential. No public exploit code has been identified and the issue is fixed in v1.75.1.
Denial of service in rclone prior to 1.75.1 allows unauthenticated remote attackers to crash individual HTTP or WebDAV connections by sending a Range request with an offset exceeding a symlink target's length. When `--links` or `links=true` is enabled, symlinks are exposed as `.rclonelink` pseudo-objects whose content is the target path string; the `openTranslatedLink` function sliced that string using a caller-controlled offset without bounds validation, producing a deterministic Go slice-bounds panic. Go's `net/http` recovers panics per connection rather than per process, limiting impact to request-level denial of service. No public exploit has been identified and the vendor-released fix is available in version 1.75.1.
Path traversal (Zip Slip class) in rclone's archive ZIP backend permits arbitrary file writes outside the intended destination directory when processing a malicious ZIP archive. Versions 1.72.0 through 1.75.0 are affected: the readZip function in backend/archive/zip/zip.go trusts central directory filenames from untrusted ZIP sources without confining path.Clean output to the archive namespace, allowing entries like ../../etc/cron.d/evil to propagate as Object.Remote() values and be written by fs/sync and fs/operations to attacker-chosen filesystem locations. A separate bug used strings.HasPrefix without a path separator, causing root 'foo' to incorrectly match sibling entries named 'foobar'. Vendor-released patch is available in version 1.75.1; no public exploit identified at time of analysis.
rclone's HTTP backend (versions 1.49.0-1.75.0) leaks user-configured secret headers - including Authorization, Cookie, and X-Api-Key values - to untrusted redirect destinations because the underlying Go HTTP client follows redirects without a CheckRedirect policy that strips sensitive headers at host boundaries. When a configured HTTP remote issues a cross-host redirect, net/http copies the original headers verbatim to the new destination; a same-host HTTPS-to-HTTP redirect similarly exposes those headers in cleartext. Listing, stat, download, mount, and serve operations can all trigger the leak during normal use. No public exploit has been identified at time of analysis and the issue is not listed in CISA KEV.
Privilege escalation in rclone before 1.74.4 allows an attacker who controls a source remote to plant a setuid binary on the destination filesystem when the victim uses the --metadata flag during a copy or sync operation. The local backend passes source-supplied mode, uid, and gid metadata verbatim to os.Chmod and os.Chown without masking ModeSetuid or ModeSetgid bits, enabling an attacker to store a crafted binary with mode=40000755 and uid=0 on a remote they control. If rclone runs as root - common in automated backup/restore workflows - any local user on the destination system can execute the planted binary to gain root access. A proof-of-concept is documented in the upstream advisory; no confirmed active exploitation (CISA KEV) is recorded at time of analysis.
Path traversal in rclone's serve s3 command (versions before 1.74.4) allows unauthenticated remote attackers to both read and overwrite files at the serve root directory by embedding dot-dot sequences in S3 object keys. Go's path.Join() in the S3 backend normalizes traversal sequences that the S3 protocol treats as opaque identifiers, so a request like GET /bucket/../root-secret.txt resolves outside the intended bucket scope to a root-level file. A public proof-of-concept is available; no active exploitation has been confirmed in CISA KEV, but the unauthenticated default configuration and low attack complexity make exposed instances high-priority for patching.
Credential exposure in rclone before v1.75.0 allows network-adjacent attackers to capture IBM IAM bearer tokens during same-host HTTPS-to-HTTP redirect downgrades, or SSE-C customer-provided encryption keys during cross-origin S3 redirects. The S3 redirect callback in s3.go correctly strips X-Amz-Security-Token on host changes but omits IBM IAM Authorization headers and SSE-C key headers from its denylist, exploiting a gap in Go's built-in redirect sanitization that does not treat scheme downgrades as a credential boundary. A proof-of-concept is documented in GHSA-8mxv-9xhp-86h4; no public exploit tool has been independently identified, and the vulnerability is not listed in CISA KEV at time of analysis.
Credential exposure in rclone's WebDAV backend allows an adjacent on-path attacker to capture and replay Basic authentication passwords, bearer tokens, or session cookies transmitted in cleartext after a same-host HTTPS-to-HTTP redirect. All rclone versions through v1.74.0-240 are affected when the WebDAV backend is configured with Basic credentials or cookie-based authentication. No public exploit code has been released, but a proof-of-concept was demonstrated and documented in the GHSA advisory as part of responsible disclosure.
Rclone before v1.75.0 panics in the WebDAV TUS creation handler when a transport failure returns a nil HTTP response, because `getTusLocationOrRetry` dereferences `resp.StatusCode` before checking the accompanying error - crashing the process if it runs as a long-lived VFS mount or multi-workload goroutine without a recovery boundary. An attacker who controls or compromises the configured WebDAV endpoint can trigger the crash by resetting the TCP connection before an HTTP response is returned, halting all unrelated work in the process. No public exploit code and no confirmed active exploitation have been identified at time of analysis.
Stack trace disclosure in rclone's RC API exposes internal file paths, Go module versions, goroutine states, and memory addresses to authenticated API callers who intentionally trigger panics. All rclone versions through v1.74.4 with the RC API enabled are affected; the vulnerability is rooted in the panic recovery handler at fs/rc/jobs/job.go including raw debug.Stack() output directly in HTTP JSON error responses. A proof-of-concept is confirmed in the GHSA advisory; no public exploit identified at time of analysis beyond that PoC, and this vulnerability is not listed in CISA KEV.
Unauthenticated credential exposure in rclone before 1.75.0 allows remote attackers to retrieve backend storage secrets via the pprof debug endpoint, bypassing the main handler's fail-closed authentication entirely. The root cause is architectural: rclone registers Go's net/http/pprof handler on its own separate router route rather than nesting it within the authenticated main handler, so GET /debug/pprof/cmdline returns the full process argv - including cloud backend credentials - to any unauthenticated caller. No CISA KEV listing or confirmed public exploit code exists at time of analysis, but exploitation requires no authentication, no special tooling, and no user interaction, making any network-exposed RC instance immediately vulnerable to credential theft.
FTP CRLF injection in rclone before 1.75.0 allows an attacker who can place crafted filenames in a source namespace to inject arbitrary authenticated FTP commands when a victim syncs to a more-privileged FTP destination using a non-default encoding that exposes raw CR/LF. The dependency `github.com/jlaffaye/ftp` passes command arguments directly onto the line-oriented FTP control channel via `textproto.Conn.Cmd` without stripping newlines, and the GHSA advisory confirms a real FTP server executed the injected `DELE` command during researcher testing. No public exploit code and no CISA KEV listing are identified at time of analysis; the vendor-released fix is v1.75.0.
Path traversal (Zip Slip) in Rclone's archive extract command allows crafted archives containing `../` or `..\ ` path components in entry names to write extracted files outside the user-selected destination prefix. All Rclone versions prior to 1.74.4 are affected; an attacker who can induce a user to run `rclone archive extract` against a malicious archive can create or overwrite sibling objects in the same bucket or parent path scope. No public exploit code has been identified and the vulnerability is not in CISA KEV; EPSS at 0.14% (4th percentile) reflects low real-world exploitation probability.
An issue was discovered in Rclone before 1.53.3. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
In Rclone 1.42, use of "rclone sync" to migrate data between two Google Cloud Storage buckets might allow attackers to trigger the transmission of any URL's content to Google, because there is no. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Path traversal in rclone's local backend (versions through 1.75.1) allows an attacker who can plant a directory named '...rclonelink' inside a source tree to redirect directory metadata operations one level above the destination the operator selected. The flaw only triggers when a sync targets a local destination with both --links/-l and --metadata enabled, and it is metadata-only: content writes remain blocked by the earlier os.Root hardening, and ownership changes require rclone to run as root, while non-root runs are limited to rewriting timestamps and extended attributes of the destination's parent directory. Exploitation status at time of analysis: no public exploit code confirmed by intelligence sources, although the upstream advisory documents a working reproduction; the vendor has released rclone 1.75.2 as the fix, and priority is routine (patch within the current cycle).
Cross-site request forgery in the pCloud backend of Rclone 1.52.0 through 1.75.1 lets a malicious web page silently rebind a victim's pCloud remote to an attacker-controlled OAuth token and API host, so subsequent `rclone sync` transfers upload files to the attacker and return attacker-chosen content. The flaw is reachable only while the victim is actively running the interactive authorization flow (`rclone config` or `rclone authorize pcloud`), which leaves the localhost callback listener on the fixed port 127.0.0.1:53682 open; a single stateless cross-site GET to that port during the window is accepted because the pCloud backend is the only one in the tree that sets `StateBlankOK: true`, disabling the OAuth `state` check. No KEV entry and no confirmed active exploitation were reported, but a full local proof-of-concept reproduction is published in the upstream advisory, and Rclone 1.75.2 is the fixed release.
Server-side request forgery in rclone's read-only RC file server (--rc-serve) lets unauthenticated users who can reach an exposed RC listener redirect http and netstorage backend requests to attacker-chosen hosts by supplying a root that begins with a double slash on an existing named remote. Successful requests return the target's response body to the requester, leak the named HTTP remote's configured custom headers to the selected host, and - for netstorage remotes - yield valid, time-bound request signatures for attacker-chosen stat and download paths. Exploitation requires a non-default deployment (--rc-serve enabled, listener reachable, no RC HTTP authentication, a known http or netstorage remote name), which is why the supplied assessment scores it CVSS:3.1 5.9 with AC:H despite the 8.2 CVSS 4.0 vector; there is no CISA KEV entry, and the advisory publishes loopback mock reproduction scripts that demonstrate synthetic-credential impact only, so no confirmed exploitation in the wild is indicated.
Path traversal in rclone's `serve webdav` front-end, in every build up to and including 1.75.1, lets remote unauthenticated attackers write outside the directory rclone was told to serve: a single `MKCOL /..` request plants a VFS node whose backend path is literally `..`, after which PUT, MOVE, COPY, MKCOL and DELETE all resolve above the served root - creating, overwriting, moving out and (by known name, after a client PUT) deleting other tenants' files. Impact is integrity-only: reads and enumeration above the root still fail with 404 because the read path filters entries through the existing `RemoteEscapesRoot`/`RemoveEscaping` predicate while the write path never asks it. Vendor-released patch: 1.75.2; the GitHub advisory carries detailed public reproduction steps (a public PoC reference exists, not verified as working exploit code), there is no CISA KEV confirmation of active exploitation in the supplied data, and the vuln.today priority label is `this_week`.
Signature verification bypass in rclone stable selfupdate (versions 1.55.0 through 1.75.1) lets an attacker who controls the authenticated release-distribution responses prepend an unsigned SHA-256 checksum for a malicious archive ahead of the genuine PGP-clearsigned SHA256SUMS block, causing selfupdate to accept and extract an attacker-controlled rclone executable. Exploitation requires origin, CDN, or TLS-termination compromise or trusted-certificate interception plus a user running stable `rclone selfupdate` without `--check`; the beta channel is unaffected and ordinary unauthenticated interception is insufficient. The issue is rated High (CVSS 4.0 7.7; independent CVSS 3.1 7.5), fixed in 1.75.2, is not listed in CISA KEV in the supplied data, and has a public PoC reference that demonstrates the bypass and archive extraction but does not complete installation.
Memory exhaustion in rclone 1.75.0's serve S3 multipart upload handler allows remote attackers to exhaust process or host memory and permanently block request handlers by sending UploadPart requests that declare a large Content-Length but deliver no body bytes. The handler in cmd/serve/s3/multipart.go pre-allocates lib/pool pages sized to the attacker-controlled Content-Length header before any body bytes arrive, and the waitForTurn scheduling mechanism admits one additional oversized part even when --multipart-streaming-buffer-limit is active, partially bypassing the intended cap. The issue is fixed in rclone v1.75.1; no public exploit or CISA KEV listing has been identified.
Authentication/authorization bypass in rclone's dynamic serve interface (versions 1.70.0 through 1.75.0) lets remote attackers reach a fixed filesystem instead of the per-request backend the operator intended. When an FTP or S3 server is spun up via the serve/start RC (remote control) API with a per-server proxyOpt.AuthProxy, the FTP and S3 constructors mistakenly consult the empty process-global proxy.Opt.AuthProxy, so the request-local auth proxy is silently ignored: FTP accepts anonymous logins with any password against the fixed VFS, and S3 with AuthKey serves the fixed RC fs rather than the proxy-selected backend. There is no public exploit identified at time of analysis, and this is not in CISA KEV. Fixed in 1.75.1.
Authentication bypass in rclone's S3 server mode (rclone serve s3) allows any unauthenticated network attacker to impersonate arbitrary S3 access keys. When rclone serve s3 is started with --auth-proxy but without --auth-key, authPairMiddleware registers whatever accessKeyID the client chooses against an empty s3Secret, and gofakes3 then validates the request's SigV4 signature against that same empty secret - so an attacker can pick any access key, sign with an empty secret, and reach whatever backend the auth-proxy script resolves for that identity. Fixed in rclone 1.75.1; no public exploit identified at time of analysis, though the vendor security advisory (GHSA-xwwr-4h3p-r22c) and fix commit are public.
Cross-session credential isolation failure in rclone's FTP auth-proxy driver (versions 1.64.0-1.75.0) allows an authenticated network attacker to hijack a victim user's cloud storage backend by exploiting a server-wide, username-keyed credential map. When an attacker holds an open FTP session using a shared username and a victim subsequently authenticates with the same username, the victim's credential silently overwrites the server-wide map entry - causing the attacker's subsequent VFS operations to execute against the victim's backend, enabling reads, writes, renames, and deletions of the victim's cloud objects. No public exploit identified at time of analysis; vendor-released patch v1.75.1 resolves the issue.
Symlink escape in rclone's local backend (prior to v1.75.1) allows an attacker who controls sync source contents to apply metadata - ownership, permissions, or timestamps - to files and directories outside the intended destination root. When `--links` is enabled, a crafted `.rclonelink` entry plants a symlink in the destination; subsequent metadata routines (`MkdirMetadata`, `writeMetadataToFile`, `setTimes`) incorrectly skip the symlink guard and call `os.Chown`, `os.Chmod`, `os.Chtimes`, and birth-time syscalls through the planted link, bypassing `os.Root` confinement. Vendor-released patch is confirmed in v1.75.1; no active exploitation has been identified at time of analysis.
Cleartext disclosure of AWS STS session tokens affects rclone before 1.74.4 when its S3 backend follows a redirect that keeps the same host:port but downgrades the scheme from HTTPS to HTTP. The redirect-safety logic added in v1.74.3 (commit e7b1eb774) compares only URL.Host and ignores URL.Scheme, so the X-Amz-Security-Token header is re-sent over the now-plaintext connection, letting any passive observer on the path harvest the temporary credential. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Denial-of-service vulnerabilities in rclone's archive backend SquashFS parser allow an attacker with write access to rclone-exposed storage to crash the rclone process or exhaust CPU. Affected versions v1.72.0 through v1.74.4 fail to validate attacker-controlled superblock and inode metadata values sourced from the go-diskfs dependency before use, enabling three distinct panic/loop conditions. When the :archive: remote is exposed via 'rclone serve sftp', exploitation crashes the entire SFTP server. No public exploit has been identified at time of analysis, but the attack surface is concrete and parser triggering is straightforward once a malicious image is placed.
PowerShell smart-quote filename injection in rclone's SFTP backend allows an attacker who controls remote filenames to execute arbitrary PowerShell commands as the victim's SSH account on the server. All rclone versions prior to v1.75.0 are affected when the SFTP remote uses PowerShell as the SSH command shell and server-side hashing is invoked. A proof-of-concept was confirmed by the GHSA advisory author; no CISA KEV listing was present at time of analysis, but the specific attack conditions meaningfully constrain real-world exposure to Windows-hosted or PowerShell-shelled SFTP deployments.
Path traversal in the `rclone serve restic --private-repos` REST server (versions prior to 1.74.4) allows an authenticated low-privileged user to read, overwrite, or delete another tenant's private restic repository. Authorization is enforced against the routed user path segment, but the backend object key is built from the raw, uncleaned URL path, so a request such as `//..//config` passes the per-user check while resolving to a different user's data on storage backends that clean path components. No public exploit has been identified at time of analysis, but the fix and a regression test are public in the vendor commits, and EPSS risk is modest (0.52%).
Arbitrary file write via symlink traversal in Rclone prior to 1.74.4 lets an attacker-controlled remote escape the local sync destination when a victim runs a copy/sync with the -l/--links flag. Rclone stores symlinks as .rclonelink text objects and recreates them on the local target without validating the link target, so a malicious remote can plant an escaping symlink and have a subsequent object write land outside the chosen destination with attacker-chosen contents. Publicly available exploit code exists (GHSA PoC), but there is no evidence of active exploitation and EPSS is low (0.34%).
Rclone's Backblaze B2 backend sends the live account Authorization token and any configured SSE-C encryption key headers to a custom download host when --b2-download-url is set, and it follows redirects with Go's default policy that inspects host but not scheme. A same-host HTTPS-to-HTTP downgrade from that download host replays the full-capability B2 bearer token in cleartext to an on-path observer, while a cross-host redirect forwards the X-Bz-Server-Side-Encryption-Customer-* headers - and therefore the customer key - to an unrelated host. Only deployments using the non-default custom download host are reachable, and the redirect behaviour is controlled by the CDN/proxy rather than the attacker; the vendor fixed the issue in v1.75.2 and a proof-of-concept procedure is described in the public advisory, though it is not verified as working exploit code and no active exploitation is reported.
Rclone's `serve webdav` command from 1.64.0 through 1.75.1 grants unauthenticated namespace enumeration because both HTTP auth middlewares in `lib/http` short-circuit every OPTIONS request, not just genuine CORS preflights. A remote attacker with no credentials and no user interaction can send OPTIONS to any path and read the returned `Allow` header, whose value differs for an existing file, an existing collection and a missing path, revealing the existence and type of arbitrarily named files and directories. The exposure is metadata-only - no file contents, listings or writes are reachable - and the flaw does not affect `serve http`, `serve restic` or `rcd`; a vendor patch is available in 1.75.2 and the advisory includes public proof-of-concept reproduction steps verified by the reporter, while no confirmed active exploitation has been recorded (not in CISA KEV).
rclone's WebDAV backend (v1.56.0 through v1.75.1, fixed in v1.75.2) forwards operator-configured custom credential headers such as X-Auth-Token or X-Api-Key to a different host whenever the configured WebDAV server answers with a cross-host, non-downgrade HTTP 3xx redirect, disclosing a reusable credential to whoever controls or influences the redirect target. Only custom-named headers set via --webdav-headers are exposed, because Go's net/http strips Authorization, Www-Authenticate, Cookie and Cookie2 across registrable domains; the leak occurs in the default configuration and does not depend on the opt-in auth_redirect option. Exploitation requires an attacker-influenced redirect (open redirect, compromised or malicious endpoint, or on-path position on a cleartext or same-host hop), which is reflected in the assessed high attack complexity; a public PoC reference exists in the form of advisory reproduction steps, which were reviewed against the source trace but not verified as working exploit code, and no confirmed active exploitation was identified at time of analysis. Vendor-released patch: v1.75.2.
Unauthenticated memory exhaustion in 'rclone serve s3' (streaming multipart implementation shipped in 1.75.0 through 1.75.1) lets a network client defeat the configured multipart reorder-memory cap by holding two concurrent current-part PUT requests that each declare a 5e18-byte body, wrapping the signed int64 accounting counter negative so later out-of-order parts bypass the buffer check and are retained in RAM. Only availability is affected - the reporter demonstrated a bounded 1 MiB-limit run admitting six 8 MiB out-of-order parts and roughly 50 MiB of RSS growth, with no confidentiality or integrity impact shown. Exploitation requires the documented anonymous deployment (no --auth-key or --auth-proxy) with a reachable listener, and the attacker must actually transmit the body bytes; a public PoC reproducer accompanies the advisory, and no confirmed active exploitation (CISA KEV) or EPSS signal is present in the supplied data, so this is a genuine but bounded availability risk rather than a top-tier emergency.
Cross-tenant authorization bypass in rclone's 'serve s3 --auth-proxy' mode lets an authenticated tenant inject parts into, complete, or abort another tenant's in-flight multipart uploads, and read upload and custom object metadata belonging to that tenant. Only deployments that map multiple access keys to separate per-tenant backends through --auth-proxy are affected; tracked as affecting rclone 1.68.0 through 1.75.1, with a vendor fix in v1.75.2. The advisory includes a documented two-tenant reproduction; that PoC reference is not verified as publicly released working exploit code, and there is no confirmation of active exploitation. Impact is bounded - the destination key is fixed by the victim at initiate, no at-rest tenant content is read, and the target upload must still be in flight - so this rates as a medium-severity, this-month-priority issue rather than an emergency.
Path traversal in rclone's Docker volume plugin ('rclone serve docker', versions 1.56.0 through 1.75.0) lets an attacker who can submit a VolumeDriver.Create request to the plugin socket make the privileged rclone process create a directory and mount an attacker-specified remote filesystem at an arbitrary host path. The attacker must already be in a high-privileged, socket-scoped position (PR:H) - normally the Docker daemon itself or, in a multi-tenant orchestration environment, a workload allowed to request named volumes - and no user interaction is required. Impact is bounded to unauthorized directory creation and remote-filesystem mounting over host paths rather than arbitrary code execution, and no public exploit code or confirmed active exploitation was identified at time of analysis; a vendor patch is available in 1.75.1.
Path traversal in rclone before 1.75.1 allows object names returned in server or third-party directory-listing responses to contain forward slashes and '../' parent-directory references that are not confined to the listed directory, so a malicious or compromised source can attempt to steer writes outside the transfer destination root. Exploitation requires the victim to run rclone against an attacker-influenced remote (attacker-controlled source), user interaction to initiate the transfer, and high attack complexity; the local backend's existing downstream protections currently block actual file escape on the default local backend, keeping real-world impact limited. Rated only 2.3 (CVSS 4.0) and assessed as CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N, this is a low-priority defense-in-depth hardening issue rather than an actionable threat, and no public exploit code was identified at time of analysis (no CISA KEV listing).
Path traversal in rclone prior to 1.75.1 allows an attacker who can populate a source object store with raw `..` key segments to cause rclone to write files outside the configured destination root when a victim performs a copy or sync operation. Thirteen destination backends - including b2, swift, sftp, smb, webdav, ftp, storj, and others - are affected because they apply path.Join(root, remote) on unvalidated object keys before EncodeDot can neutralize parent-directory segments; sftp and smb destinations carry the highest impact since they can reach other filesystem paths or shares accessible under the victim's credential. No public exploit code has been identified and the issue is fixed in v1.75.1.
Denial of service in rclone prior to 1.75.1 allows unauthenticated remote attackers to crash individual HTTP or WebDAV connections by sending a Range request with an offset exceeding a symlink target's length. When `--links` or `links=true` is enabled, symlinks are exposed as `.rclonelink` pseudo-objects whose content is the target path string; the `openTranslatedLink` function sliced that string using a caller-controlled offset without bounds validation, producing a deterministic Go slice-bounds panic. Go's `net/http` recovers panics per connection rather than per process, limiting impact to request-level denial of service. No public exploit has been identified and the vendor-released fix is available in version 1.75.1.
Path traversal (Zip Slip class) in rclone's archive ZIP backend permits arbitrary file writes outside the intended destination directory when processing a malicious ZIP archive. Versions 1.72.0 through 1.75.0 are affected: the readZip function in backend/archive/zip/zip.go trusts central directory filenames from untrusted ZIP sources without confining path.Clean output to the archive namespace, allowing entries like ../../etc/cron.d/evil to propagate as Object.Remote() values and be written by fs/sync and fs/operations to attacker-chosen filesystem locations. A separate bug used strings.HasPrefix without a path separator, causing root 'foo' to incorrectly match sibling entries named 'foobar'. Vendor-released patch is available in version 1.75.1; no public exploit identified at time of analysis.
rclone's HTTP backend (versions 1.49.0-1.75.0) leaks user-configured secret headers - including Authorization, Cookie, and X-Api-Key values - to untrusted redirect destinations because the underlying Go HTTP client follows redirects without a CheckRedirect policy that strips sensitive headers at host boundaries. When a configured HTTP remote issues a cross-host redirect, net/http copies the original headers verbatim to the new destination; a same-host HTTPS-to-HTTP redirect similarly exposes those headers in cleartext. Listing, stat, download, mount, and serve operations can all trigger the leak during normal use. No public exploit has been identified at time of analysis and the issue is not listed in CISA KEV.
Privilege escalation in rclone before 1.74.4 allows an attacker who controls a source remote to plant a setuid binary on the destination filesystem when the victim uses the --metadata flag during a copy or sync operation. The local backend passes source-supplied mode, uid, and gid metadata verbatim to os.Chmod and os.Chown without masking ModeSetuid or ModeSetgid bits, enabling an attacker to store a crafted binary with mode=40000755 and uid=0 on a remote they control. If rclone runs as root - common in automated backup/restore workflows - any local user on the destination system can execute the planted binary to gain root access. A proof-of-concept is documented in the upstream advisory; no confirmed active exploitation (CISA KEV) is recorded at time of analysis.
Path traversal in rclone's serve s3 command (versions before 1.74.4) allows unauthenticated remote attackers to both read and overwrite files at the serve root directory by embedding dot-dot sequences in S3 object keys. Go's path.Join() in the S3 backend normalizes traversal sequences that the S3 protocol treats as opaque identifiers, so a request like GET /bucket/../root-secret.txt resolves outside the intended bucket scope to a root-level file. A public proof-of-concept is available; no active exploitation has been confirmed in CISA KEV, but the unauthenticated default configuration and low attack complexity make exposed instances high-priority for patching.
Credential exposure in rclone before v1.75.0 allows network-adjacent attackers to capture IBM IAM bearer tokens during same-host HTTPS-to-HTTP redirect downgrades, or SSE-C customer-provided encryption keys during cross-origin S3 redirects. The S3 redirect callback in s3.go correctly strips X-Amz-Security-Token on host changes but omits IBM IAM Authorization headers and SSE-C key headers from its denylist, exploiting a gap in Go's built-in redirect sanitization that does not treat scheme downgrades as a credential boundary. A proof-of-concept is documented in GHSA-8mxv-9xhp-86h4; no public exploit tool has been independently identified, and the vulnerability is not listed in CISA KEV at time of analysis.
Credential exposure in rclone's WebDAV backend allows an adjacent on-path attacker to capture and replay Basic authentication passwords, bearer tokens, or session cookies transmitted in cleartext after a same-host HTTPS-to-HTTP redirect. All rclone versions through v1.74.0-240 are affected when the WebDAV backend is configured with Basic credentials or cookie-based authentication. No public exploit code has been released, but a proof-of-concept was demonstrated and documented in the GHSA advisory as part of responsible disclosure.
Rclone before v1.75.0 panics in the WebDAV TUS creation handler when a transport failure returns a nil HTTP response, because `getTusLocationOrRetry` dereferences `resp.StatusCode` before checking the accompanying error - crashing the process if it runs as a long-lived VFS mount or multi-workload goroutine without a recovery boundary. An attacker who controls or compromises the configured WebDAV endpoint can trigger the crash by resetting the TCP connection before an HTTP response is returned, halting all unrelated work in the process. No public exploit code and no confirmed active exploitation have been identified at time of analysis.
Stack trace disclosure in rclone's RC API exposes internal file paths, Go module versions, goroutine states, and memory addresses to authenticated API callers who intentionally trigger panics. All rclone versions through v1.74.4 with the RC API enabled are affected; the vulnerability is rooted in the panic recovery handler at fs/rc/jobs/job.go including raw debug.Stack() output directly in HTTP JSON error responses. A proof-of-concept is confirmed in the GHSA advisory; no public exploit identified at time of analysis beyond that PoC, and this vulnerability is not listed in CISA KEV.
Unauthenticated credential exposure in rclone before 1.75.0 allows remote attackers to retrieve backend storage secrets via the pprof debug endpoint, bypassing the main handler's fail-closed authentication entirely. The root cause is architectural: rclone registers Go's net/http/pprof handler on its own separate router route rather than nesting it within the authenticated main handler, so GET /debug/pprof/cmdline returns the full process argv - including cloud backend credentials - to any unauthenticated caller. No CISA KEV listing or confirmed public exploit code exists at time of analysis, but exploitation requires no authentication, no special tooling, and no user interaction, making any network-exposed RC instance immediately vulnerable to credential theft.
FTP CRLF injection in rclone before 1.75.0 allows an attacker who can place crafted filenames in a source namespace to inject arbitrary authenticated FTP commands when a victim syncs to a more-privileged FTP destination using a non-default encoding that exposes raw CR/LF. The dependency `github.com/jlaffaye/ftp` passes command arguments directly onto the line-oriented FTP control channel via `textproto.Conn.Cmd` without stripping newlines, and the GHSA advisory confirms a real FTP server executed the injected `DELE` command during researcher testing. No public exploit code and no CISA KEV listing are identified at time of analysis; the vendor-released fix is v1.75.0.
Path traversal (Zip Slip) in Rclone's archive extract command allows crafted archives containing `../` or `..\ ` path components in entry names to write extracted files outside the user-selected destination prefix. All Rclone versions prior to 1.74.4 are affected; an attacker who can induce a user to run `rclone archive extract` against a malicious archive can create or overwrite sibling objects in the same bucket or parent path scope. No public exploit code has been identified and the vulnerability is not in CISA KEV; EPSS at 0.14% (4th percentile) reflects low real-world exploitation probability.
An issue was discovered in Rclone before 1.53.3. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
In Rclone 1.42, use of "rclone sync" to migrate data between two Google Cloud Storage buckets might allow attackers to trigger the transmission of any URL's content to Google, because there is no. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.