Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN404 _____________________________________________________________________ DATE : 20/04/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running rclone (Go) versions prior to 1.73.5. ===================================================================== https://github.com/rclone/rclone/security/advisories/GHSA-jfwf-28xr-xw6q https://github.com/rclone/rclone/security/advisories/GHSA-25qr-6mpr-f7qx _____________________________________________________________________ Unauthenticated RC operations/fsinfo allows attacker-controlled backend instantiation and local command execution via WebDAV bearer_token_command Critical ncw published GHSA-jfwf-28xr-xw6q Apr 19, 2026 Package github.com/rclone/rclone (Go) Affected versions >= 1.48.0, <= 1.73.4 Patched versions 1.73.5 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 --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 Details The root cause consists of the following pieces: operations/fsinfo is not protected with AuthRequired: true operations/fsinfo calls rc.GetFs(...) on attacker-controlled input rc.GetFs(...) supports inline backend creation through object-valued fs WebDAV backend initialization executes bearer_token_command Relevant code paths: fs/operations/rc.go operations/fsinfo is registered without AuthRequired: true rcFsInfo() calls rc.GetFs(ctx, in) fs/rc/cache.go GetFs() / GetFsNamed() can parse an object-valued fs getConfigMap() converts attacker-controlled JSON into a backend config string backend/webdav/webdav.go bearer_token_command is a supported backend option NewFs(...) calls fetchAndSetBearerToken() when bearer_token_command is set fetchBearerToken() invokes exec.Command(...) This creates a practical single-request unauthenticated command-execution primitive on reachable RC servers without global HTTP authentication. I validated this on: current master as of 2026-04-14: bf55d5e6d37fd86164a87782191f9e1ffcaafa82 latest public release tested locally: v1.73.4 I also validated it on a public amd64 Ubuntu host that I control, 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_marker is 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 I successfully reproduced this: on my local test environment on a public amd64 Ubuntu host that I control On the public host I confirmed: the unauthenticated operations/fsinfo exploit worked command execution occurred on the host the issue was reproducible through direct host execution I believe this should be treated as a High severity issue on reachable RC deployments without global HTTP authentication. Severity Critical 9.2/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required None User interaction None Vulnerable System Impact Metrics Confidentiality High Integrity High Availability High Subsequent System Impact Metrics Confidentiality None Integrity None Availability None 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 CVE ID CVE-2026-41179 Weaknesses Weakness CWE-78 Weakness CWE-306 Credits @0wnerDied 0wnerDied Reporter @ncw ncw Remediation developer _____________________________________________________________________ Unauthenticated RC options/set allows runtime auth bypass and leads to sensitive operations and command execution Critical ncw published GHSA-25qr-6mpr-f7qx Apr 19, 2026 Package github.com/rclone/rclone (Go) Affected versions >= 1.45, <= 1.73.4 Patched versions 1.73.5 Description Summary 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 --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 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/set is exposed without AuthRequired: true the RC server enforces authorization for AuthRequired calls using the mutable runtime value s.opt.NoAuth Relevant code paths: fs/rc/config.go registers options/set without AuthRequired: true rcOptionsSet reshapes attacker-controlled input into global option blocks fs/rc/rcserver/rcserver.go request handling checks: if !s.opt.NoAuth && call.AuthRequired && !s.server.UsingAuth() once rc.NoAuth is changed to true, later AuthRequired methods 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/listremotes config/dump config/get operations/list operations/copyfile core/command Relevant code for the second-stage command execution path: fs/metadata.go metadataMapper() uses exec.Command(...) fs/operations/rc.go operations/copyfile is normally AuthRequired: true once rc.NoAuth=true, it becomes reachable without credentials I validated this on: current master as of 2026-04-14: bf55d5e6d37fd86164a87782191f9e1ffcaafa82 latest public release tested locally: v1.73.4 I also verified the issue on a public amd64 Ubuntu host that I control, 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 I successfully reproduced this: on my local test environment on a public amd64 Ubuntu host that I control On the public host I confirmed: unauthenticated options/set successfully set rc.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. I believe this should be treated as a High severity issue. Severity Critical 9.2/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required None User interaction None Vulnerable System Impact Metrics Confidentiality High Integrity High Availability High Subsequent System Impact Metrics Confidentiality None Integrity None Availability None 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 CVE ID CVE-2026-41176 Weaknesses Weakness CWE-306 Credits @0wnerDied 0wnerDied Reporter @ncw ncw Remediation developer ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================