Rclone USN-8299-1 vulnerabilities

Support tickets and forum threads about the Rclone USN-8299-1 vulnerabilities have been climbing steadily since the advisory dropped, and the pattern is familiar: most affected users had no idea their Rclone remote control endpoint was reachable from outside localhost, let alone that an unauthenticated attacker could use it to run arbitrary commands. Two CVEs are in play here, both serious, and the fix is not complicated, but you do need to act on it properly rather than just hoping your setup is fine.

What Causes the Rclone USN-8299-1 Vulnerabilities?

There are two distinct problems bundled under this advisory, and it's worth understanding both because they have different risk profiles depending on how you use Rclone.

CVE-2026-41179 is the nastier one. It lives in Rclone's remote control (RC) API, which is the HTTP interface you get when you start Rclone with --rc, --rc-serve, or the web UI. The authorisation logic in versions 1.48.x through 1.73.4 has a flaw that lets unauthenticated requests reach sensitive endpoints. Specifically, operations/fsinfo and options/set can be called without valid credentials. That's bad on its own, but the real damage comes from unsafe backend instantiation: an attacker can pass a crafted request that causes Rclone to spin up an attacker-controlled backend, and during WebDAV initialisation the bearer_token_command parameter gets executed as a shell command. Arbitrary remote code execution, no credentials required, as long as the RC port is reachable. See the full Ubuntu security notice for the official version breakdown.

CVE-2024-52522 is a local privilege escalation bug affecting versions before 1.68.2. It involves how Rclone handles symlinks when you run a copy operation with both --links and --metadata flags under a privileged account. A local attacker (or a process running as a lower-privileged user on the same machine) can craft a symlink that a privileged Rclone process then follows, writing files to locations it shouldn't be able to reach. The NVD entry for CVE-2024-52522 has the technical detail if you want it.

Underneath both bugs is a broader pattern: Rclone's RC interface was designed for convenience and local automation, not for exposure to untrusted networks. When people deploy it with default settings or bind it to 0.0.0.0 because it was easier, the attack surface opens up fast. The rclone.conf file compounds this because it stores OAuth tokens and effective passwords in plaintext, so if an attacker can read it (or exfiltrate it via the RC API), they get full access to every configured remote.

And yes, ransomware groups know this. Rclone is a well-documented exfiltration tool in ransomware playbooks precisely because it handles dozens of cloud storage providers cleanly. If your RC endpoint is exposed and unpatched, you're not just at risk of a one-off compromise. You're potentially handing over a ready-made data exfiltration pipeline. Worth taking seriously.

Rclone USN-8299-1 Vulnerabilities: Quick Fix

This first step is about reducing your exposure right now, before you do anything else. It takes five minutes.

More Rclone USN-8299-1 Vulnerability Solutions

Once you've stopped any exposed RC processes, the next job is upgrading to a patched version and hardening your configuration. This is where most people will be fully sorted.

One thing worth flagging here: if you're running Rclone as part of an automated backup pipeline, check whether your scripts pass credentials as command-line arguments. Those show up in process listings. Better to use environment variables or a config file with tight permissions. This is the kind of thing that gets missed when people set up automation in a hurry and never revisit it.

For anyone who wants to understand the broader context of how authorisation failures in backup and sync tools get exploited, our guide on ransomware data exfiltration tactics covers how tools like Rclone end up in attacker toolkits and what monitoring you can put in place.

Advanced Rclone USN-8299-1 Vulnerability Fixes

If you're managing Rclone across multiple machines, running it in automation, or operating in an environment where security compliance matters, the intermediate fix isn't enough on its own. You need a proper inventory and policy layer.

One edge case that trips people up: some backup applications and NAS devices ship their own bundled copy of Rclone. QNAP, Synology, and a few others have done this. If you're running Rclone through one of those interfaces, the version the vendor ships may be older than 1.73.5 and you'll need a firmware or app update from the vendor rather than a direct binary swap. Check the vendor's security bulletins. For related config security issues on NAS devices, our NAS security hardening guide covers the common pitfalls.

Also worth mentioning: if your rclone.conf contains credentials for Microsoft 365 or Google Workspace remotes, consider enabling conditional access policies on those accounts as an additional layer. Even if an attacker gets the token, conditional access can block usage from unexpected locations or devices. That's not a fix for the Rclone USN-8299-1 vulnerabilities themselves, but it limits the blast radius if a token does get stolen.

Preventing Rclone USN-8299-1 Vulnerabilities in Future

Prevention here comes down to three things: staying current, minimising exposure, and protecting credentials. In that order of importance.

Staying current means subscribing to Rclone's GitHub security advisories. Go to the Rclone repository, click Watch, then Custom, and tick Security alerts. You'll get an email when a new advisory drops. That's five seconds of setup that means you won't be reading about a CVE on Reddit three weeks after it was published.

Minimising exposure means treating the RC API like a network service that's off by default. Only enable it when you actively need it. When you do enable it, bind it to localhost. If you need it accessible over a network, use a VPN or SSH tunnel rather than exposing the port directly. The Rclone USN-8299-1 vulnerabilities are a good reminder that RC was designed for local automation convenience, not network exposure.

Protecting credentials is the bit most people skip. rclone.conf stores OAuth tokens and passwords in plaintext. Treat it like a password manager database: tight file permissions, not synced to cloud storage in a readable form, and credentials rotated on a reasonable schedule. For cloud remotes that support short-lived tokens (most OAuth2-based ones do), prefer those over long-lived API keys. If you're in an enterprise context, look at storing secrets in a proper vault and having Rclone pull them at runtime rather than reading from a static config file.

Running Rclone under a least-privilege account for routine sync jobs is also worth doing. It doesn't fix the CVEs, but it limits what an attacker can do if they do get code execution through the RC API. And it directly mitigates the symlink privilege escalation bug in CVE-2024-52522 for anything below 1.68.2. For more on least-privilege principles in practice, our guide on setting up least-privilege accounts on Windows walks through the specifics.

Rclone USN-8299-1 Vulnerabilities: Summary

The Rclone USN-8299-1 vulnerabilities are a genuine risk if you're running an older version with RC enabled, but they're also very fixable. Stop any exposed RC processes now, upgrade to 1.73.5 or later, bind RC to localhost with proper authentication, and lock down rclone.conf permissions. That covers both CVEs. If you're managing Rclone across multiple systems, add it to your vulnerability scanning and set up monitoring for unusual process behaviour. The Rclone USN-8299-1 vulnerabilities are a reminder that convenience features like RC need the same security treatment as any other network service, and that tools with broad cloud storage access deserve proper credential hygiene. Sorted properly, this is a 30-minute job. Ignored, it's a potential data exfiltration incident waiting to happen.