How Do Zip Bombs Work? | Tiny File, Huge Damage

A zip bomb abuses one of compression’s best traits: it can shrink repeated data into a tiny package. That tiny package can look harmless at a glance. Once a scanner, mail gateway, server, or person opens it, the archive expands so hard that the target machine runs out of room or burns through memory and processor time.

The trick is not magic. It is math, file structure, and timing. The attacker packs data so densely, or nests archives so deeply, that the job of unpacking becomes the attack. A normal ZIP file saves space. A zip bomb turns that same idea into a denial-of-service weapon.

What A Zip Bomb Tries To Do

The goal is plain: force a system to spend more resources unpacking data than it can spare. The system may freeze, crash, slow to a crawl, or skip later scans. In a mail server or upload pipeline, that can clog the whole line behind one small file.

Most zip bombs hit one or more of these pressure points:

• Disk space: The extracted content grows until the drive fills.
• Memory: The parser holds too much data in RAM.
• CPU time: Decompression and recursion keep cores busy for too long.
• Scanner limits: Antivirus or file inspection tools time out, skip content, or stop early.
• Cloud cost: Auto-scaling jobs may spin up extra workers just to chew on junk.

That last point gets missed a lot. A zip bomb does not need to steal data to hurt a service. It can burn compute, fill logs, and stall queues. On a busy platform, even one bad archive can cause a nasty backlog.

Zip Bomb Mechanics Inside Compressed Archives

A zip bomb usually relies on one of two moves. The first is heavy compression of highly repetitive content. The second is nesting, where one archive contains more archives, which each contain more archives, and so on. Some files mix both.

Compression Is The Bait

ZIP compression loves repeated patterns. A giant file made of the same byte over and over can shrink to a tiny size. That means a small download can hide an absurd expansion ratio. The machine opening it only learns the real cost when decompression starts.

Say a file is packed with long runs of zeros. The archive can store short instructions that mean “repeat this again and again” instead of storing every byte. The result is a tiny archive on disk and a monster payload after extraction.

Recursion Makes The Blast Bigger

Nesting makes the trap nastier. An archive can contain copies of other archives, which each contain more copies. A scanner that opens every layer may end up chasing a tree that grows faster than expected. This is one reason people also call zip bombs decompression bombs.

OWASP’s ZIP bomb testing notes describe the attack as an archive built to exhaust disk or memory on the system that extracts it. That wording gets right to the point: the danger is not the tiny file itself, but the workload hidden inside it.

The Trigger Can Be A Scanner, Mail Gateway, Or User

Many victims never double-click the file. The archive may be opened by a security tool trying to inspect attachments, a web app checking uploads, a backup job cataloging files, or a document parser reading Office files built on ZIP containers. A zip bomb can strike the moment an automated service tries to be careful.

That is why this attack still matters. Good security practice often means unpacking files before trust is granted. The bomb turns that habit against the defender.

Zip Bomb Pattern	How It Works	What It Strains
Single huge repeated file	Compresses a mass of repeated bytes into a tiny archive	Disk space after extraction
Nested archives	One archive contains many more archives across several layers	CPU time and recursion depth
Wide fan-out	Each layer expands into many child archives or files	File count and scan queue length
Mixed-content bundle	Benign files sit beside bomb content to look ordinary	Human review and automated triage
Header trick plus payload	Metadata masks the cost until extraction starts	Parser reliability and scan accuracy
Office-style container abuse	Bomb logic rides inside ZIP-based document formats	Document indexing and preview services
Email attachment bomb	Mail security opens the archive before delivery	Mail gateway throughput
Upload pipeline bomb	App back end unpacks content for validation or conversion	Web app workers and temp storage

Why Tiny Archives Can Freeze Bigger Systems

The weak spot is the gap between compressed size and unpacked size. Many workflows make early decisions from the small number they can see first: upload limit, attachment size, queue priority, or time budget. The real cost arrives later, when extraction begins.

That is why decent defenses set limits on archive depth, expanded size, file count, and processing time. Microsoft even exposes policy settings to cap archive scanning depth and the maximum archive size to be scanned in Microsoft Defender Antivirus scanning options. The idea is simple: if a file asks the system to unpack too much, the scan should stop before the machine gets dragged down with it.

A second weak spot is trust in familiar formats. ZIP is normal. Office documents, Java archives, Android packages, and many app bundles lean on ZIP or related compression methods. So the wrapper can look routine even when the content plan is hostile.

Then there is the pipeline effect. One worker thread gets stuck. Temp storage fills. Retry jobs kick in. Queues grow. Alerts pile up. A single archive can ripple across a service long after the first extraction attempt begins.

How Defenders Spot And Stop Decompression Bombs

Defenders do not need to unpack every byte of every archive to stay safe. They need limits, sane defaults, and isolation. A good archive-handling flow treats compressed files as untrusted until size, depth, and structure pass clear checks.

Some libraries bake those checks right into parsing. Apache POI’s ZipSecureFile class can reject entries by inflate ratio and entry size, which is a clean way to stop suspicious expansion before memory use gets silly.

Practical defenses usually stack together:

• Cap recursion depth for nested archives.
• Cap total unpacked bytes, not just archive size.
• Cap the number of files created during extraction.
• Use timeouts and CPU budgets for parsers.
• Extract in a sandbox with tight disk and memory quotas.
• Log partial scans so skipped content does not vanish from view.
• Block or quarantine archives that break policy instead of trying harder.

Notice the pattern: every control limits work. That is the heart of defense here. You are not trying to outsmart every bomb design by signature alone. You are shrinking the blast radius when an archive asks for too much.

Defense Control	What It Limits	Why It Helps
Expanded-size cap	Total bytes after extraction	Stops disk exhaustion early
Depth cap	Nested archive layers	Prevents runaway recursion
Entry-count cap	Number of files inside the archive	Keeps fan-out under control
Inflate-ratio check	Compression ratio per entry	Flags files that expand far past normal ranges
Sandbox extraction	Memory, CPU, and temp storage	Contains damage to a disposable space
Timeouts	Processing time	Prevents long hangs in queues and scanners

What Good Handling Looks Like

A safer workflow checks metadata, applies hard limits, and extracts in a low-privilege temp area. If the archive trips a limit, the service marks it as blocked and moves on. That keeps one bad file from taking the whole system hostage.

For mail or upload systems, this also means telling operators when content was only partly scanned. Silent failure is nasty here. If the bomb causes the scanner to skip content and nobody notices, the archive has already won half the fight.

What This Means For Regular Users And Teams

If you are opening files by hand, the rule is simple: treat tiny archives with oversized claims as suspect. A 20 KB file that says it contains gigabytes of logs or media should raise an eyebrow. So should archives from strangers, surprise invoices, or random “documents” sent outside the usual channel.

If you run a site or service that accepts uploads, the rule is stricter. Do not rely on file extension checks, and do not trust compressed size alone. Build your limits around the unpacked cost, the nesting depth, and the file count. Then isolate extraction from the rest of the app.

Zip bombs are old, but they keep showing up because the underlying trick never went away. Compression is useful. Automated scanning is useful too. When those two meet without guardrails, a tiny file can still make a healthy system sweat.

The Real Lesson Behind A Zip Bomb

A zip bomb works by turning decompression into the weapon. The file stays small while the work hidden inside it grows out of proportion. Once a target starts unpacking, the archive can eat disk, memory, processor time, or scan capacity until the service chokes.

That is why smart defenses measure work, not just file size. When a system sets hard extraction limits and keeps archive handling boxed in, the bomb loses its punch.