Zip Slip, zip bombs and malicious archives

The specification says an entry name must be a relative path using forward slashes, and must not contain a drive letter or a leading slash. Nothing enforces that — the name is just bytes. Put ../../../../etc/cron.d/backdoor in an entry and a naive extractor that joins the name onto the destination directory will happily walk back out of it and write wherever the path lands.

Snyk gave this class of bug the name Zip Slip in June 2018 and published a list of thousands of affected projects across Java, JavaScript, Python, Go and Ruby — including build tools and CI systems that unpack archives supplied by other people. The bug is old, but the disclosure showed how many ecosystems had reimplemented the same mistake independently.

The same trick has sibling forms. A name beginning with / is an absolute path; a name beginning with C:\ is an absolute Windows path; a name using backslashes is ambiguous, because some extractors treat a\b as a directory separator and others as a file literally called a\b. Any of them is a sign that the archive was not produced by a well-behaved tool.

On Unix-like systems a ZIP entry can be a symbolic link: the external attributes field carries the file mode, the link type is set, and the entry's content is the path it points at. Extract that and you have created a pointer, not a file.

The attack is to put two entries in the archive. The first is a symlink named config pointing at /etc or at the user's home directory. The second is an ordinary file named config/authorized_keys. An extractor that processes entries in order, creating each one as it goes, writes the second file straight through the link and out of the destination folder — without any .. appearing anywhere.

Careful extractors defend against this by resolving the final destination of every entry and refusing anything that escapes the target directory, or by creating all regular files first and links last. Neither defence is free, which is why it is worth knowing whether your tool bothers.

The famous 42.zip is 42 KB on disk. Inside it are sixteen archives, each of which contains sixteen more, five layers deep, and at the bottom sit files of 4.3 GB each consisting of a single repeated byte. Fully expanded it is about 4.5 petabytes. It was built to exhaust antivirus scanners that unpacked nested archives without a budget.

Recursion is not required. In 2019 David Fifield published a non-recursive construction that overlaps the compressed data: many entries in the central directory point into the same deflate stream at different offsets, so a single copy of the data is counted many times over. His example is a 42 KB file that expands to 5.5 GB in one pass, and a ZIP64 version reaching 281 TB from 10 MB.

Both kinds are visible in the listing before you extract anything. Recursive bombs show as a handful of nested archives; overlapping bombs show as entries whose uncompressed size is thousands of times the compressed size. A tool that displays per-entry ratios and flags anything above roughly 100× gives you the warning for free.

Every entry is described twice — once in its local header and once in the central directory — and nothing guarantees the two agree. Some tools trust the local header, some the central directory. An archive crafted so that the two disagree can show one harmless file to a scanner and deliver a different one to the extractor.

Duplicate names are the simpler version of the same problem. If an archive has two entries called setup.cfg, the file you end up with depends on whether your extractor keeps the first or overwrites with the last — and both behaviours exist in the wild. A listing that shows the duplicate at least tells you the archive is not what it appears to be.

Extra bytes before the archive are legitimate in one context and suspicious in another. A self-extracting archive genuinely starts with an executable stub, and a signed APK carries a signing block, but an unexplained megabyte in front of a plain .zip from an unknown sender is worth noticing.

A .docx is a ZIP containing XML parts, relationship files, embedded images and fonts. That makes it a convenient carrier: the container is familiar, the extension looks harmless, and the interesting content is several layers in. A .docm, .xlsm or .pptm additionally holds a vbaProject.bin — a compiled VBA project that can run when the document opens.

Since 2022 Microsoft blocks macros by default in Office files that carry the Mark of the Web, which pushed attackers towards delivering documents inside archives precisely because unpacking an archive strips that marker. That is the mechanism behind the flood of invoice.zip attachments: the ZIP is the wrapper that launders the file's origin.

Opening the container and reading the part list is a cheap check. A real invoice is a handful of XML parts and maybe a logo; a document with a vbaProject.bin, an unexpected oleObject1.bin or an external relationship pointing at an http URL is telling you something before you ever open it in Word.

The defences are unglamorous and well understood. Normalise every entry name — strip drive letters and leading slashes, resolve . and .., and reject anything that still points outside the destination. Refuse to follow symlinks during extraction, or create them last. Apply a budget: stop when total output exceeds some multiple of the archive size or a fixed ceiling.

For a viewer the job is smaller but the principle is the same: never trust the name, show the user exactly what the archive claims, and say plainly which claims are unusual. ZipPeek flags traversal, absolute paths, drive letters, backslashes, symlinks, duplicates, encrypted entries, nested archives, very deep paths and extreme ratios, and it normalises paths again when it repacks a selection.