CVE-2026-88014: rclone archive/zip: Zip Slip via unsanitized zip entry names lets a malicious archive escape its own namespace
rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.72.0 until 1.75.1, the archive ZIP backend method (Fs).readZip in backend/archive/zip/zip.go accepts archive/zip.File.Name values from an untrusted central directory and exposes cleaned entry names without ensuring that they remain inside the archive namespace. Entries such as ../../etc/cron.d/evil can survive path.Clean and become Object.Remote() values that fs/sync and fs/operations use as destination-relative paths, allowing rclone copy or sync to write outside the selected destination on backends that do not independently confine the path. The non-empty root check also used strings.HasPrefix without a path boundary, so root foo could incorrectly include sibling foobar entries. This issue is fixed in version 1.75.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rclone (archive ZIP backend)to a version that resolves this vulnerability.Fixed in 1.75.1
Event History
Frequently Asked Questions
Which deployments are exposed?
rclone versions from 1.72.0 through 1.75.1 are affected when using the archive ZIP backend with ZIP archives whose entry names are attacker-controlled. Exposure depends on copying or syncing from such an archive to a destination backend that does not independently constrain destination-relative paths.
What does an attacker need to exploit this issue?
An attacker needs to supply or influence a malicious ZIP archive containing crafted central-directory entry names, such as ../../etc/cron.d/evil. A user must then perform an rclone copy or sync operation involving the archive ZIP backend.
What is the impact of exploitation?
Crafted ZIP entry names can be treated as destination-relative paths and cause writes outside the selected destination namespace. The issue can also cause a configured archive root such as foo to include entries under a sibling prefix such as foobar.
What should be done if patching cannot happen immediately?
Do not copy or sync untrusted ZIP archives through the archive ZIP backend to destinations that do not enforce path confinement. Restrict archive inputs to trusted sources until version 1.75.1 can be deployed.
How can I determine whether an archive may be malicious?
Inspect ZIP central-directory entry names for absolute or traversal-style paths, especially names containing ../ that could resolve outside the intended archive root. Also check for entries whose names begin with a configured root string but are not actually within that root, such as foobar when the intended root is foo.