rclone CVE-2026-116189

Three concrete prerequisites must all hold: (1) the attacker controls the bytes returned for the stable release archive and its SHA256SUMS file - via compromise of the release origin, CDN, or TLS termination, or interception with a certificate trusted by the client (ordinary network interception without a trusted certificate is insufficient because downloads use HTTPS); (2) the victim runs the default stable rclone selfupdate WITHOUT the --check flag; and (3) the attacker supplies a syntactically valid archive (ZIP) or package (.deb/.rpm) for the victim's platform and expected filename. Limiting factors: user interaction is required (the user must invoke self-update), the beta update channel is not affected (it uses a separate path without this checksum verification), and only versions 1.55.0 through 1.75.1 are vulnerable (fixed in 1.75.2). The attack does not require the PGP private key and does not modify the genuine signed block; resulting code execution runs with the invoking user's privileges, so impact escalates only if a privileged user performs the update.

The input rates this CVSS 4.0 7.7 (High), and the metric breakdown is the key to real-world triage: AV:N but AC:H, AT:P, and UI:P. The High complexity and Present attack requirement are decisive - exploitation presupposes that the attacker already controls the authenticated release-distribution path (compromised origin, CDN, TLS termination, or interception with a client-trusted certificate), which the GHSA advisory explicitly states and stresses is NOT an ordinary on-path/HTTPS-MITM capability. PR:N is accurate (no rclone-side authentication is needed), but the precondition is heavy, so this is a high-severity flaw whose real-world exploitation is gated behind a significant prerequisite rather than a trivially internet-exploitable bug. Exploitation status: no CISA KEV listing is present in the input, so this is not confirmed actively exploited; a public PoC reference exists in the GHSA advisory (with reproduced test output), though the input does not mark it as 'Publicly available (confirmed)' standalone exploit code. No EPSS score was provided, so probabilistic exploitation likelihood cannot be weighed. The vuln.today Decision label is 'this_week' (not act_now/emergency), consistent with a serious issue warranting prompt patching rather than drop-everything urgency. One data point to reconcile: the GHSA narrative says 'No fixed release was available at the time of testing,' but the structured package data lists 'fixed in: 1.75.2' and the CVE title says 'before 1.75.2' - a fix now exists. Net: a genuine high-priority supply-chain-style integrity flaw, but the required attacker position means it is targeted, not mass-exploitable.

An attacker who already controls rclone's stable release-distribution responses (compromised origin, CDN, TLS termination, or interception via a client-trusted certificate) serves a malicious archive and prepends a single unsigned checksum line matching it ahead of the genuine PGP-clearsigned SHA256SUMS block. When a user runs stable rclone selfupdate without --check, rclone validates the signed block but resolves the archive hash from the whole buffer, so the attacker's unsigned line wins and the malicious rclone binary is installed, executing under the invoking user's privileges on next run. A reproducible PoC (run.sh plus Go tests) is included in the GHSA advisory; given AC:H and UI:P, the attack still requires both the privileged distribution-path position and the user invoking self-update.