PT-2026-38636 · Julia · Rclone Jll

Published

2026-04-27

·

Updated

2026-04-27

CVSS v4.0

9.2

Critical

VectorAV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

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
    • 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:
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

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Related Identifiers

JLSEC-2026-281

Affected Products

Rclone Jll