A zip bomb is a small compressed archive designed to expand to an enormous size when decompressed, exhausting the memory, disk or processing time of whatever opens it. It carries no malware. The damage comes from the act of unpacking it, which makes it a denial-of-service attack rather than an infection.
Why the numbers get so extreme
Compression works by describing repetition compactly. A file of ten million identical bytes can be stored as an instruction to repeat one byte ten million times, which is why highly repetitive data compresses so well. A zip bomb is simply that idea taken to its limit and pointed at whoever opens the file.
The weakness has its own catalogue entry, CWE-409, improper handling of highly compressed data. DEFLATE, the algorithm behind the ZIP format, has a ceiling: it cannot compress data by more than about 1,032 to one. That sounds like it should cap the problem, and for a long time attackers worked around it by nesting archives inside archives, so each layer multiplied the last. The famous published example expands to petabytes, but only if something unpacks it recursively, layer after layer.
In 2019, security researcher David Fifield published a construction that removes the need for nesting. By overlapping files so that many entries in the archive all point at a single block of compressed data, the archive reaches its full size in one pass. His published figures are worth quoting exactly:
| Archive | Compressed size | Expands to | Ratio |
|---|---|---|---|
| zbsm.zip | 42 kB | 5.5 GB | 129,000:1 |
| zblg.zip | 10 MB | 281 TB | 28 million:1 |
| zbxl.zip (Zip64) | 46 MB | 4.5 PB | 98 million:1 |
The practical consequence for anyone accepting uploads is that a depth limit is no longer sufficient. A single-layer archive can be as damaging as a deeply nested one, and it will not look unusual on the way in.
Why upload endpoints are the target
A zip bomb needs something to open it, which makes any feature that accepts and processes an archive a natural place to send one. Document upload, bulk import, attachment handling, a build pipeline that unpacks artefacts, an email gateway that inspects attachments: all of them decompress untrusted data as a matter of routine.
There is a particular irony worth understanding. Your malware scanner has to open the archive to look inside it, so a scanner without its own resource limits becomes a target rather than a defence. The same is true of anything that inspects archives on your behalf, which is why the protection has to sit around the decompression step rather than inside the detection logic.
Nothing about the file looks suspicious in transit either. It is a small, structurally valid archive that arrives well within any sensible upload size limit. The size limit you are enforcing is on the compressed file, and the compressed file is genuinely small.
How to defend against them
Fifield's own conclusion is the right starting point, and it points away from detection: strong protection means sandboxing the parser to limit its use of time, memory and disk space. Rather than trying to enumerate and block every construction someone might invent, apply resource constraints uniformly to anything untrusted that you decompress.
In practice that means four limits, all enforced during extraction rather than checked afterwards:
- Total uncompressed output. Decide the largest legitimate expansion your feature needs and abort the moment the running total exceeds it. This is the limit that stops a single-layer bomb
- Entry count. A legitimate archive rarely holds tens of thousands of files. Cap it
- Recursion depth. Still worth setting, because nested bombs have not gone away, but no longer sufficient on its own
- Time and memory. Run the extraction where you can cap both and kill it cleanly, so a runaway operation takes down a worker rather than the service
A compression ratio check is a useful early signal on top of these, but it is a heuristic rather than a boundary. Legitimate files sometimes compress remarkably well, so treat an unusual ratio as a reason to be careful rather than as a verdict.
It is worth being clear about what other controls do and do not cover here. Signature scanning catches published examples and misses new ones, because there is nothing malicious to match on. Handing the file to an external scanner moves the decompression somewhere else rather than removing it. And content disarm and reconstruction rebuilds a document from its safe components, which addresses structural threats inside a file rather than the cost of unpacking a container. Resource limits are the control that actually fits this problem.
Resource limits handle the container. The documents inside it are a separate question. Once an archive is safely unpacked, you still have untrusted documents to deal with. The Red Eagle Tech CDR API rebuilds each one from its safe components and hands back a working file, with published per-document pricing and self-service signup.
