Zip Slip: the archive path traversal that turned one snippet into thousands of advisories

One flaw in a hand written extraction loop

Zip Slip is described in the README as a widespread critical archive extraction vulnerability that allows attackers to write arbitrary files on the system, typically resulting in remote command execution. The mechanism is a filename inside the archive, not the archive format. An entry whose name contains directory traversal segments such as `../../evil.sh` will, if the extraction code concatenates it onto a destination directory without checking, resolve to a path outside that directory. The write then lands wherever the process can reach. Because the payload is just a crafted archive that a user is asked to open, the trigger is a file the victim already expects to be safe, which is why the outcome is arbitrary write and then remote execution rather than a crash.

The vulnerable pattern, as published in the README

The README shows the pattern that the catalogue is built around, and it is worth reading closely because it is short:

   Enumeration<ZipEntry> entries = zip.getEntries();
   while (entries.hasMoreElements()) {
      ZipEntry e = entries.nextElement();
      File f = new File(destinationDir, e.getName());
      InputStream input = zip.getInputStream(e);
      IOUtils.copy(input, write(f));
   }

Every step is ordinary code. The loop walks the entries, builds a `File` from the destination directory and the entry name, opens a stream and copies the bytes. There is no validation between reading `e.getName()` and writing to `f`. A single check on the resolved path, comparing it against the destination directory, would break the attack, and the absence of that check is the whole vulnerability. The README notes that code similar to this has been found in many repositories across many ecosystems, including libraries that thousands of applications depend on.

Why Java was the worst affected ecosystem

The README explains the distribution mechanism rather than blaming developers. The vulnerability has been found in JavaScript, Ruby, .NET and Go, but it is especially prevalent in Java because there is no central library offering high level processing of archive files. With no `zip` library to lean on, teams wrote their own extraction code, and that code was shared and copied through developer communities such as StackOverflow, where the canonical how to unzip files recursively in Java thread became a distribution channel for the flaw. The same logic explains the presence of libraries that never offered a high level API, since people either copy pasted vulnerable private code or wrote their own equivalent snippet.

The archive formats in scope, from tar to 7z

Zip Slip is not limited to the zip format despite the name. The README states that the vulnerability can affect numerous archive formats, including `tar`, `jar`, `war`, `cpio`, `apk`, `rar` and `7z`. That matters for threat modelling. A team that assumed it was safe because it never accepted zip uploads from untrusted sources is still exposed if it unpacks a tarball or an apk. The exposure is a property of the extraction code and the entry names inside the archive, and both tar and zip store entry names as plain strings, so the traversal segments survive the format boundary. Any extraction routine that builds a destination path by string concatenation has the same weakness regardless of the container.

The affected library table and how it is kept current

The core of the repository is a table of affected libraries with a fixed version, a CVE identifier and the date the fix landed. It began with the libraries found during the private disclosure of Zip Slip, and the README says the list is aimed at keeping up to date with community support as more vulnerable libraries are discovered. The documented way to help is to contribute a finding, with the mechanics described in `CONTRIBUTING.md`. The repository layout supports that: besides the README and the contribution guide there are `SECURITY.md`, an `archives/` directory, a `catalog-info.yaml` and CircleCI and pre-commit configuration, so the catalogue is treated as structured data that is checked in automation rather than as loose prose.

The fixes, in versions and dates

Reading the table shows how quickly and how unevenly the ecosystem responded. The npm library `unzipper` was fixed in version 0.8.13 on 17/4/2018 under CVE-2018-1002203, and `adm-zip` in 0.4.9 on 23/4/2018 under CVE-2018-1002204. The Java libraries moved within days of each other: `zeroturnaround/zt-zip` in 1.13 on 26/4/2018 with CVE-2018-1002201, `codehaus/plexus-archiver` in 3.6.0 on 6/5/2018 with CVE-2018-1002200, and `srikanth-lingala/zip4j` in 1.3.3 on 13/6/2018 with CVE-2018-1002202. The .NET library `DotNetZip.Semverd` was fixed in 1.11.0 on 7/5/2018 under CVE-2018-1002205. Note the spread: the last of those fixes landed more than a month after the first, and the public disclosure was on 5 June 2018, which sits inside that window rather than after it.

What this repository does not do for you

It is worth being clear about the boundary, because the name invites a wrong assumption. This is a status catalogue. It contains no scanner, no static analysis rule, no patched library and no runtime protection, and the README itself points elsewhere for technical details, sending readers to the Snyk research page for the full write up. It also lists no GitHub releases, so there is no versioned artifact to consume, and no licence is listed for the repository. The last push was on 2026-09-21, which tells you the table is still being touched. If you want a defence rather than a list, the alternative approach is to validate the resolved destination path inside your own extraction code before opening the output file, which catches the bug regardless of which library version you are pinned to, rather than relying on every dependency being above its fixed version.

Editorial conclusion

Adopt the catalogue in this repository as a checklist when you audit code that extracts archives, because it names the affected packages, their CVEs and the versions that closed the hole. Do not adopt it as a security control, since the repository is a status page with no scanner, no patch and no runtime behaviour. Verify first that the versions you ship match the fixed versions listed for each library, and remember the disclosure date of 5 June 2018, since anything still pinning an affected version predates the fix entirely.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. snyk/zip-slip-vulnerability on GitHub