Skip to main content
HighProtected by PowerWAF

Zip Bomb Attack

CategoryFile & PathOWASPA05:2021 – Security MisconfigurationFirst seen1996Read time8 minVerified2026-03-12
DEFINITION

A zip bomb (also called a decompression bomb or zip of death) is a malicious archive file designed to crash or incapacitate the system that decompresses it. By exploiting the massive compression ratios achievable with repetitive data, a small file β€” sometimes only 42 kilobytes β€” can expand into petabytes of data, exhausting disk space, memory, and CPU resources. Zip bombs target antivirus scanners, file upload processors, email gateways, and any automated system that extracts compressed archives.

How Zip Bomb Attack Works

Compression algorithms like DEFLATE achieve their best ratios with highly repetitive data. A file consisting entirely of null bytes (0x00) can be compressed at ratios exceeding 1000:1. A zip bomb weaponizes this principle by either nesting compressed archives inside each other (recursive bomb) or using overlapping file entries that reference the same compressed data kernel (quine/flat bomb). When the victim's system decompresses the archive β€” whether to scan it for malware, process an upload, or extract attachments β€” the decompressed data floods available storage and memory, causing denial of service.

1

Construct the payload

The attacker creates a zip bomb using one of three techniques: (1) Classic recursive bomb: a ZIP file containing multiple ZIP files, each containing more ZIP files, creating exponential growth across layers β€” the famous 42.zip is 42 KB compressed but expands to 4.5 petabytes across 6 layers of 16 files each; (2) Flat (non-recursive) bomb: a single-layer ZIP using overlapping file entries that reference the same compressed data kernel β€” David Fifield's 2019 research produced a 46 MB zip that expands to 4.5 petabytes without nesting, defeating recursion-depth defenses; (3) Quine bomb: a self-referencing archive that contains a copy of itself, creating infinite recursion when a tool tries to recursively extract all nested archives.

2

Deliver the bomb to the target

Delivery depends on the target system: (1) Email attachment β€” sends the zip bomb to addresses protected by an email gateway that auto-scans attachments; the gateway's antivirus attempts to decompress and scan, exhausting server resources; (2) File upload β€” uploads the bomb to a web application that processes compressed files (document converters, image processors, CI/CD pipelines, CMS media importers); (3) API endpoint β€” submits the bomb to APIs that accept compressed request bodies (Content-Encoding: gzip, deflate) or compressed file uploads; (4) Malware scan evasion β€” wraps actual malware inside layers of a zip bomb so that antivirus scanners crash or time out before reaching the malicious payload.

3

Trigger decompression

The target system automatically decompresses the archive as part of its normal processing pipeline. Antivirus scanners decompress to inspect file contents. Upload processors extract archives to validate or transform the contents. Email gateways decompress to scan attachments. CI/CD systems extract archives for build processing. In each case, the decompression operation begins filling available resources: disk space fills first (if writing extracted data), or memory fills first (if decompressing in-memory). Modern flat bombs are particularly dangerous because they decompress in a single pass without recursion, bypassing depth-limit defenses.

4

Resource exhaustion and denial of service

As decompression proceeds, the system's resources are systematically consumed: (1) Disk space fills to capacity, potentially affecting other applications sharing the same filesystem β€” databases crash, logs can't be written, applications fail; (2) Memory exhaustion triggers the OS OOM killer (Linux) or causes system-wide thrashing; (3) CPU is consumed by the decompression operation itself, especially with high compression ratios requiring intensive computation; (4) The affected service crashes or becomes unresponsive, causing a denial of service. If the target is a shared service (email gateway, centralized AV scanner, CI/CD server), the blast radius extends to all users and systems that depend on it.

Real-World Examples

2001

42.zip β€” The original zip bomb

The 42.zip file became the canonical example of a zip bomb: a 42-kilobyte file that decompresses to 4.5 petabytes (4,503,599,627,370,496 bytes). It consists of 16 zip files nested 6 levels deep, each bottom-level file containing 4.3 GB of null bytes. When antivirus programs attempted to scan the file, they crashed or hung indefinitely. 42.zip exposed a fundamental weakness in AV architecture: the assumption that decompression is safe. It forced the entire antivirus industry to implement decompression limits β€” maximum recursion depth, maximum expansion ratio, and maximum decompressed size β€” fundamentally changing how security tools handle compressed files.

2019

Non-recursive zip bomb research (David Fifield)

