A file that is small on disk but expands dramatically when unpacked, often consuming extreme CPU, memory, or storage during processing. Attackers use it to overload systems that trust the archive size. The danger is especially acute in shared services that process untrusted input without strict resource limits.
What a Decompression Bomb Is
A decompression bomb is a file or archive that looks modest at rest but expands enormously when unpacked, so the apparent input size hides the true processing cost. The security issue is not the file itself, but the mismatch between stored size and expanded resource demand.
This pattern matters because many services decide whether to accept content before they fully decompress it. If the system trusts metadata, preview size, or compressed length too much, a tiny upload can trigger disproportionate CPU, memory, disk, or queue consumption during inspection or extraction.
How Decompression Bombs Work
Most decompression bombs exploit the way compression works: repeated patterns, nested archives, or recursive packaging can collapse a large amount of data into a small payload. When the archive is expanded, the processor has to materialise much more data than the source file suggested, sometimes repeatedly across multiple layers.
The impact depends on where decompression happens. A desktop tool may freeze or crash, a shared file-processing service may exhaust worker memory, and an automation pipeline may stall downstream jobs. In environments that process many uploads, a single crafted file can create a broad denial-of-service condition.
Decompression bombs are especially effective when systems perform automatic unpacking for malware scanning, indexing, previews, or content conversion. Those are sensible controls, but they become liabilities if resource limits, recursion limits, and expansion checks are weak or absent.
Where the Security Boundary Fails
The key failure is assuming that a safe-looking archive is a safe-looking workload. Size-based allowlists, naive recursion, and unlimited extraction paths all break that assumption. The risk is highest when untrusted content enters a shared service with broad processing rights and no isolation between users, tenants, or jobs.
Another common weakness is validating the compressed file before validation of the expanded content. If the decompressor itself is the point of failure, the surrounding application may never get a chance to enforce quotas, abort early, or reject suspicious structures. That turns a file-handling problem into an availability problem.
Because the attack abuses legitimate decompression behavior, it often avoids simple signature-based blocking. Defenses need to account for expansion ratio, nested depth, per-request limits, and the total resources a single object can consume during safe inspection.
Typical Defenses and Safe Handling Patterns
Robust handling starts with treating decompression as a potentially dangerous operation. Systems should bound how much data a single archive can expand into, limit nesting and recursion depth, and terminate processing when CPU, memory, or disk thresholds are exceeded. For shared services, isolate extraction work so one file cannot starve the entire platform.
Operationally, it also helps to pre-scan archives for suspicious expansion characteristics before full extraction, and to apply timeouts to scanning, indexing, and conversion workflows. When the content is not expected to be an archive, reject it rather than attempting broad automatic unpacking. Where decompression is unavoidable, log abnormal expansion events so repeated attempts can be detected quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Decompression bombs exploit unsafe handling of untrusted input. |
| SC-39 — Process Isolation | Shared decompression tasks need isolation to contain resource exhaustion. | |
| CP-10 — System Recovery and Reconstitution | A decompression bomb can force service restart or recovery after exhaustion. | |
| Recommendation — Validate archive inputs and reject content that can trigger unsafe expansion. Isolate extraction workloads so one archive cannot starve shared services. Prepare recovery procedures for extraction services that are exhausted or crashed. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Abnormal expansion attempts should be visible for detection and investigation. |
| Recommendation — Log suspicious archive expansion events and review them for abuse patterns. | ||
| NIST CSF 2.0 | PR.PS-03 — Platform Security | Safe handling of untrusted files is part of platform hardening against resource abuse. |
| Recommendation — Constrain file-processing services with limits that prevent archive-driven exhaustion. | ||
Related resources from NHI Mgmt Group
- What breaks when a service processes untrusted archives without decompression limits?
- Why do unsafe decompression paths create more risk than a routine denial of service issue?
- Who is accountable when a public Apache HTTP Server instance is left vulnerable to HTTP/2 bomb attacks?
- Decompression Ratio Governance
