Understanding Zip Bombs: Construction, Risks, and Mitigation

Why zip bombs still matter in 2025

Even though modern operating systems and antivirus engines have improved, zip bombs remain a potent resource‑exhaustion weapon. Security teams, developers of file‑upload services, and SaaS platforms must understand the underlying mechanics to design robust mitigations. This article dives deep into the technical construction of non‑recursive zip bombs, explains the compression tricks that push ratios beyond 28 million‑to‑1, and outlines practical defenses.

What is a zip bomb?

A zip bomb is an archive—usually a .zip file—containing data that inflates dramatically after a single decompression pass. Unlike recursive bombs that nest zip files within zip files, the non‑recursive variant achieves massive expansion by overlapping file entries inside the same container.

• Small on disk (often < 50 KB).
• Explodes to gigabytes, terabytes, or even petabytes when extracted.
• Targets the unzip routine, not the operating system directly.

Because the payload is hidden inside a legitimate‑looking archive, many web applications automatically accept it, making zip bombs a stealthy attack vector.

Technical details that make a zip bomb explode

1. Compression fundamentals: DEFLATE, Zip64, and bzip2

Most zip parsers default to the DEFLATE algorithm. DEFLATE can compress a stream of repeated bytes at most 1 032‑to‑1. To surpass this limit, attackers use two tricks:

1. Overlapping files: Multiple central‑directory entries point to the same compressed data block (the “kernel”).
2. Non‑compressed DEFLATE blocks: These “quote” local file headers so that each entry re‑uses the kernel without duplicating it.

When the kernel is compressed to the theoretical DEFLATE limit, each additional file adds only a tiny header (≈ 47 bytes). The total uncompressed size grows quadratically with the number of files, yielding ratios like 28 million‑to‑1 for a 42 KB zip that expands to 281 TB.

2. Overlapping file entries

In a standard zip file, each file has:

• A local file header (30 bytes + filename).
• Compressed data.
• A central‑directory header (46 bytes + filename) at the end of the archive.

By making many central‑directory headers reference the same local header, the same compressed kernel is decompressed for every entry. The first entry incurs the full overhead; every subsequent entry costs only the central‑directory header, dramatically improving the compression ratio.

3. Quoting local headers with DEFLATE non‑compressed blocks

DEFLATE supports “stored” (non‑compressed) blocks that simply copy the next n bytes verbatim. Attackers prepend a 5‑byte non‑compressed block before each quoted header, allowing the parser to treat the header bytes as part of the decompressed stream. This technique preserves compatibility with most unzip tools while keeping the kernel reusable.

4. Zip64 extensions

Standard zip limits (16‑bit file count, 32‑bit size fields) cap the maximum uncompressed output at ~281 TB. Zip64 expands these fields to 64 bits, allowing bombs that reach petabytes. However, Zip64 is less universally supported, so many attackers prefer the classic format for broader impact.

5. bzip2 – a denser but less flexible alternative

bzip2 can achieve a theoretical compression ratio of about 1.4 million‑to‑1 on repetitive data, far exceeding DEFLATE. The downside: bzip2 lacks non‑compressed blocks, so overlapping tricks cannot be applied. Consequently, a bzip2‑based bomb must duplicate the kernel for each file, limiting its overall ratio compared to the quoted‑overlap DEFLATE method.

6. CRC‑32 handling at scale

Each file entry stores a CRC‑32 checksum of its uncompressed data. Computing this checksum naïvely would require decompressing the entire payload—impractical for a bomb. Researchers use matrix‑based CRC composition, allowing the checksum of the shared kernel to be calculated once and then combined with the small quoted headers in O(N) time, where N is the number of files.

7. Real‑world examples

Source: original research paper

Security implications and mitigation strategies

Because zip bombs exploit the decompression step, they bypass many traditional file‑type filters. Below are proven defenses for developers and security teams.

1. Enforce strict size limits

Before extraction, check the compressedSize field against a configurable threshold (e.g., 5 MB). Reject archives that exceed the limit or that claim an uncompressed size far larger than the compressed size.

2. Perform a “dry‑run” scan

Many libraries (e.g., zipfile in Python, java.util.zip) allow you to read central‑directory entries without writing files. Use this pass to sum declared uncompressed sizes and detect anomalous ratios.

3. Limit resources per extraction

Run the unzip process inside a sandbox or container with caps on CPU time, memory, and disk I/O. Tools like systemd‑run or Docker resource limits can automatically kill runaway extractions.

4. Detect overlapping entries

Overlapping files are a hallmark of the quoted‑overlap technique. Implement a validator that ensures each local header’s offset is unique and that the central directory does not reference the same offset multiple times.

5. Disable Zip64 when not needed

If your application never needs >4 GB archives, reject any Zip64‑enabled files. This removes the ability to craft petabyte‑scale bombs.

6. Keep libraries up‑to‑date

Modern unzip implementations (e.g., 7‑Zip 21.07, Info‑ZIP 6.1) include patches that warn on overlapping entries or abort on suspicious compression ratios.

By combining these layers—pre‑validation, resource caps, and library hardening—organizations can neutralize the threat without sacrificing legitimate zip functionality.

Why SaaS providers should care

Many SaaS products accept user‑generated zip files for bulk uploads, theme packages, or data imports. A malicious actor could embed a zip bomb to exhaust shared compute resources, leading to service degradation or denial of service for all tenants.

Integrating robust zip handling into your platform aligns with the Enterprise AI platform by UBOS philosophy: secure, scalable, and AI‑ready. For example, you can leverage the Workflow automation studio to create a pre‑processing pipeline that validates archives before they enter your core services.

Additionally, the AI marketing agents can automatically flag suspicious uploads based on compression ratios, reducing manual review workload.

Explore related UBOS resources

• Telegram integration on UBOS – learn how to forward alerts from your security pipeline directly to Slack‑like channels.
• ChatGPT and Telegram integration – automate incident response conversations.
• OpenAI ChatGPT integration – enrich your security dashboards with AI‑generated insights.
• Chroma DB integration – store vector embeddings of file metadata for fast similarity search.
• ElevenLabs AI voice integration – turn alerts into spoken notifications.
• UBOS for startups – secure your early‑stage product with minimal overhead.
• UBOS solutions for SMBs – affordable security automation for small businesses.
• Web app editor on UBOS – quickly prototype a secure file‑upload UI.
• UBOS pricing plans – find a plan that fits your security budget.
• UBOS portfolio examples – see real‑world deployments that already mitigate zip‑bomb threats.