Security researcher David Fifield published research demonstrating that zip bombs can achieve massive expansion ratios without recursion, bypassing the recursion-depth limits that AV vendors had implemented after 42.zip. His technique uses ZIP's feature of allowing multiple file entries to reference the same compressed data β€” a 46 MB file expands to 4.5 petabytes in a single decompression pass with no nesting. A smaller 10 MB variant expands to 281 TB. The research forced security vendors to rethink their decompression safeguards, as checking for nested archives was no longer sufficient.

2023

Zip bomb attacks on web application firewalls

Security researchers demonstrated that several commercial WAFs and API gateways were vulnerable to zip bomb attacks via compressed HTTP request bodies (Content-Encoding: gzip). By sending a small gzip-compressed request that expanded to gigabytes, attackers could crash or temporarily disable the WAF, creating a window to deliver unprotected malicious payloads to the upstream application. The attack targeted the defense infrastructure itself rather than the application, highlighting that security tools must protect themselves against decompression-based DoS.

Impact & Risk Assessment

Zip bombs are rated High because they exploit the fundamental trust that systems place in compressed data. The primary impact is denial of service: crashing antivirus scanners creates windows for malware delivery, crashing file upload processors disrupts business operations, and crashing email gateways blocks organizational communication. In shared infrastructure environments (cloud hosting, CI/CD platforms, multi-tenant SaaS), a zip bomb affecting one service can cascade to impact other tenants and services sharing the same resources. Beyond DoS, zip bombs serve as an evasion technique β€” by crashing or timing out the security scanner, the actual malicious payload (nested inside or delivered alongside the bomb) evades detection. The low complexity of creating zip bombs (tools and pre-built files are freely available) combined with the difficulty of defending against all variants makes this a persistent threat.

How to Detect Zip Bomb Attack

Implement decompression-aware detection at every point where compressed data is processed: (1) Check compression ratios before full decompression β€” flag files where the declared uncompressed size exceeds a threshold relative to the compressed size (ratios above 100:1 for a single file, or 1000:1 aggregate, warrant inspection); (2) Monitor resource consumption during decompression: set hard limits on memory allocation, disk write, and CPU time for any decompression operation; (3) Detect nested archives and enforce a maximum recursion depth (typically 2-3 levels suffices for legitimate use); (4) For flat (non-recursive) bombs, check for overlapping file entries in the ZIP central directory β€” legitimate archives rarely have multiple entries pointing to the same compressed data offset; (5) Monitor system-level indicators: sudden disk space consumption, memory pressure, or CPU spikes correlating with file processing events indicate possible decompression bomb activity.

How to Prevent Zip Bomb Attack

Apply defensive limits at every decompression boundary: (1) Set maximum uncompressed size limits β€” reject archives whose declared or actual decompressed size exceeds a reasonable threshold (e.g., 100 MB for user uploads, appropriate to the use case); (2) Enforce maximum compression ratio limits β€” reject files with ratios exceeding a threshold (e.g., 100:1); (3) Limit recursion depth for nested archives (max 2-3 levels); (4) Decompress to a dedicated filesystem or container with disk quotas and memory limits β€” use cgroups on Linux or resource limits in container runtimes to contain the blast radius; (5) Stream decompression with byte-counting: decompress incrementally and abort when the running total of decompressed bytes exceeds the limit, rather than trying to decompress everything first; (6) For HTTP request bodies with Content-Encoding: gzip/deflate, enforce a maximum decompressed body size at the web server or reverse proxy level (e.g., Nginx client_max_body_size applies after decompression); (7) Use timeout-based protection: set a maximum wall-clock time for any decompression operation; (8) Deploy a WAF with decompression bomb detection that inspects compressed uploads and request bodies before they reach the application.

Code Examples

Vulnerable: Extracting ZIP without limits
import zipfile
import os

# VULNERABLE: No size or ratio checks
def extract_upload(zip_path: str, dest_dir: str):
with zipfile.ZipFile(zip_path, 'r') as zf:
# Extracts everything β€” a zip bomb fills the disk
zf.extractall(dest_dir) # DANGER!

# A 42 KB zip bomb will attempt to write 4.5 PB to disk
# The server crashes long before that, but the damage is done:
# - Disk fills to 100%, crashing other services
# - OOM killer terminates critical processes
# - The application becomes unresponsive
Secure: Safe extraction with multiple limits
import zipfile
import os
from pathlib import Path

class ZipBombError(Exception):
pass

def safe_extract(
zip_path: str,
dest_dir: str,
max_files: int = 100,
max_total_size: int = 100 * 1024 * 1024, # 100 MB
max_ratio: float = 100.0, # 100:1 compression ratio
max_depth: int = 2 # Max nesting depth
) -> list[str]:
"""Safely extract a ZIP file with bomb detection."""
zip_size = os.path.getsize(zip_path)
if zip_size == 0:
raise ZipBombError('Empty archive')

