GHSA-jfwf-28xr-xw6q is a critical-severity (CVSS 9.8) vulnerability in github.com/rclone/rclone. O3 Security confirms whether GHSA-jfwf-28xr-xw6q is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
RClone: Unauthenticated operations/fsinfo allows attacker-controlled backend instantiation and local command execution
Real-World Exposure
github.com/rclone/rcloneReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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
--rcflag or by running therclone rcdserver - The remote control API must be reachable by the attacker - by default rclone only serves the rc to localhost unless the
--rc-addrflag 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/fsinfois not protected withAuthRequired: trueoperations/fsinfocallsrc.GetFs(...)on attacker-controlled inputrc.GetFs(...)supports inline backend creation through object-valuedfs- WebDAV backend initialization executes
bearer_token_command
Relevant code paths:
-
operations/fsinfois registered withoutAuthRequired: truercFsInfo()callsrc.GetFs(ctx, in)
-
GetFs()/GetFsNamed()can parse an object-valuedfsgetConfigMap()converts attacker-controlled JSON into a backend config string
-
bearer_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:
- current
masteras 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_markeris 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/fsinfoexploit worked - command execution occurred on the host
- the issue was reproducible through direct host execution
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/rclone/rclone | ≥ 1.48.0&&< 1.73.5 | 1.73.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/rclone/rclone. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/rclone/rclone to 1.73.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jfwf-28xr-xw6q is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-jfwf-28xr-xw6q is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-jfwf-28xr-xw6q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-jfwf-28xr-xw6q in your dependencies?
O3 detects GHSA-jfwf-28xr-xw6q across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.