Rclone: update to v1.74.4 — six more flaws after CVE-2026-49980

Top/Articles/Rclone: update to v1.74.4 — six more flaws after CVE-2026-49980

NewsPublished June 25, 2026Last updated July 29, 2026

Table of contents

Key takeaways

Rclone, a standard tool for saving and syncing files to the cloud, has a flaw abusable remotely without authentication. CVE-2026-49980, with a top-class severity of CVSS 9.8. If the remote-control daemon (rcd) is exposed to the network, a single crafted request can run arbitrary commands on the machine running Rclone. Versions 1.46.0–1.74.2 are affected; update to 1.74.3.

Update — July 29, 2026: the current release is v1.74.4; staying on 1.74.3 leaves six flaws unfixed

Rclone's current release is v1.74.4, published July 8, 2026, and it is an explicit security release. Anyone who stopped at 1.74.3, the version this article originally pointed to, still carries six vulnerabilities found afterwards (two High, two Medium, two Low; see the table below). Target 1.74.4 or later instead.

One line worth drawing clearly: CVE-2026-49980 itself, the subject of this article, has received no follow-up patch and no correction. The 1.74.3 fix holds, and no new CVE has been published that gets around it. The six flaws closed in 1.74.4 sit elsewhere — in serve restic, serve s3, and local file handling — and were found separately, later on.

No real-world exploitation has been reported as of this update, and none of these are listed in CISA's Known Exploited Vulnerabilities catalog. That said, the published advisory for CVE-2026-49980 spells out the default listening port of 5572 and records that a public page carrying nothing but an img tag fired the payload through a visitor's browser against a listener bound only to localhost. The bar for attempting this stays low.

Rclone, a standard tool for saving and syncing files to the cloud, has been found to contain a vulnerability (a software flaw) that can be abused remotely without any identity check (authentication). It is tracked as CVE-2026-49980, with a severity of 9.8 out of 10 (Critical), near the very top of the scale.

The affected versions are 1.46.0 through 1.74.2. It was reported by GitHub and disclosed on June 24, 2026. The fix for this flaw is included in 1.74.3, though six further flaws were fixed in 1.74.4, so aim for 1.74.4 or later when you update. If you expose Rclone's remote-control daemon (rcd) to the network, an attacker can send a single unauthenticated request and run arbitrary commands on the machine where Rclone runs, so an update is needed right away.

What kind of tool is Rclone?

Rclone is a command-line tool that exchanges files with more than 70 kinds of cloud storage, including Amazon S3, Google Drive, Dropbox, and OneDrive. It can back up and restore to the cloud, migrate data between services, and store data encrypted, and it is nicknamed "the Swiss army knife of cloud storage." It is widely used on Linux, Windows, and Mac, and is included in the official packages of major Linux distributions (types of OS, such as Ubuntu).

This flaw is in Rclone's "remote-control daemon (rcd)." With the rclone rcd command, Rclone can start an API (an access point) for operating Rclone over the network from other programs or a browser. It is convenient for automation and web admin panels, but the way this access point was built had a hole.

Who targets it, what they do, and what happens

At risk are servers or individuals running Rclone's remote-control feature (rcd) reachable from the network without authentication. This applies to setups that keep this access point running to automate backups or manage cloud syncing centrally. Simply placing it where other services can reach it on an internal network or in the cloud can make it a target.

What an attacker does is send a single crafted request to this access point and, without undergoing any identity check, run any command on the machine where Rclone runs. No login or passphrase is required; it works for anyone in a position to reach it with a request, which is what pushes the severity to the top class.

Execution happens with the privileges of the user running Rclone. Because Rclone holds the credentials (keys) to cloud storage, a takeover can lead to stealing or deleting backup data, tampering with stored content, and even expanding intrusion using the same machine as a foothold. A tool meant to protect backups thus becomes an entry point that puts all of that data at risk.

Vulnerabilities that begin to be used in real attacks can be added to the U.S. agency CISA's "list of vulnerabilities under active attack." We maintain a Japanese-language overview in our CISA KEV Dashboard (Japanese edition). None of the Rclone flaws covered here appear in that catalog as of this update.

What the vulnerability is

The cause is that an important access point that should have been guarded was missing its identity check.

CVE-2026-49980: arbitrary command execution in a single unauthenticated shot (CVSS 9.8)

According to the published information, Rclone's remote-control server (rcd --rc-serve) accepted unauthenticated GET and HEAD requests to specific URLs. By abusing an "inline configuration" option that writes the connection settings directly into the request, an attacker can execute arbitrary commands with the privileges of the Rclone process. All it takes is one request over the network—no login and no luring the user into any action.

In the fixed version 1.74.3, the handling of this access point was reworked so that critical functions cannot be reached without authentication. That fix still holds, and no flaw that gets around it has been reported. This also ties into managing the tools you bring in from outside, and inspecting the packages and services you use is worth revisiting alongside the ideas in our OSS supply-chain scanner overview.

The six flaws closed in 1.74.4

v1.74.4, released July 8, 2026, fixes six issues discovered separately from 49980. None is a 9.8-style single-shot takeover, but they bite in two situations: when you expose Rclone's file-serving modes, and when you pull data from a remote you do not control.

