<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Rclone (1.74.3) - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/rclone-1.74.3/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 05 Aug 2026 21:25:39 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/rclone-1.74.3/feed.xml" rel="self" type="application/rss+xml"/><item><title>Authorization Bypass in rclone serve restic --private-repos</title><link>https://feed.craftedsignal.io/briefs/2026-08-rclone-auth-bypass/</link><pubDate>Wed, 05 Aug 2026 21:25:39 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-08-rclone-auth-bypass/</guid><description>An authorization bypass vulnerability in rclone's restic server allows authenticated users to access and manipulate repositories of other users via path traversal, impacting multi-tenant environments using backend storage that canonicalizes path segments.</description><content:encoded><![CDATA[<p>The rclone <code>serve restic</code> command includes a <code>--private-repos</code> feature intended to provide multi-tenant isolation by restricting users to their own path prefix (e.g., <code>/&lt;username&gt;/</code>). This security boundary is enforced by two separate chi middlewares that handle request authorization and object path resolution differently. The <code>checkPrivate</code> middleware validates that the authenticated user matches the initial path segment. However, the <code>WithRemote</code> middleware constructs the backend object key using the raw, un-cleaned URL path.</p>
<p>An authenticated user can bypass this confinement by sending a request with a traversal sequence, such as <code>GET /&lt;attacker&gt;/../&lt;victim&gt;/config</code>. Because the path starts with the attacker's username, the authorization middleware permits the request. However, backends that use POSIX <code>path.Clean</code> semantics (including the common <code>sftp</code>, <code>ftp</code>, and <code>memory</code> backends) resolve the <code>..</code> segment, directing the operation to the victim's repository. This vulnerability enables unauthorized reading, overwriting, or deletion of another tenant's backup metadata and blobs. The vulnerability affects rclone version 1.74.3.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker establishes a valid, low-privileged authenticated session on the target rclone instance configured with <code>--private-repos</code>.</li>
<li>Attacker crafts a malicious HTTP request using path traversal sequences, targeting a victim's repository path (e.g., <code>/mallory/../alice/config</code>).</li>
<li>The <code>checkPrivate</code> middleware observes the initial path segment (<code>mallory</code>) and confirms it matches the authenticated session user, allowing the request to proceed.</li>
<li>The <code>WithRemote</code> middleware captures the un-cleaned URL path <code>mallory/../alice/config</code> and passes it as the remote key to the storage backend.</li>
<li>The storage backend (e.g., SFTP/FTP) invokes POSIX path normalization, collapsing <code>mallory/../alice/config</code> into <code>alice/config</code>.</li>
<li>The backend handler executes the requested operation (GET, POST, or DELETE) against the victim's resource.</li>
<li>Attacker successfully exfiltrates metadata/blobs, poisons the repository, or deletes the victim's backups.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation results in a total loss of confidentiality, integrity, and availability for the victim's restic repository on the affected server. Attackers can read sensitive restic <code>config</code> and <code>keys</code> metadata, poison existing backups by overwriting objects, or delete the entire repository. This vulnerability effectively nullifies the multi-tenant isolation provided by the <code>--private-repos</code> flag. The impact is critical for hosting providers or organizations sharing a single rclone restic server among multiple users.</p>
<h2 id="recommendation">Recommendation</h2>
<p>Prioritize the following actions to secure rclone instances:</p>
<ul>
<li>Upgrade rclone to the latest patched version addressing this bypass, or disable the <code>--private-repos</code> flag until an update is applied.</li>
<li>Audit existing multi-tenant rclone deployments to identify those utilizing the <code>--private-repos</code> flag with backends like SFTP or FTP.</li>
<li>Implement network-level access controls or proxy-based URL path normalization to reject requests containing <code>..</code> or <code>%2e%2e</code> sequences before they reach the rclone server.</li>
<li>Use backends that do not rely on implicit POSIX path normalization if available, or isolate multi-tenant backup repositories at the infrastructure level rather than relying on application-layer flags.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category></item></channel></rss>