Zip Bomb

What a zip bomb is in security terms

A zip bomb is deceptive by design: the compressed object looks small and harmless, but its decompressed form can overwhelm storage, memory, CPU, and scanning queues. That makes it less a “file type” than a resource exhaustion technique.

Security teams usually encounter it at upload gates, email gateways, sandboxing systems, or backup and indexing workflows. The danger is not limited to the payload itself, because any automated process that decompresses, previews, or recursively scans archives can become the point of failure.

How decompression turns a small file into a large operational problem

The core mechanic is compression amplification. A highly compressed archive can expand many times over, especially when nested archives, repeated patterns, or recursive unpacking are involved. In practice, the apparent size of the upload is a poor indicator of the work required to inspect it safely.

This matters because many security controls assume that files can be safely opened, scanned, or extracted before they are allowed to proceed. With a zip bomb, the act of inspection can become the attack path, forcing systems to spend disproportionate resources just to learn what the file contains.

Where zip bombs tend to break workflows

Zip bombs are disruptive because they exploit normal operational trust in archive handling. They can stall malware scanners, trigger storage exhaustion, inflate backup windows, and slow or crash services that automatically unpack content for processing. In shared environments, that can affect more than one tenant, queue, or application at once.

The issue is not confined to security tooling. Search indexing, document conversion, data pipelines, and ETL jobs can also inherit the same weakness if they automatically expand untrusted archives without strict limits or early termination checks.

What makes zip bombs different from ordinary malicious files

A zip bomb is primarily a denial-of-service mechanism, not a payload delivery mechanism. Its success depends on exhausting resources before deeper inspection can complete. That means the defensive question is not only “is this file malicious?” but also “what happens if handling this file becomes very expensive?”

Because the risk is rooted in expansion ratio, recursion, and automated unpacking behavior, defenders should treat archive handling as a resource-control problem as much as a content-inspection problem. That distinction is why safe file intake often needs size limits, recursion limits, and hard stop conditions rather than relying on signature detection alone.

Risk and Threat Considerations

Zip bombs create denial-of-service risk wherever systems trust compressed input to remain cheap to inspect. The most common failure mode is an automated workflow that decompresses before it has enough safeguards to stop runaway growth, allowing a tiny upload to consume disproportionate compute, memory, or storage.

Failure mechanism: Recursive extraction, extreme compression ratios, and repeated pattern expansion force scanners or handlers into sustained resource consumption until the process times out, crashes, or blocks other work.

Impact: The result can be queue backlogs, service degradation, failed uploads, delayed incident response, and in shared infrastructure, wider operational disruption than the original file would suggest.

Practitioner Guidance

What to watch for: Archive handling should be designed to fail safely on abnormal expansion, not merely to identify known-bad content. In practice, that means treating decompression as a controlled operation with explicit limits, not as a routine convenience step.

Practitioner takeaway: The safest posture is to assume that any untrusted archive can become expensive the moment it is opened, and to bound that cost before extraction ever begins.

Related resources from NHI Mgmt Group

• How should security teams prevent Zip Slip vulnerabilities in archive import features?
• What breaks when ZIP extraction does not validate file paths correctly?
• Who is accountable when a ZIP import flaw leads to server compromise?
• Who is accountable when a public Apache HTTP Server instance is left vulnerable to HTTP/2 bomb attacks?