RClone Manager CVE-2026-55183

Exploitation requires that the RClone Manager local engine (prior to 0.2.7) be actively running so the rclone rcd API is listening on 127.0.0.1:51900, started - per the description - with --rc-no-auth, --rc-allow-origin *, and --rc-serve, which is the default local-backend behavior when no username/password is configured. The concrete trigger is the victim opening a malicious or compromised web page in a browser on the same machine while the daemon runs (UI:R); the wildcard CORS header and absence of authentication let that page's cross-origin requests reach the API. Limiting factors: the daemon must be running at the time, the user must be induced to load attacker-controlled web content, and impact is bounded to data/credentials/files reachable at the user's OS privilege level - the advisory's command-execution impact is unconfirmed. Configuring an explicit username/password, or upgrading to 0.2.7 (which auto-generates transient in-memory credentials), removes the no-auth condition.

This is a genuine high-priority issue, not a CVSS-inflated one. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, 9.6) is internally consistent with the description: RClone Manager binds a local rclone rcd API on 127.0.0.1:51900 with --rc-no-auth and --rc-allow-origin * (CWE-306, Missing Authentication), so any web page the user visits while the daemon runs can issue authenticated-equivalent cross-origin requests at the user's OS privilege level. The scope change (S:C) is justified because the rclone component's compromise reaches beyond it to local files and configured remote storage. The only limiting signal is UI:R (the victim must have the daemon running and open a malicious page), which keeps this from being a pure drive-by. No EPSS score, no CISA KEV listing, and no public POC are provided in the input, so there is no public exploit identified at time of analysis - the risk is driven by the trivial exploitation primitive (a few lines of JavaScript/fetch) rather than observed exploitation. Two caveats to note explicitly: the advisory's possible command-execution impact is UNCONFIRMED (so I:H/A:H rest on credential/file disclosure and modification, not confirmed RCE), and AV:N is defensible only because the attack is delivered through a victim-visited web page against a loopback service - the service itself is not directly network-reachable.

A user runs RClone Manager (pre-0.2.7), leaving the unauthenticated rcd API listening on 127.0.0.1:51900 with a wildcard CORS policy. While the daemon is running, the user visits an attacker-controlled web page, which silently issues cross-origin fetch/XHR requests to the local API to read configured storage credentials and access, modify, or exfiltrate local and remote files at the user's privilege level. No public POC is referenced, but the exploit is trivial to write given AV:N/AC:L/PR:N and the wildcard origin policy.