CVE-2026-41179 is a critical flaw (CVSS 9.8) in rclone's remote control (RC) API. In versions 1.48.0 through 1.73.4, an unauthenticated request to one RC endpoint can trigger local command execution. The fix is rclone 1.73.5. If you cannot upgrade yet, put authentication on the RC interface.
What's affected
Per the GitHub advisory, rclone versions from 1.48.0 up to and including 1.73.4 are affected. Version 1.73.5 is the patched release.
The advisory lists three preconditions, and all three must hold:
- The RC API is enabled, either with the
--rcflag or by runningrclone rcd. - The RC API is reachable by the attacker. By default rclone serves it to localhost only, unless
--rc-addris used. - The RC was deployed without global HTTP authentication, meaning no
--rc-user,--rc-passor--rc-htpasswdstyle option.
A plain rclone sync or rclone copy run with no RC server is not exposed by this bug.
How to check if you're exposed
First find the version on every host that runs rclone:
rclone version
Then find out whether anything starts the RC server. Look at running processes, systemd units, container commands and cron jobs for the RC flags:
ps aux | grep -E 'rclone.*(--rc|rcd)'
grep -R "rclone" /etc/systemd/system 2>/dev/null | grep -E "rc"
An rclone older than 1.73.5 with RC enabled, bound to anything other than localhost and with no RC credentials, is the dangerous combination. Also check whether a reverse proxy or port mapping exposes a localhost-only listener to a wider network.
What to do now
- Upgrade rclone to 1.73.5 or later on every host and in every container image that bundles it.
- If you run the RC API, require authentication on it and keep it bound to localhost or a private interface.
- Restrict network access to the RC port with a firewall or security group.
- Review hosts that ran an exposed RC API for unexpected processes or changed files, since the bug allows command execution as the rclone user.
- Scan your repositories and images for rclone so you know where else it hides. The free dependency scan runs in your browser.
Why it matters
The record maps this to CWE-306 (missing authentication for a critical function), CWE-78 (OS command injection) and CWE-94 (code injection).
The advisory explains the chain. The operations/fsinfo endpoint was registered without AuthRequired: true, and it passes caller input to a function that can build a storage backend from an inline definition. The WebDAV backend supports a bearer_token_command option that runs a command when the backend starts. So an unauthenticated caller could cause a command to run on the host in a single request.
The lesson is broader than rclone. Any API that accepts a configuration object from a caller and turns it into a live connection deserves the same scrutiny as a code execution endpoint. The record does not flag this CVE as listed in CISA's Known Exploited Vulnerabilities catalog.
Quick check
My RC API only listens on localhost. Am I safe?
Per the advisory, localhost is the default and lowers exposure. Anything else on the same host, or any proxy that forwards to that port, can still reach it. Upgrade anyway.
Does a normal rclone sync job need this fix?
The vulnerable path is the RC endpoint. Jobs that do not start the RC server do not expose it, but upgrading is still the clean fix.
Sources
Last reviewed: 19 October 2026.
