Vulnerabilities

rclone's `serve s3` command, when configured with an --auth-proxy but without --auth-key, registers any client-chosen access key ID with an empty secret and passes that identifier to the proxy without an independent per-identity credential. An unauthenticated network attacker can send an S3 request signed via SigV4 with an arbitrary access key ID and an empty secret; because both authPairMiddleware and gofakes3 validate against that same empty secret, the signature verifies and the request is accepted. The attacker then reaches whatever backend the auth-proxy script resolves for the chosen identity, with high impact on confidentiality, integrity and availability (CVSS 9.8). Only deployments running rclone prior to 1.75.1 with `serve s3`, --auth-proxy enabled and no --auth-key are affected; other rclone configurations are not implicated. No public proof-of-concept is known and the issue is not in the CISA KEV catalog, so no confirmed exploitation has been reported.

Do: Upgrade to rclone 1.75.1 or later. If upgrading is not immediately possible, set --auth-key on `serve s3` deployments that use --auth-proxy, or restrict network access to the S3 endpoint to trusted clients. Check serve s3 access logs for successful requests using unexpected or arbitrary access key IDs, which would indicate exploitation attempts.

Rclone is a command-line program to sync files and directories to and from different cloud storage providers. Prior to 1.74.4, rclone serve restic --private-repos enforces authorization using the routed user path segment while building the backend object key from the raw uncleaned URL path, allowing an authenticated user to include .. in a request such as //..//config and read, overwrite, or delete another user's private repository on backends that clean path components. This issue is fixed in version 1.74.4.

Rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.46.0 until 1.74.3, rclone rcd --rc-serve accepts unauthenticated GET and HEAD requests to paths of the form: /[remote:path]/object. The remote value is parsed from the URL and passed to normal backend initialization. Inline remote configuration can set backend options that execute local commands during initialization. As a result, a single unauthenticated GET or HEAD request can execute a command as the rclone process user. This vulnerability is fixed in 1.74.3.

Rclone's remote control (RC) API exposes the `options/set` endpoint without an authentication requirement, and because that endpoint can mutate global runtime configuration — including the RC option block itself — an unauthenticated attacker can enable `rc.NoAuth` and thereby disable the authorization gate on many other RC methods. The flaw affects rclone starting in version 1.45.0 and in all versions prior to 1.73.5, but only on RC servers that are reachable over the network and started without global HTTP authentication. With a single unauthenticated request an attacker gains access to sensitive administrative functionality, including configuration and operational RC methods that normally require authorization. Anyone running an affected rclone version with an RC server exposed without HTTP authentication is affected; rclone users who do not enable the RC feature are not impacted. Exploitation has not been confirmed in the wild (not in CISA KEV), but a public proof of concept exists and EPSS assigns a 32.7% probability of exploitation within 30 days (98th percentile).

Do: Upgrade to rclone 1.73.5 or later, prioritizing any RC server reachable from untrusted networks. Until patched, restrict the RC listener to localhost or trusted networks and enable global HTTP authentication on the RC server. Review RC logs for unexpected unauthenticated calls to options/set, given the elevated 32.7% EPSS likelihood of exploitation.

An issue was discovered in Rclone before 1.53.3. Due to the use of a weak random number generator, the password generator has been producing weak passwords with much less entropy than advertised. The suggested passwords depend deterministically on the time the second rclone was started. This limits the entropy of the passwords enormously. These passwords are often used in the crypt backend for encryption of data. It would be possible to make a dictionary of all possible passwords with about 38 million entries per password length. This would make decryption of secret material possible with a plausible amount of effort. NOTE: all passwords generated by affected versions should be changed.

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 validation of a URL field received from the Google Cloud Storage API server, aka a "RESTLESS" issue.