Rclone CVE-2026-59733

Requires an rclone instance running rclone serve restic with the --private-repos flag in a multi-user configuration, plus valid credentials for at least one low-privileged account (PR:L, confirmed authenticated by CVSS vector). The attacker sends a request with .. and/or extra slashes (e.g. //..//config or /test/../other_user/config) so the routed user segment still matches their own identity while the raw path resolves elsewhere. Exploitation is further limited to storage backends that clean/normalize path components - on backends that treat the raw key literally, the traversal does not cross into another repo. It does not apply to default serve restic usage without --private-repos or to single-tenant deployments, and no user interaction is required (UI:N).

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) is internally consistent with the description: network-reachable REST endpoint, low complexity, and a single low-privilege authenticated account yielding full read/write/delete over another user's repo. CISA's SSVC framing aligns partially - Technical Impact is rated 'total' (matching C:H/I:H/A:H) but Exploitation is 'none' and Automatable is 'no', indicating no observed in-the-wild activity and a target that must be enumerated per user rather than sprayed. EPSS is low (0.52%, 41st percentile) and this is not in CISA KEV, so despite the high base score this is a real but not emergency-tier issue: it matters most to multi-tenant deployments of serve restic --private-repos, and is largely irrelevant to single-user or non-private-repo setups. One caveat worth verifying: the impact is conditional on backends that clean path components, so exposure depends on the storage backend in use - CVSS does not capture that dependency.

A legitimate but low-privileged user of a shared rclone serve restic --private-repos service authenticates with their own credentials and issues a request such as GET //..//config or DELETE /test/../other_user/config. The per-user authorization check passes because the routed {userID} segment still matches the attacker, but the uncleaned URL path resolves on the backend to a different tenant's repository, letting the attacker read, corrupt, or wipe another user's backups. No public POC is identified, though the vendor's regression test demonstrates the exact malicious requests.