Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
CRITICAL severity

GHSA-qw24-gh76-8rvv

CRITICAL

GHSA-qw24-gh76-8rvv is a critical-severity (CVSS 9.8) vulnerability in github.com/rclone/rclone. O3 Security confirms whether GHSA-qw24-gh76-8rvv is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Rclone: Unauthenticated command execution in `rclone rcd --rc-serve` via inline remote instantiation, bypassing CVE-2026-41179 fix

Also known asBIT-rclone-2026-49980CVE-2026-49980GO-2026-5596
Published
Jun 16, 2026
Updated
Aug 11, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Aug 11, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐹github.com/rclone/rclone

Real-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

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/rclone/rclone≥ 1.46.0&&< 1.74.31.74.3

Detection & mitigation playbook

Open-source dependency

  1. Detect

    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.

  2. Fix

    Update github.com/rclone/rclone to 1.74.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qw24-gh76-8rvv is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-qw24-gh76-8rvv 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-qw24-gh76-8rvv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary `rclone rcd --rc-serve` accepts unauthenticated `GET` and `HEAD` requests to paths of the form: ```text /[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 de
O3 Security · Impact-Aware SCA

Is GHSA-qw24-gh76-8rvv in your dependencies?

O3 detects GHSA-qw24-gh76-8rvv across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works
GHSA-qw24-gh76-8rvv: rclone (Critical 9.8) | O3 Security