What Is a Zip Bomb? The 42KB File That Crashes Servers (DoS Explained)

A 42 KB file crashed an entire server — and this is what we call a DoS attack, denial of service.

Let's say you have a zip file that's 42 KB. You'd assume that's all there is to it. But the moment you start unzipping it, its size blows up — not to a few megabytes, but to roughly 4.5 petabytes. And this is exactly what attackers use, called a zip bomb.

The famous 42.zip

The canonical example is a file called 42.zip. It is, as the name suggests, 42 kilobytes compressed. Uncompressed, it expands to 4,507,998,139,048,459 bytes — about 4.5 petabytes (4,500,000 GB). That's a compression ratio of roughly 100-million-to-one.

How? It's not "zipped 42 times" sequentially, as a popular explainer once put it. 42.zip works through nested layers: 5 layers of zip files, 16 archives per layer, with each bottom-level archive holding a single 4.3 GB file. The compounding is exponential, not linear.

The newer, scarier variant

In 2019, researcher David Fifield built a zip bomb that doesn't even need nesting. A single 46 MB file expands to the same 4.5 PB without layers, using overlapping file entries inside the zip structure. This matters because many antivirus tools only check recursion depth — they'd flag a deeply nested bomb but miss a flat overlapping one.

Fun fact: Fifield's "zblg" bomb is a 46 MB file that decompresses to 4.5 PB. The compression ratio is so extreme that just listing the contents takes meaningful compute.

How the attack actually plays out

Say an attacker uploads this zip file to a file-upload endpoint on your server. Your server dutifully starts unzipping it — allocating memory, writing decompressed bytes to disk, unzipping, unzipping, unzipping. CPU pegs to 100%. Disk fills. RAM exhausts.

Meanwhile, a real user makes a request. Your server is busy being murdered by a 42 KB file, so it doesn't respond. That's a DoS attack — denial of service — meaning the server couldn't respond to legitimate traffic.

This is technically a decompression bomb / resource-exhaustion attack, a specific kind of DoS. It's worth naming it precisely rather than just saying "DoS."

How to defend against zip bombs (and decompression bombs generally)

This is the part most explainers get half-right. Rate limiting, WAF/Cloudflare, CAPTCHA, and load balancers all help with traffic-based DoS — they throttle the number of requests hitting you. But the zip-bomb-specific fix is different and more important:

• Cap decompression size and ratio before and during extraction. Set a hard maximum on total output bytes (e.g. refuse anything that would decompress beyond 1 GB for an upload endpoint).
• Cap recursion depth. Refuse nested archives deeper than, say, 3–5 layers.
• Stream, don't buffer. Decompress with a streaming approach and a kill switch — the moment cumulative output crosses your threshold, abort.
• Reject by content type, not just extension. Verify the actual file type (magic bytes), not the .zip suffix a client sent you.
• Run extraction in a sandbox with strict memory/CPU/time limits — a container with cgroups, or a lambda with a tight timeout.

The deeper principle: never trust input size as a proxy for resource cost. A 42 KB input can cost you petabytes of work. Always bound the work, not the input.

The broader lesson for production

This is exactly the kind of thing a production readiness review catches — and exactly why "file upload validation" appears as a checklist item in our Security section. It's not enough to validate the type and size of an incoming file; you have to validate the cost of processing it.

When you run your stack through the ShipReady checklist generator, pay special attention to the Security section's file-upload item. The checkbox is small. The blast radius if you skip it is 4.5 petabytes.

Further reading

• David Fifield's original zip bomb writeup (the source of the 2019 overlapping-entries variant)
• The 42.zip file itself — handle with extreme care; do not decompress on any machine you care about
• OWASP's "Denial of Service" Cheat Sheet for the broader attack class

Originally adapted from a security explainer script; corrected with accurate figures (4.5 PB, not 4.7 million; nested layers, not 42 sequential zips) and expanded with mitigation specifics.