Zip Bomb Attack
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.
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.
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.
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.
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
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.
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.
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
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
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
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