CVE / GHSA	Severity	Affected feature	What happens
CVE-2026- 59733	High	serve restic --private-repos	Per-user isolation is bypassed, letting any authenticated user read, overwrite and delete other users' repositories
CVE-2026- 54572	High	Local backend (--links)	A crafted symlink from an untrusted remote writes arbitrary files outside the destination directory
CVE-2026- 59732	Medium	archive extract	Paths inside a crafted archive escape the extraction root
GHSA-8v25- v8p6-qf7v	Medium	serve s3	Dot-dot path traversal lets clients read and overwrite files at the root level
GHSA-945v- v9p3-v5xw	Low	Local backend (--metadata)	setuid/setgid/sticky bits are restored from metadata, planting a setuid binary from an untrusted remote
GHSA-gx4c- 2hqx-cw2r	Low	S3 backend	The STS security token is not stripped on a same-host HTTPS-to-HTTP redirect, so it travels in the clear

1.74.4 also moves the Go toolchain to 1.26.5, picking up CVE-2026-39822 (os: a Root escape via a symlink plus a trailing slash) and CVE-2026-42505 (crypto/tls: an Encrypted Client Hello privacy leak). golang.org/x/image goes to v0.43.0, clearing four image-decoding issues in TIFF and WebP handling that could crash the process or exhaust memory. Depending on how you use Rclone you may never touch that code, but the fixes come along with the update.

A chain of bypassed fixes around rcd

CVE-2026-49980 did not appear out of nowhere. The GitHub advisory's own headline says it plainly — "bypassing CVE-2026-41179 fix" — and around the remote-control feature, holes that were supposedly sealed keep reopening through a different door.

The first move came in v1.73.5 on April 19, 2026, which fixed CVE-2026-41176 (options/set lacked the auth-required marking, so an attacker could rewrite the running auth configuration) and CVE-2026-41179 (operations/fsinfo could be called unauthenticated, and settings supplied in the request built a WebDAV backend whose token-fetching command was then executed). In both cases the remedy was to mark the endpoint as requiring authentication.

The real root, though, was the mechanism that assembles a backend on the spot from settings written into the request — inline configuration. Closing one endpoint left other routes to the same mechanism, and CVE-2026-49980 is one of them, reached through the URL path served by --rc-serve. The fix landed in v1.74.3 on June 5 and went further than shutting the door: it also cut off the global.* route that let connection-string options rewrite process-wide configuration.

v1.74.4 on July 8 belongs to a different line. Attention moved off the remote-control API and onto the serving side (serve restic, serve s3) and the receiving side (local storage), where the common thread is trusting a path or an attribute exactly as the other end supplied it. Assume that review is still in progress, and keep an eye on Rclone releases for a while.

A quick check of whether you are affected

CVE-2026-49980 affects 1.46.0 through 1.74.2, and it is especially dangerous if you expose the remote-control feature to the network. 1.74.3 closes 49980, but the six flaws listed above are only cleared in 1.74.4. Check your version with rclone version.

Your version	Remote feature (rcd) state	What to do
1.46.0 – 1.74.2	Exposed to the network	Top priority: update to 1.74.4 or later
1.46.0 – 1.74.2	Not used (plain commands only)	Update to 1.74.4 or later soon
1.74.3	—	49980 handled, but six flaws remain: update to 1.74.4 or later
1.74.4 and later	—	No action needed

If you do not use the remote-control feature and only run everyday commands like rclone copy, the risk is lower because requests cannot reach the access point from outside. The six flaws in 1.74.4 sit outside the remote-control feature, though, and you can hit them while extracting an archive or writing to local storage. Updating to 1.74.4 or later is recommended in any case.

What to do now

The top priority is to update Rclone to 1.74.4 or later. Get the latest version from your OS packages or the official downloads page. Distribution packages may still sit at 1.74.3, so confirm the actual number in the output of rclone version.

If you cannot update immediately, an effective mitigation is to isolate the remote-control feature (rcd) where unknown parties cannot reach it. Concretely: limit the listening range to your own machine (localhost), always require authentication with --rc-user / --rc-pass, and block external connections at the firewall. Also inspect for unfamiliar processes, traffic, or suspicious file operations. In case you have already been compromised, the safe move is to rotate the cloud credentials configured in Rclone after you update.

Two more things are worth checking for the six flaws in 1.74.4. First, whether you expose any rclone serve mode (restic, s3 and friends); if you do, review who can reach it and how it authenticates. Second, whether you sync from storage you do not control with --links or --metadata enabled. Dropping those flags until you can update keeps the exposure down on its own.

Summary

Rclone's CVE-2026-49980 is a vulnerability in which the remote-control access point was missing its identity check, allowing arbitrary commands to be run with a single unauthenticated request. Its severity is CVSS 9.8, near the very top, and it affects 1.46.0 through 1.74.2, fixed in 1.74.3. That fix still holds, and nothing has surfaced that gets around it.

Six separate flaws did surface after 1.74.3, and v1.74.4 on July 8, 2026 cleared them together. The two rated High are the broken per-user isolation in serve restic (CVE-2026-59733) and the symlink write outside the destination directory (CVE-2026-54572), followed by path traversal in archive extraction and in serve s3. Staying on 1.74.3 leaves all of them in place.

Because Rclone is a backup linchpin that holds cloud keys, a takeover causes large damage. If you expose the remote-control feature, update as a top priority; even if you do not, update to 1.74.4 or later soon. If new vulnerabilities concerning Rclone emerge, we will track them by adding to this article.