What is a Zip Bomb and Why It Still Matters

A zip bomb (also called a decompression bomb or malicious archive) is a specially crafted compressed file that looks harmless at first glance but is designed to overwhelm systems when it is unpacked. Instead of carrying a standard payload like malware, a zip bomb exploits the compression process itself. A tiny file can expand into gigabytes or terabytes of data, consuming CPU, memory, disk space, or scanning resources and causing denial-of-service conditions for antivirus tools, mail servers, or endpoint systems.

Zip bombs are not flashy. They are quiet, clever, and highly disruptive, especially in environments that automatically open or scan attachments. Understanding how they work, where the risk lies, and how to protect systems is important for any security-conscious organization.

How zip bombs work

At a high level, a zip bomb uses compression characteristics to multiply its size when decompressed:

• Highly redundant content: The archive contains repeating patterns such as the same small chunk repeated millions of times. Compression algorithms shrink that repetition into a much smaller file. When decompressed, the repetition re-expands into its full, very large form.

• Nested archives: An archive may contain many layers of compressed files (zip inside zip inside zip). A scanner that follows every nested archive can get stuck decompressing multiple levels, rapidly consuming resources.

• Abuse of file format features: Some archive formats support directory structures, symbolic links, or pointers that can be abused to reference large logical structures on decompression.

The key to remember is that the danger does not come from malicious code but from the overwhelming amount of data created during decompression. This makes zip bombs effective against tools that are programmed to automatically unpack and inspect everything.

Real-world impact

Zip bombs have been used to evade detection and disrupt systems. Classic examples included tiny archive files that expanded into petabytes when decompressed, forcing antivirus engines or mail gateways into lengthy scans or crashes. Even today, automated pipelines that unpack attachments or index archive contents remain vulnerable. The damage is often operational: slowed services, full disks, timeouts, and missed alerts, rather than direct data theft.

How organizations can defend against zip bombs

Protecting systems from decompression bombs is about setting sensible limits, improving visibility, and using smart scanning practices.

1. Set decompression limits

   Configure antivirus and gateway scanners to impose maximum limits on decompression depth and total uncompressed size per file. If an archive exceeds the limit, flag it instead of attempting to fully expand it.

2. Block risky file types at the

   Block or quarantine archives from untrusted sources, especially nested archives such as .zip files inside .zip files. Require manual review for archives containing executables or large numbers of nested files.

3. Use streaming scanners

   Modern scanners can inspect compressed archives without fully decompressing them. Stream-based scanning examines metadata and file headers for anomalies before expansion becomes a problem.

4. Monitor resource usage and set quotas

   Enforce per-process CPU, memory, and disk quotas for scanning processes and email gateways. Trigger alerts when a scan consumes excessive resources.

5. Educate staff and enforce email policies

   Train employees to be cautious with unexpected attachments. Use email policies to route suspicious archives to a safe sandbox instead of allowing automatic unpacking.

6. Sandbox suspicious files

   Run suspect archives in isolated environments that limit resource impact and monitor behavior before allowing them into production.

7. Log and alert on unusual archive characteristics

   Detect unusually high compression ratios or archives with deep nesting. These are red flags that should always be investigated.

Detection tips for defenders

• Watch for extreme compression ratios where a small file expands into hundreds of gigabytes.

• Flag archives with thousands of files or multiple nested layers.

• Use heuristics: legitimate archives rarely require deep nesting or excessive expansion factors.

• Combine static checks such as metadata analysis with dynamic, throttled unpacking in a sandbox.

Bottom line

Zip bombs are a reminder that attackers do not always need sophisticated malware to cause damage. By exploiting features of file formats and automated processes, they can target the operations of security tools and mail systems. The good news is that practical controls such as decompression limits, sandboxing, resource quotas, and smarter scanning significantly reduce the risk.

If your team scans incoming archives automatically, treat that pipeline like any other service: apply rate limits, monitor resource use, and set safe policies that protect systems without creating outages. With these guardrails in place, a zip bomb becomes far less dangerous.