Rclone CVE-2026-116194

Exploitation requires the victim to be actively running the interactive pCloud OAuth flow (rclone config or rclone authorize pcloud) so the localhost callback server is listening on the fixed, well-known port 127.0.0.1:53682, AND a malicious web page to be loaded in the victim's browser during that short window. Only the pcloud backend is affected - it is the sole backend that sets StateBlankOK:true, disabling the OAuth state check; sharefile uses the same host-trust pattern but keeps the state check and is not vulnerable. Limiting factors: exploitation is confined to the brief interactive authorization window, needs victim-side interaction (a loaded page), and the attacker needs no information from the victim because the port is fixed. Chrome's Private Network Access can block the request when issued as a subresource (though not as a top-level navigation); Firefox blocks neither.

The CVSS 4.0 base score of 7.6 (High) is driven by severe technical impact - VC:H/VI:H - because a successful attack binds the victim's pCloud remote to an attacker-controlled host and token, so later rclone sync operations exfiltrate files (confidentiality) and return attacker-chosen content (integrity). However, the exploitability metrics temper raw urgency: AC:H, AT:P and UI:P together encode that exploitation depends on a narrow, attacker-uncontrolled window (the victim must be mid-authorization) plus victim-side interaction (a malicious page loaded in the browser at that moment). PR:N confirms the attacking web page needs no credentials. On exploitation signals, a fully author-verified proof-of-concept is published in the GHSA advisory, which materially raises feasibility, but this CVE is NOT in CISA KEV (no confirmed active exploitation) and no EPSS score was supplied, so widespread automated exploitation cannot be asserted. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with high impact gated behind a tight timing-and-interaction precondition. Net: a genuine high-severity flaw worth remediating this week, but the practical attack surface is limited to users actively running pCloud OAuth setup, pointing to opportunistic/targeted rather than mass exploitation.

While a victim runs rclone config or rclone authorize pcloud and the localhost callback server is listening on 127.0.0.1:53682, the attacker gets a malicious web page loaded in the victim's browser. That page fires one cross-site GET to the callback with an attacker code and hostname; because the pcloud backend sets StateBlankOK, the stateless request is accepted, planting an attacker token and API host so every later transfer on that remote reaches the attacker. A fully verified, working proof-of-concept demonstrating this chain is published in the GHSA advisory.