fix(deps): update module github.com/rclone/rclone to v1.73.5 [security] by renovate[bot] · Pull Request #655 · IBM/lunchpail

renovate · 2026-04-22T16:14:17Z

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/rclone/rclone	`v1.68.2` → `v1.73.5`

Rclone: Unauthenticated options/set allows runtime auth bypass, leading to sensitive operations and command execution

CVE-2026-41176 / GHSA-25qr-6mpr-f7qx

More information

Details

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

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

Severity

CVSS Score: 9.2 / 10 (Critical)
Vector String: 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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RClone: Unauthenticated operations/fsinfo allows attacker-controlled backend instantiation and local command execution

CVE-2026-41179 / GHSA-jfwf-28xr-xw6q

More information

Details

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.

This was alidated on:

current master as 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_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

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/fsinfo exploit worked
command execution occurred on the host
the issue was reproducible through direct host execution

Severity

CVSS Score: 9.2 / 10 (Critical)
Vector String: 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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

rclone/rclone (github.com/rclone/rclone)

Conversation

renovate Bot commented Apr 22, 2026

Rclone: Unauthenticated options/set allows runtime auth bypass, leading to sensitive operations and command execution

Details

Summary

Preconditions

Details

PoC

Minimal reproduction

Testing performed

Impact

Severity

References

RClone: Unauthenticated operations/fsinfo allows attacker-controlled backend instantiation and local command execution

Details

Summary

Preconditions

Details

PoC

Minimal single-request form PoC

Impact

Testing performed

Severity

References

Release Notes

v1.73.5: rclone v1.73.5

v1.73.4: rclone v1.73.4

v1.73.3: rclone v1.73.3

v1.73.2: rclone v1.73.2

v1.73.1: rclone v1.73.1

v1.73.0: rclone v1.73.0

v1.72.1: rclone v1.72.1

v1.72.0: rclone v1.72.0

v1.71.2: rclone v1.71.2

v1.71.1: rclone v1.71.1

v1.71.0: rclone v1.71.0

v1.70.3: rclone v1.70.3

v1.70.2: rclone v1.70.2

v1.70.1: rclone v1.70.1

v1.70.0: rclone v1.70.0

v1.69.3: rclone v1.69.3

v1.69.2: rclone v1.69.2

v1.69.1: rclone v1.69.1

v1.69.0: rclone v1.69.0

Configuration

Uh oh!

renovate Bot commented Apr 22, 2026

ℹ️ Artifact update notice

File name: go.mod

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

`v1.73.5`: rclone v1.73.5

`v1.73.4`: rclone v1.73.4

`v1.73.3`: rclone v1.73.3

`v1.73.2`: rclone v1.73.2

`v1.73.1`: rclone v1.73.1

`v1.73.0`: rclone v1.73.0

`v1.72.1`: rclone v1.72.1

`v1.72.0`: rclone v1.72.0

`v1.71.2`: rclone v1.71.2

`v1.71.1`: rclone v1.71.1

`v1.71.0`: rclone v1.71.0

`v1.70.3`: rclone v1.70.3

`v1.70.2`: rclone v1.70.2

`v1.70.1`: rclone v1.70.1

`v1.70.0`: rclone v1.70.0

`v1.69.3`: rclone v1.69.3

`v1.69.2`: rclone v1.69.2

`v1.69.1`: rclone v1.69.1

`v1.69.0`: rclone v1.69.0