| Summary | RClone: Unauthenticated operations/fsinfo allows attacker-controlled backend instantiation and local command execution
### 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:
1. `operations/fsinfo` is not protected with `AuthRequired: true`
2. `operations/fsinfo` calls `rc.GetFs(...)` on attacker-controlled input
3. `rc.GetFs(...)` supports inline backend creation through object-valued `fs`
4. WebDAV backend initialization executes `bearer_token_command`
Relevant code paths:
- [`fs/operations/rc.go`](https://github.com/rclone/rclone/blob/bf55d5e6d37fd86164a87782191f9e1ffcaafa82/fs/operations/rc.go)
- `operations/fsinfo` is registered without `AuthRequired: true`
- `rcFsInfo()` calls `rc.GetFs(ctx, in)`
- [`fs/rc/cache.go`](https://github.com/rclone/rclone/blob/bf55d5e6d37fd86164a87782191f9e1ffcaafa82/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`](https://github.com/rclone/rclone/blob/bf55d5e6d37fd86164a87782191f9e1ffcaafa82/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:
```bash
rclone rcd --rc-addr 127.0.0.1:5572
```
No `--rc-user`, no `--rc-pass`, no `--rc-htpasswd`.
Then send a single request:
```bash
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 |
|---|