CVE-2026-59733: Path Traversal and Authorization Bypass in Rclone serve restic

Rclone features an integrated REST server subcommand, serve restic, which enables the hosting of multiple private restic backup repositories. This functionality leverages the --private-repos flag to enforce isolation among distinct clients. Under this security model, each authenticated user is restricted to their own designated repository folder.

The isolation is implemented via HTTP Basic authentication, where the backend sub-directory is determined by the authenticated username. However, a logical flaw exists in the directory confinement checks prior to version 1.74.4. This allows authenticated clients to escape their restricted path boundaries.

The flaw represents a path traversal and authorization bypass vulnerability classified under CWE-22 and CWE-639. An authenticated attacker can read, modify, or delete backup data belonging to other users on the same server.

The root cause of CVE-2026-59733 lies in a logical path-desynchronization defect between two distinct HTTP middleware components in the cmd/serve/restic package. These components are checkPrivate (the authorization handler) and WithRemote (the object-key retrieval handler).

When a client submits an HTTP request, the checkPrivate middleware validates access based on a path parameter parsed by the go-chi router. Specifically, it retrieves the {userID} wildcard parameter. If an attacker submits a path such as /attacker/../victim/config, the router identifies attacker as the {userID} parameter. Because the attacker is authenticated as attacker, the access check is authorized successfully.

Following authorization, the WithRemote middleware processes the request to determine the target storage path. Rather than utilizing the verified {userID} parameter, it extracts the raw, uncanonicalized path directly from the URL. The storage backend subsequently cleans the relative dot-dot segments, which resolves /attacker/../victim/config directly to /victim/config.

This desynchronization permits authorized access under the identity of one user, while the physical read, write, or delete operation is executed against the directory of a different user.

The vulnerable version of the path extraction logic does not perform validation on the directory components of the raw URL path. This allows traversal sequences to pass directly into the storage backend.

// Vulnerable logic in cmd/serve/restic/restic.go
func WithRemote(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		urlpath := r.URL.Path
		urlpath = strings.Trim(urlpath, "/")
		// Raw path containing ".." is parsed directly without canonical verification
		parts := matchData.FindStringSubmatch(urlpath)
		// ...
	})
}

The official patch addresses this gap by validating that the requested path is already in canonical form before any parsing occurs. It utilizes path.Clean to check for anomalies.

// Patched logic in cmd/serve/restic/restic.go
func WithRemote(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		urlpath := r.URL.Path
		urlpath = strings.Trim(urlpath, "/")
		// Reject any non-canonical path, in particular one containing ".." traversal elements.
		if urlpath != "" && path.Clean(urlpath) != urlpath {
			http.Error(w, http.StatusText(http.StatusBadRequest), http.StatusBadRequest)
			return
		}
		parts := matchData.FindStringSubmatch(urlpath)
		// ...
	})
}

An attacker requires a valid set of credentials for their own private repository namespace. The attack vector is executed over HTTP, making it fully remote and independent of local host privileges.

The attack is executed by constructing custom HTTP requests that embed relative directory traversal segments directly into the URL path. By inserting the authorized username, followed by traversal operators and the target user's namespace, the request escapes the tenant sandbox.

For example, to retrieve the configuration of a victim repository, the attacker issues a GET request to /attacker/../victim/config with their own Basic Authentication credentials. The server responds with the contents of the target repository's configuration. Overwriting or deleting the configuration can similarly be executed using POST or DELETE requests.

The impact of CVE-2026-59733 is a full compromise of data confidentiality, integrity, and availability within multi-user rclone restic environments. A compromised tenant can access, manipulate, or delete all stored backups across every other tenant on the system.

The National Vulnerability Database has assigned a CVSS v3.1 score of 8.8 (High), with a vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. This reflects the low complexity of the attack and the lack of required interaction, combined with high impact metrics.

Because backup systems often contain highly sensitive data, including system configurations, intellectual property, and credentials, the exposure of these files constitutes a critical vector for data exfiltration and subsequent lateral movement.

The primary remediation for this vulnerability is upgrading the rclone installation to version 1.74.4 or later. This version contains the path canonicalization check which successfully blocks non-canonical requests.

If immediate upgrading is not viable, administrators must implement alternative isolation strategies. Disabling the --private-repos flag and running separate rclone daemon processes for each tenant on distinct ports is the recommended workaround.

Additionally, upstream reverse proxies such as Nginx or HAProxy can be configured to inspect and block any request paths that contain directory traversal tokens such as .. or double slashes before they reach the rclone backend.