## 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 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
## 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 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
Update github.com/rclone/rclone to 1.74.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanRclone: Unauthenticated command execution in `rclone rcd --rc-serve` via inline remote instantiation, bypassing CVE-2026-41179 fix affects github.com/rclone/rclone (go). Severity is critical. ## 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 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
AI coding agents often install or upgrade packages automatically in go. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/rclone/rclonego | >=1.46.0,<=1.74.2 | 1.74.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/rclone/rclone to 1.74.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanRclone: Unauthenticated command execution in `rclone rcd --rc-serve` via inline remote instantiation, bypassing CVE-2026-41179 fix affects github.com/rclone/rclone (go). Severity is critical. ## 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 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
AI coding agents often install or upgrade packages automatically in go. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/rclone/rclonego | >=1.46.0,<=1.74.2 | 1.74.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard