rclone remote-control, path, symlink, and metadata boundary checks¶

Source: hourly offensive-security scan, 2026-07-21 GitHub Advisory Database update. Primary entry: GHSA-qw24-gh76-8rvv / CVE-2026-49980.

This advisory is durable for operators because it exposes a reusable local-control-plane chain: an unauthenticated rclone Remote Control listener started with --rc-serve parses a remote specification from ordinary GET or HEAD paths, initializes caller-selected inline backends, and can cross into local command execution as the rclone process user. Browser subresource requests can deliver the same path to a localhost-only listener, so loopback binding alone does not remove the browser-to-local-service boundary.

What changed¶

Affected ranges and controls reported by the advisory:

• rclone 1.55.0 through 1.74.2: inline backend option overrides make command execution reachable;
• rclone 1.46.0 through 1.74.2: the same route family can expose local files through inline local remotes, although releases before 1.55.0 lack the command-execution path;
• first patched release: rclone 1.74.3;
• required conditions: RC enabled, listener reachable, no global RC HTTP authentication, and --rc-serve enabled.

The advisory also reports that inline global.* options can mutate process-wide rclone configuration, including proxy state. Keep public validation focused on one inert marker and configuration decision evidence; do not redirect real process traffic.

Recon and preconditions¶

1. Establish the exact startup mode. Look for rclone rcd, --rc, and specifically --rc-serve in service units, containers, desktop integrations, CI jobs, or process arguments. An installed rclone binary is not sufficient.
2. Record listener topology. Capture bind address, port, TLS, reverse proxy, and whether --rc-user, --rc-pass, --rc-htpasswd, or equivalent global HTTP authentication is active.
3. Map request principals. Separate remote network callers, same-host processes, and a browser on the workstation. Loopback exposure can still matter when a public page can issue an <img>-style subresource request.
4. Confirm version-specific impact. Distinguish backend initialization, local-file selection, global-option mutation, and command execution. Do not claim command execution for versions before 1.55.0 based only on the shared route.
5. Use a throwaway process identity. The lab rclone user should have no credentials, mounted customer data, sensitive environment variables, or access outside a dedicated temporary tree.

High-value targets include backup/orchestration hosts, developer workstations, agent sandboxes, shared service containers, and CI runners where rclone runs with more authority than the HTTP caller. Report that authority as impact context; do not exercise unrelated filesystem or storage access.

Replayable validation boundaries¶

Unauthenticated path-to-backend initialization matrix¶

1. Start an affected rclone release in a disposable container or VM with:
2. an empty temporary config and home directory;
3. no cloud credentials or customer mounts;
4. RC bound only to the lab interface;
5. --rc-serve enabled; and
6. one temporary directory for canary files and command markers.
7. Send baseline GET and HEAD requests to a normal nonexistent remote path and record status, response length, and whether backend initialization occurs.
8. Repeat with an inline remote path whose only backend-initialization effect is writing a unique inert marker under the temporary lab directory. Keep the exact command-option syntax in private evidence; the public artifact needs only the redacted path shape, process trace, and marker result.
9. Positive evidence is marker creation by the rclone process after an unauthenticated GET or HEAD. Stop immediately—do not open a shell, read environment variables, make network callbacks, or modify persistent configuration.
10. Repeat with:
11. rclone 1.74.3 or newer;
12. global RC HTTP authentication enabled and no credentials supplied;
13. --rc-serve disabled; and
14. a pre-1.55.0 release if the assessment must separate local-file behavior from command execution.
15. Record the remote string as a redacted structural representation rather than publishing a copy-paste command-execution URL.

Report this as unauthenticated RC file-serving path -> inline backend initialization -> inert command marker as the rclone process user. Include rclone version, process identity, startup flags, authentication state, request method, marker path, and patched controls.

Local-file selection control¶

For versions in the broader 1.46.0 through 1.74.2 range, create one synthetic file inside the disposable lab tree and test whether an inline local remote can select it through the unauthenticated file-serving path.

• Use only the known synthetic file; never request /etc, home directories, environment files, configs, keys, logs, or customer data.
• Compare GET with HEAD and distinguish response-body disclosure from backend initialization alone.
• Repeat with authentication enabled, --rc-serve disabled, and 1.74.3+.

Report this separately as unauthenticated URL-derived inline local remote -> synthetic file read. Do not infer arbitrary command execution for old versions unless the command-capable inline option path is independently proven.

Browser-to-loopback delivery check¶

1. Use an owned public test origin and disposable browser profile on the lab workstation.
2. Embed only a harmless <img> or equivalent subresource whose URL targets the lab RC listener and the inert marker path.
3. Record whether the browser sends the request and whether rclone creates the marker. Response readability is not required for a state-changing blind request.
4. Compare Firefox and the actual browser in scope, ordinary public HTTP/HTTPS origins, RC authentication enabled/disabled, and patched rclone.
5. Distinguish request delivery from CORS-enabled response access. Do not claim browser-readable local data when the proof shows only blind request delivery and marker creation.

Report this as public browser origin -> loopback RC subresource request -> unauthenticated backend initialization. Include browser/version, page origin, request method, listener address, authentication state, and marker-only result.

Evidence and reporting¶

Capture:

• rclone version and exact RC startup flags;
• listener address, reverse-proxy topology, TLS, and global RC HTTP authentication;
• caller class: remote client, same-host process, or browser origin;
• escaped/redacted request path and method;
• backend-initialization trace and inert marker ownership;
• vulnerable-versus-fixed decision table; and
• whether the proven impact is backend initialization, synthetic local-file read, process-global option mutation, or command execution.

Lead with the exact crossed boundary: unauthenticated URL path -> inline rclone backend configuration -> process-context side effect. Do not publish weaponized URLs, real remote configurations, credentials, production filesystem paths, or command output beyond a unique inert marker.

August 5 follow-up: untrusted-remote filesystem boundaries¶

Four reviewed rclone advisories published on August 5 extend the operator model beyond Remote Control. Three yield durable validation paths; the RC stack-trace record is useful only as adjacent version and error-surface context.

Symlink-following copy matrix¶

The relevant chain is ordered: untrusted remote object -> translated local symlink -> later descendant object -> filesystem operation follows the planted link. Test the chain without allowing the final write:

1. Create a temporary destination and a sibling directory containing one unique marker filename. Neither directory should contain sensitive data.
2. Replace or interpose the local backend's symlink and file-open operations with recorders. The symlink recorder logs the requested target but creates only an inert in-root placeholder; the open recorder resolves the would-be final path and denies the syscall.
3. Seed a synthetic source listing with a translated-link object followed lexically by one descendant object. Record object order explicitly.
4. Compare relative in-root, parent-relative, and absolute symlink targets. Do not use real home or system paths.
5. Require evidence that the affected build requests an outside-destination final path and that 1.74.4+ rejects or safely handles the same fixture.

Report untrusted remote link metadata -> translated local symlink -> descendant write would escape destination. A symlink target alone is weaker than proof that a later operation follows it; preserve both recorder events.

serve restic backend-root matrix¶

The advisory identifies a backend-independent acceptance point followed by backend-specific propagation. Do not assume every backend escapes identically.

1. Start rclone serve restic in an isolated lab with authentication, one empty backend root, and no reusable credentials.
2. Instrument the middleware-to-backend path value and the backend's final object selector.
3. Seed an in-root canary and a synthetic sibling-root canary with distinct hashes.
4. Compare a normal object path, an encoded harmless separator control, and one parent-path structural test generated by the lab client.
5. Exercise HEAD or a denied read recorder first. Test write/delete dispatch only through no-op recorders; never mutate the sibling canary.
6. Repeat across the actual backend in scope and 1.75.0+.

Evidence should bind request path -> middleware context path -> backend selector -> final canonical/object key. Report each backend separately. A WebDAV result does not prove identical FTP, SFTP, cloud-object, or local behavior.

Metadata-to-privilege recorder¶

Test metadata handling without generating a privileged file:

1. Run rclone as an unprivileged user in a disposable mount or namespace.
2. Create one inert non-executable text object on the synthetic source.
3. Attach ordinary mode/ownership metadata as the baseline, then a canary value containing a special-mode bit and a numeric owner that the test user cannot assume.
4. Patch chown and chmod immediately before the operating-system call. Record the requested path, uid, gid, raw parsed mode, and masked ordinary permission bits, then return a denied result.
5. Compare copy with and without --metadata, affected <=1.74.3, and fixed 1.74.4+.

The positive is a sink record showing source-controlled ownership or special-mode bits would be applied to attacker-controlled content. Do not create an executable, invoke the copied file, run the test as root, or treat ordinary permission preservation as privilege escalation.

Follow-up evidence fields¶

rclone version and command family:
Source trust and synthetic object order:
Destination/backend root:
Raw selector and canonical final path/key:
Symlink target recorder:
File-open/write/delete recorder:
Requested uid/gid/mode recorder:
Affected-versus-fixed result:
Strongest supported claim:
Excluded write, execution, or disclosure claims:

Keep the RC error disclosure as supporting recon only. A normal API error containing a synthetic path or build detail can establish response behavior, but do not repoint configuration at host files, force panics on a shared service, or publish stack addresses.

August 5 second follow-up: encoding, archive, tenant-path, protocol, and redirect boundaries¶

Eight additional reviewed records expand the same invariant: after filename decoding, URL normalization, archive joining, or redirects, the final path, command frame, principal, and transport must retain the authority selected by the operator.

The ranges above are those recorded by the reviewed advisories. Confirm the exact backend, build, and configuration in scope. Several paths require non-default encodings, a feature flag, an unsafe redirect emitted by an otherwise legitimate endpoint, or a lower-trust source namespace.

Post-decoding and archive containment matrix¶

Build one harness that records the original object/archive name, configured encoding, decoded portable path, native path, selected destination root/prefix, and final canonical path or object key. Replace open, create, overwrite, and cloud-write operations with deny-by-default recorders.

Exercise:

• default local encoding, Slash, None, Raw, and platform-relevant masks that omit Dot or BackSlash;
• fullwidth-dot components, native separators, ordinary dotted names, and benign Unicode controls;
• archive entries that are in-prefix, contain parent components, begin with ./, or use platform separators; and
• local and object-store destinations, keeping every target inside disposable buckets or directories.

A bounded positive is untrusted standard/archive name -> conversion or join -> final selector leaves the chosen destination -> denied sink records only the synthetic sibling marker. Default encoding rejecting the fixture does not clear a deployment that explicitly uses a weaker custom encoding. Enforce containment after conversion to the platform-native path; checking only whether an encoder mask contains Dot misses separator-specific variants.

Multi-user service path normalization¶

Use two fake Basic-auth users, two empty restic prefixes, two synthetic S3 buckets, and distinct random marker object IDs. Instrument raw request target, framework-decoded route parameters, authenticated username, private-repository authorization input, backend path input, normalized final selector, and no-op read/write/delete sink.

Compare ordinary paths with literal and encoded dot-segment variants. For serve restic --private-repos, require the authenticated username and canonical repository prefix to agree after one shared normalization pipeline. For serve s3, bind bucket authorization to the final normalized object key, not the pre-join bucket segment.

The proof is user A passes the route-level check -> a different path representation selects user B's repository or a root-level synthetic object -> denied backend sink records the foreign marker ID. Do not return object content, overwrite a config, or issue a real delete. Note that the serve s3 record describes escape from a bucket directory into the configured serve root, not escape from the rclone remote itself.

String-to-protocol grammar recorders¶

For SFTP, replace process execution with an argv and PowerShell-parser recorder. Feed ordinary names, ASCII quote controls, and inert Unicode quote markers through the real filename conversion and hash-command builder. A positive requires the final PowerShell parse tree to contain syntax outside the intended single path literal. Stop before process creation and do not publish an executable payload.

For FTP, use a local fake server whose control-channel parser records command boundaries but refuses mutations. Compare default encoding with explicitly configured masks that preserve CR/LF. Feed a filename containing only an inert second-command marker and prove whether the client emits one command frame or two. Do not use DELE, upload executable content, or connect to an operational FTP service.

Keep configuration preconditions in the report. If the source actor already has equivalent rights on the SFTP/FTP destination, the parser defect may have no authority gain; establish the lower-trust source to stronger destination boundary separately.

Redirect authority and transport matrix¶

Use an owned TLS endpoint, owned plaintext listener, locally trusted test CA, and fake credentials with no external value. Patch the final sender to log only header names and hashes. Test same-host and cross-host redirects across HTTPS-to-HTTPS, HTTPS-to-HTTP, and port changes.

Record for every hop:

• original and destination scheme, hostname, and effective port;
• resolved and selected peer;
• redirect policy decision;
• presence/hash of Authorization, Cookie, X-Amz-Security-Token, IBM IAM bearer, SSE-C, and copy-source SSE-C headers; and
• whether the request would traverse plaintext.

The secure origin comparison is the tuple scheme + canonical host + effective port. Any downgrade must fail closed; sensitive credentials should not be replayed merely because URL.Host is unchanged. A bounded positive is trusted fake credential reaches the initial owned HTTPS peer -> redirect changes authority or transport strength -> patched next-hop recorder observes the credential header.

Do not frame a malicious original endpoint as the primary attacker: it already receives the credentials. Establish the credible boundary as a legitimate endpoint, gateway, accelerator, or redirect behavior followed by an adjacent/on-path observer or a foreign redirect origin.

Second-follow-up evidence fields¶

rclone version, backend, and exact feature flags:
Source actor and destination authority:
Raw object, archive, or URL representation:
Configured filename encoding:
Decoded / native / canonical path or key:
Authenticated user and authorized prefix:
Protocol parse tree or command-frame count:
Redirect hop scheme / host / effective port:
Fake credential header presence and hash:
Denied filesystem / backend / process / network sink:
Affected-versus-fixed result:
Deployment-specific preconditions:
Strongest supported claim and excluded effects:

September 16 follow-up: the --auth-proxy auth chain and RC per-server config drift (9 GHSAs)¶

A nine-advisory rclone wave published 2026-09-10 lands on the same remote-control/serve trust surface and promotes two durable operator patterns: documentation-blessed authentication configurations that authenticate nobody, and request-supplied per-server options checked against process-global state. All proofs stay in disposable rclone processes with empty temp configs and fake credentials.

First patched release for the wave: rclone 1.75.1 (per-server proxy bypass affects 1.70.0–1.75.0).

Durable heuristics:

1. Fingerprint the auth mode, not the auth intent. For any serve-with-proxy deployment (rclone, gateways, sidecars), determine the exact flag/env combination before trusting the auth story; docs-blessed "auth proxy alone" configurations can be no-auth by construction.
2. Global-vs-request config resolution audit. Any control plane that starts protocol servers from request-supplied option objects must be diffed for options that are parsed but gated on global state; the divergence is the finding.
3. Client-known HMAC keys. If the server-side HMAC key is derived from or defaulted to anything the client controls or knows (including ""), signature verification is a formality; test with a self-computed signature using a client-chosen key.