Cybersecurity glossary
What is a Decompression Bomb?
Learn what a decompression bomb is, how gzip, xz, brotli, and image codecs amplify tiny inputs into huge outputs, how this differs from zip bombs, and how to bound decode safely.
Definition
A decompression bomb is any crafted compressed or encoded payload—ZIP is only one case—whose decode expands into far more data than the input size, exhausting memory, disk, or CPU in gzip, xz, brotli, image, or similar decoders.
Why decompression bombs matter
Modern stacks decode everywhere: HTTP Content-Encoding, artifact stores, log shippers, thumbnailers, and message queues. A decompression bomb abuses that trust: tiny inputs decode into enormous outputs across gzip, xz, brotli, classic compress, and image codecs—not just ZIP.
Teams that only guard against zip bombs still leave gunzip-on-request and image-resize paths wide open to the same amplification class of DoS.
How decompression bombs work
Pick a decode sink
Find gunzip middleware, brotli proxies, xz artifact loaders, or image libraries that inflate bytes automatically.
Craft a high-amplification payload
Build highly compressible streams or codec-specific constructs that expand far beyond the wire size.
Deliver through normal APIs
Send via upload, request body encoding, webhook payload, or media import—often looking like legitimate traffic.
Force full or near-full decode
Frameworks that buffer entire decoded bodies allocate RAM proportional to uncompressed size.
Cross resource budgets
Memory, temp disk, and CPU spike while other requests wait on exhausted workers.
Take the service down
OOMs, timeouts, and cascading failures deny service until limits and isolation are applied.
Common bomb surfaces beyond ZIP
gzip / deflate
Request and response Content-Encoding paths that inflate entire bodies into memory.
xz / lzma / brotli
High-ratio codecs used for artifacts and APIs can amplify even more aggressively than gzip.
Image codecs
Decode and resize pipelines expand pixel buffers far beyond compact on-disk encodings.
Multi-layer encoding
Double-compressed or nested encodings stack amplification across successive decoders.
Prevention
| Practice | Detail |
|---|---|
| Cap every codec | Apply absolute uncompressed ceilings and ratio limits for gzip, xz, brotli, archives, and images alike. |
| Stream, do not buffer | Decode incrementally with abort-on-budget; avoid loading fully inflated payloads into RAM. |
| Allowlist encodings | Accept only needed Content-Encoding and media types; reject surprise compressed wrappers. |
| Isolate heavy decode | Run unpackers and image workers with memory/CPU quotas separate from latency-critical APIs. |
- Inventory every gunzip, unxz, brotli, archive, and image-decode path in the request and upload pipeline.
- Enforce max compressed size, max uncompressed size, decode timeout, and peak memory per request.
- Disable automatic multi-layer decompression unless each layer is independently budgeted.
- Tune reverse proxies so they do not silently inflate huge bodies before the app sees them.
- Add tests that send high-ratio gzip/brotli and oversize images and expect rejection.
- Alert on decode duration and inflation ratio outliers as early [resource exhaustion](/glossary/resource-exhaustion) signals.
- Keep zip-bomb controls, but do not treat ZIP as the only amplification format.
- Review auto-decode defaults as potential [security misconfiguration](/glossary/security-misconfiguration).
The practical takeaway
A decompression bomb is codec-agnostic amplification: gzip, xz, brotli, images, and archives can all turn small inputs into huge expansions. Bound every decoder—not only ZIP extractors.
If your stack inflates bytes without a meter, an attacker only needs to find which codec you trust.
Related security terms
Zip Bomb
ZIP-specific nested and overlapping archive ratio attacks within this broader class.
Denial of Service (DoS)
The availability outcome when decode amplification stalls or crashes services.
Resource Exhaustion
App-level CPU, memory, and disk exhaustion during unbounded decode.
File Upload Vulnerability
Uploads and Content-Encoding paths often feed hostile compressed bytes.
Frequently asked questions
What is a decompression bomb in simple terms?
A small compressed blob that balloons into a huge amount of data when your server gunzips, unxzs, or decodes it—enough to run out of memory or disk.
How is this different from a zip bomb?
Zip bombs target ZIP archives (often nested/overlapping). Decompression bombs cover any codec: gzip, deflate, xz, brotli, compress, and many image formats.
Can HTTP Content-Encoding be abused?
Yes. Clients or intermediaries that send highly compressible bodies with Content-Encoding: gzip (or similar) can force reverse proxies and apps to allocate huge buffers on decode.
Do image uploads count?
Yes. Highly compressible or specially crafted images can expand massively during decode or resize, which is a common media-pipeline bomb.
Is ratio alone enough to detect them?
Ratio helps, but also cap absolute uncompressed size, decode time, and peak memory—some bombs stay under a naive ratio until late in the stream.
How do you prevent decompression bombs?
Set max compressed and uncompressed sizes, enforce timeouts, decode with streaming meters, disable unused encodings, and isolate media/archive workers.
Are zip bombs a subtype?
Yes. Treat zip bombs as archive-focused decompression bombs; defenses should cover every decode path, not only ZIP extractors.
References
Explore authoritative guidance and frameworks related to decompression bomb.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.