Summary
The RC endpoint operations/fsinfo is exposed without AuthRequired: true and accepts attacker-controlled fs input. Because rc.GetFs(...) supports inline backend definitions, an unauthenticated attacker can instantiate an attacker-controlled backend on demand. For the WebDAV backend, bearer_token_command is executed during backend initialization, making single-request unauthenticated local command execution possible on reachable RC deployments without global HTTP authentication.
Preconditions
Preconditions for this vulnerability are:
- The rclone remote control API must be enabled, either by the
--rc flag or by running the rclone rcd server
- The remote control API must be reachable by the attacker - by default rclone only serves the rc to localhost unless the
--rc-addr flag is in use
- The rc must have been deployed without global RC HTTP authentication - so not using
--rc-user/--rc-pass/--rc-htpasswd/etc
Details
The root cause consists of the following pieces:
operations/fsinfo is not protected with AuthRequired: true
operations/fsinfo calls rc.GetFs(...) on attacker-controlled input
rc.GetFs(...) supports inline backend creation through object-valued fs
- WebDAV backend initialization executes
bearer_token_command
Relevant code paths:
-
fs/operations/rc.go
operations/fsinfo is registered without AuthRequired: true
rcFsInfo() calls rc.GetFs(ctx, in)
-
fs/rc/cache.go
GetFs() / GetFsNamed() can parse an object-valued fs
getConfigMap() converts attacker-controlled JSON into a backend config string
-
backend/webdav/webdav.go
bearer_token_command is a supported backend option
NewFs(...) calls fetchAndSetBearerToken() when bearer_token_command is set
fetchBearerToken() invokes exec.Command(...)
This creates a practical single-request unauthenticated command-execution primitive on reachable RC servers without global HTTP authentication.
This was alidated on:
- current
master as of 2026-04-14: bf55d5e6d37fd86164a87782191f9e1ffcaafa82
- latest public release tested locally:
v1.73.4
This was also validated on a public amd64 Ubuntu host controlled by the tester, using direct host execution (not containerized PoC execution).
PoC
Minimal single-request form PoC
Start a vulnerable RC server:
rclone rcd --rc-addr 127.0.0.1:5572
No --rc-user, no --rc-pass, no --rc-htpasswd.
Then send a single request:
curl -sS -X POST http://127.0.0.1:5572/operations/fsinfo \
--data-urlencode "fs=:webdav,url='http://127.0.0.1/',vendor=other,bearer_token_command='/usr/bin/touch /tmp/rclone_fsinfo_rce_poc_marker':"
Expected result:
- HTTP 200 JSON response from
operations/fsinfo
/tmp/rclone_fsinfo_rce_poc_marker is created on the host
Impact
This is effectively a single-request unauthenticated command-execution vulnerability on reachable RC deployments without global HTTP authentication.
In practice, command execution in the rclone process context can lead to higher-impact outcomes such as local file read, file write, or shell access, depending on the deployed environment.
Testing performed
This was successfully reproduced:
- on a local test environment
- on a public amd64 Ubuntu host controlled by the tester
On the public host it was confirmed:
- the unauthenticated
operations/fsinfo exploit worked
- command execution occurred on the host
- the issue was reproducible through direct host execution
References
Summary
The RC endpoint
operations/fsinfois exposed withoutAuthRequired: trueand accepts attacker-controlledfsinput. Becauserc.GetFs(...)supports inline backend definitions, an unauthenticated attacker can instantiate an attacker-controlled backend on demand. For the WebDAV backend,bearer_token_commandis executed during backend initialization, making single-request unauthenticated local command execution possible on reachable RC deployments without global HTTP authentication.Preconditions
Preconditions for this vulnerability are:
--rcflag or by running therclone rcdserver--rc-addrflag is in use--rc-user/--rc-pass/--rc-htpasswd/etcDetails
The root cause consists of the following pieces:
operations/fsinfois not protected withAuthRequired: trueoperations/fsinfocallsrc.GetFs(...)on attacker-controlled inputrc.GetFs(...)supports inline backend creation through object-valuedfsbearer_token_commandRelevant code paths:
fs/operations/rc.gooperations/fsinfois registered withoutAuthRequired: truercFsInfo()callsrc.GetFs(ctx, in)fs/rc/cache.goGetFs()/GetFsNamed()can parse an object-valuedfsgetConfigMap()converts attacker-controlled JSON into a backend config stringbackend/webdav/webdav.gobearer_token_commandis a supported backend optionNewFs(...)callsfetchAndSetBearerToken()whenbearer_token_commandis setfetchBearerToken()invokesexec.Command(...)This creates a practical single-request unauthenticated command-execution primitive on reachable RC servers without global HTTP authentication.
This was alidated on:
masteras of 2026-04-14:bf55d5e6d37fd86164a87782191f9e1ffcaafa82v1.73.4This was also validated on a public amd64 Ubuntu host controlled by the tester, using direct host execution (not containerized PoC execution).
PoC
Minimal single-request form PoC
Start a vulnerable RC server:
No
--rc-user, no--rc-pass, no--rc-htpasswd.Then send a single request:
curl -sS -X POST http://127.0.0.1:5572/operations/fsinfo \ --data-urlencode "fs=:webdav,url='http://127.0.0.1/',vendor=other,bearer_token_command='/usr/bin/touch /tmp/rclone_fsinfo_rce_poc_marker':"Expected result:
operations/fsinfo/tmp/rclone_fsinfo_rce_poc_markeris created on the hostImpact
This is effectively a single-request unauthenticated command-execution vulnerability on reachable RC deployments without global HTTP authentication.
In practice, command execution in the rclone process context can lead to higher-impact outcomes such as local file read, file write, or shell access, depending on the deployed environment.
Testing performed
This was successfully reproduced:
On the public host it was confirmed:
operations/fsinfoexploit workedReferences