Summary
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.
Versions from 1.55.0 onwards are vulnerable to command execution. Earlier versions (from 1.46.0) are vulnerable to the unauthenticated local file read described under "Additional impact" but not to command execution, because inline backend option overrides did not exist until 1.55.0.
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
- The
--rc-serve flag must be in use
Impact
An unauthenticated network attacker who can reach the RC HTTP listener can execute commands as the rclone process user.
Additional impact observed during testing:
GET and HEAD both trigger backend initialization.
- The same path allows unauthenticated local file read through inline
local remotes.
- Inline
global.* options can mutate process-wide rclone configuration, including global.http_proxy.
- Browser subresource requests can also trigger the issue against a localhost-only RC listener. In testing, Firefox triggered the payload from a public HTTPS page containing only an
<img> tag pointing at http://127.0.0.1:5572/.... This is an additional impact multiplier, not the primary attack precondition.
Mitigations / Workarounds
- Upgrade to rclone 1.74.3 (or 1.75.0 when released).
- Or, configure HTTP authentication on the rc with
--rc-user/--rc-pass
or --rc-htpasswd, which has always been the recommended deployment.
- Or, do not use
--rc-serve if file serving is not needed.
The Fix
The vulnerabilities in this advisory have been fixed by two commits:
- rc: fix unauthenticated command execution via
--rc-serve inline remotes
- rc: stop
global.* connection string options changing config
References
Summary
rclone rcd --rc-serveaccepts unauthenticatedGETandHEADrequests to paths of the form:The
remotevalue 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 unauthenticatedGETorHEADrequest can execute a command as the rclone process user.Versions from 1.55.0 onwards are vulnerable to command execution. Earlier versions (from 1.46.0) are vulnerable to the unauthenticated local file read described under "Additional impact" but not to command execution, because inline backend option overrides did not exist until 1.55.0.
Preconditions
Preconditions for this vulnerability are:
--rcflag or by running therclone rcdserver--rc-addrflag is in use--rc-user/--rc-pass/--rc-htpasswd/etc--rc-serveflag must be in useImpact
An unauthenticated network attacker who can reach the RC HTTP listener can execute commands as the rclone process user.
Additional impact observed during testing:
GETandHEADboth trigger backend initialization.localremotes.global.*options can mutate process-wide rclone configuration, includingglobal.http_proxy.<img>tag pointing athttp://127.0.0.1:5572/.... This is an additional impact multiplier, not the primary attack precondition.Mitigations / Workarounds
--rc-user/--rc-passor
--rc-htpasswd, which has always been the recommended deployment.--rc-serveif file serving is not needed.The Fix
The vulnerabilities in this advisory have been fixed by two commits:
--rc-serveinline remotesglobal.*connection string options changing configReferences