with zipfile.ZipFile(zip_path, 'r') as zf:
members = zf.infolist()

# 1. Check number of files
if len(members) > max_files:
raise ZipBombError(
f'Too many files: {len(members)} > {max_files}')

# 2. Check total uncompressed size
total_uncompressed = sum(m.file_size for m in members)
if total_uncompressed > max_total_size:
raise ZipBombError(
f'Total size {total_uncompressed} exceeds limit {max_total_size}')

# 3. Check compression ratio
total_compressed = sum(m.compress_size for m in members)
if total_compressed > 0:
ratio = total_uncompressed / total_compressed
if ratio > max_ratio:
raise ZipBombError(
f'Compression ratio {ratio:.1f}:1 exceeds limit {max_ratio}:1')

extracted = []
running_total = 0
dest = Path(dest_dir).resolve()

for member in members:
# 4. Prevent path traversal in filenames
member_path = (dest / member.filename).resolve()
if not str(member_path).startswith(str(dest) + os.sep):
raise ZipBombError(
f'Path traversal detected: {member.filename}')

# 5. Skip nested archives beyond max depth
if member.filename.lower().endswith(('.zip', '.gz', '.tar', '.7z')):
# Log but don't recursively extract
continue

# 6. Stream extraction with byte counting
if not member.is_dir():
with zf.open(member) as src:
member_path.parent.mkdir(parents=True, exist_ok=True)
bytes_written = 0
with open(member_path, 'wb') as dst:
while True:
chunk = src.read(8192)
if not chunk:
break
bytes_written += len(chunk)
running_total += len(chunk)
if running_total > max_total_size:
# Clean up and abort
dst.close()
member_path.unlink()
raise ZipBombError(
'Actual decompressed size exceeds limit')
dst.write(chunk)
extracted.append(str(member_path))

return extracted

Frequently Asked Questions

A zip bomb does not directly damage hardware. It causes software-level denial of service by exhausting disk space, memory, or CPU. However, repeated crashes caused by zip bombs can lead to data corruption (e.g., database corruption if the database process is killed mid-write due to OOM), and in extreme cases, filling a disk to capacity can render a system unbootable if system partitions are affected. Modern operating systems and hardware are designed to handle resource exhaustion gracefully, but the software-level impact can still be severe.
A recursive (nested) zip bomb achieves its expansion through layers: a ZIP file containing ZIP files containing ZIP files, each layer multiplying the total size. The classic 42.zip uses 6 layers of 16 files. This type is defeated by setting a maximum recursion depth for archive extraction. A flat (non-recursive) zip bomb achieves the same massive expansion in a single layer by exploiting ZIP format features β€” specifically, multiple file entries pointing to the same compressed data kernel. David Fifield's flat bomb expands to 4.5 PB without any nesting. Flat bombs bypass recursion-depth defenses and require ratio-based or size-based limits to detect.
Yes. Web servers that accept compressed request bodies (Content-Encoding: gzip) can be targeted by gzip bombs β€” small compressed requests that expand to enormous payloads. If the server decompresses the entire request body into memory before processing it, this causes memory exhaustion. Most modern web servers and reverse proxies (Nginx, Apache, Caddy) have configurable limits on decompressed body size, but these must be explicitly set. API gateways, WAFs, and load balancers that inspect request bodies are also vulnerable if they don't enforce decompression limits.
A WAF protects at the perimeter by inspecting compressed uploads and request bodies before they reach the application. PowerWAF enforces configurable limits on maximum decompressed size, compression ratio, and recursion depth for all compressed content β€” including ZIP, GZIP, DEFLATE, and Brotli. It uses streaming decompression with byte-counting to abort processing as soon as limits are exceeded, preventing resource exhaustion. For file uploads, it inspects the ZIP central directory for overlapping entries that indicate flat bomb construction. These protections apply to both multipart file uploads and compressed HTTP request bodies.
Historically, yes β€” zip bombs were specifically designed to crash antivirus scanners. When AV software encountered a compressed file, it would attempt to decompress it fully to scan the contents, leading to memory exhaustion or disk filling. Modern AV products implement decompression safeguards (size limits, ratio limits, recursion limits, timeout), but researchers periodically discover bypass techniques (like flat bombs). Attackers use zip bombs as an AV evasion technique: by crashing or causing the AV to skip the file, the actual malicious payload inside or alongside the bomb avoids detection.

PowerWAF automatically blocks Zip Bomb Attack at the edge.

Deploy in minutes. No code changes required. Free plan available.

Free plan spots are limited Β· No credit card required