GHSA-66hp-wgxq-6f5q

Dashboard / Vulnerabilities / GHSA-66hp-wgxq-6f5q

GHSA-66hp-wgxq-6f5q

Summary: rclone archive/zip: Zip Slip via unsanitized zip entry names lets a malicious archive escape its own namespace

Details: ### Summary `backend/archive` mounts a zip file as a browsable, syncable rclone `Fs` (e.g. `rclone lsf :zip:downloaded.zip` or `rclone copy :zip:downloaded.zip dest:`). Go's `archive/zip` package does not sanitize `file.Name` - it is taken verbatim from the untrusted zip's central directory. `readZip()` in `backend/archive/zip/zip.go` applies `path.Clean` to the entry name, but this alone cannot fully neutralize a name with more `..` components than real segments preceding them (e.g. `"../../etc/cron.d/evil"` stays exactly as-is after cleaning). When the archive is mounted with an empty root (the common case), there was no check at all that the resulting name stayed inside the archive's own namespace, so it was stored verbatim and returned unchanged by `Object.Remote()`. `fs/sync`/`fs/operations` use `srcObj.Remote()` directly as the destination-relative path when copying between filesystems, so a maliciously crafted zip file can cause `rclone copy`/`sync` to attempt writes outside the intended destination directory on whatever backend it targets - this is the well-known "Zip Slip" vulnerability class (https://security.snyk.io/research/zip-slip-vulnerability) applied to rclone's own zip-mounting backend. It is distinct from `cmd/archive/extract`, which already validates via its own `destPath()` choke point and is not affected. ### Details Vulnerable code (before fix), `backend/archive/zip/zip.go`, `(*Fs).readZip`: ```go for _, file := range zr.File { remote := strings.Trim(path.Clean(file.Name), "/") if remote == "." { remote = "" } remote = path.Join(f.prefix, remote) if f.root != "" { // Ignore all files outside the root if !strings.HasPrefix(remote, f.root) { continue } ... } ... o := &Object{f: f, remote: remote, ...} dt.Add(o) } ``` The escape check only ran when `f.root != ""`, and even then used a bare `strings.HasPrefix` with no boundary check (so `f.root="foo"` incorrectly also matched a sibling entry `"foobar"`). ### PoC Built a zip in memory with Go's real `archive/zip` writer (entry name `"../../etc/cron.d/evil"`, not sanitized by the writer either), wrote it to disk, and mounted it via the actual production constructor `zip.New(ctx, localFs, "evil.zip", "", "")`: ``` zip entry Name="../../etc/cron.d/evil" -> Object.Remote()="../../etc/cron.d/evil" ``` Fully outside the archive's own namespace - confirmed via a regression test that mounts the malicious zip through the real `local` backend and inspects the resulting Fs's internal dirtree and every Object's `Remote()`. ### Impact A user who runs `rclone copy`/`sync`/`mount` against an untrusted zip file (downloaded, e-mailed, etc.) can have files written outside the intended destination directory on the destination backend, depending on that backend's own confinement. No server compromise or custom remote configuration is required from the attacker - only a crafted zip file and a normal `rclone copy`/`sync` invocation by the victim. ### Fix Skip any zip entry whose cleaned+prefixed name still escapes the archive's own namespace, rather than exposing it. Also tightened the pre-existing root filter's weak prefix check.

References: https://github.com/rclone/rclone/security/advisories/GHSA-66hp-wgxq-6f5q, https://nvd.nist.gov/vuln/detail/CVE-2026-88014, https://github.com/rclone/rclone/commit/5dae3adbf571a6cd9ba501eb47397a7e871e1ae0, https://github.com/rclone/rclone/commit/6507e13d5a83789f500af96d7188c302c9d74d98, https://github.com/rclone/rclone, https://github.com/rclone/rclone/releases/tag/v1.75.1