Gzip Bomb

How gzip bombs work

A gzip bomb is dangerous because decompression turns a compact input into a much larger in-memory or on-disk workload. The core issue is not the compressed file size itself, but the expansion ratio and the resources consumed while the data is unpacked.

That makes the term important anywhere compressed content is accepted automatically, especially in upload pipelines, email gateways, archive inspection tools, backup restore jobs, and application features that decompress user-controlled data before validation.

Why they are operationally dangerous

The failure mode is resource exhaustion. A decompressor may allocate memory, consume CPU, fill temporary storage, or stall request threads long before the final payload is fully materialised. In practice, that can degrade service for other users, trigger crashes, or create denial-of-service conditions inside an otherwise healthy application.

Compressed payloads are especially risky because simple file-size checks can miss the real blast radius. A small archive can hide an output volume that is orders of magnitude larger, so defenders must reason about decompressed size, expansion depth, and processing cost rather than trusting the compressed object alone.

Security teams should treat any automated decompression path as a trust boundary. If untrusted content is expanded before inspection, the decompression step itself becomes the attack surface.

Where exposure is usually checked

Exposure review starts with an inventory of places where gzip or archive handling exists, including web forms, API endpoints, mail relays, content scanners, ETL jobs, and internal automation. The key question is whether the system ever decompresses data that an external party can influence.

Teams should also look for internet-facing services that accept uploads, nested archives, or compressed request bodies. If those paths sit in front of shared infrastructure or high-availability services, a single decompression event can have a wider operational impact than the original file would suggest.

Vendor guidance, product defaults, and platform limits matter here because decompression guards are often implemented unevenly. Administrators should confirm what size ceilings, recursion limits, timeout controls, and sandboxing options the platform actually enforces rather than assuming protection exists by default.

Controls that reduce the blast radius

Effective controls focus on bounding work before decompression completes. Common safeguards include limiting input size, capping expansion ratio, restricting nested archive depth, applying CPU and memory quotas, and rejecting decompression jobs that exceed a processing threshold.

Safe designs also separate inspection from execution. A file can be scanned or queued in a low-privilege, resource-constrained environment before it is allowed anywhere near production storage or business logic.

NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it aligns decompression protection with configuration management, system integrity, and access control expectations for controlled processing paths.

Detection and review after suspected abuse

When a gzip bomb is suspected, defenders should look for abnormal decompression latency, worker saturation, rising memory pressure, temporary file growth, and repeated failures in services that normally handle compressed input. These signals often appear before a complete outage.

After an incident, review whether the application accepted the file without sufficient pre-checks, whether the decompressor logged expansion warnings, and whether the system retried the same payload in a way that amplified the load. The objective is to determine whether the issue was a one-off resource spike or a repeatable abuse path.

OWASP API Security Top 10 is relevant when compressed bodies or file-processing endpoints are exposed through APIs, because resource exhaustion and input handling weaknesses are often easiest to exploit there. NIST Cybersecurity Framework 2.0 also fits well at the program level because it frames the need to identify, protect, detect, respond, and recover from availability-impacting abuse.

Risk and Threat Considerations

Gzip bombs create a denial-of-service risk by turning a small, apparently harmless object into a high-cost processing event. The danger is greatest where decompression is automatic, shared across many tenants, or performed before the system has applied resource limits.

Failure mechanism: The attacker supplies compressed content that expands far beyond expected bounds, causing memory pressure, CPU exhaustion, disk saturation, or worker starvation during decompression.

Impact: Services may slow down, reject legitimate traffic, crash, or cascade into broader availability failures if shared processing resources are consumed.

Practitioner Guidance

Why practitioners should care: Treat decompression as an explicit security control point, not a background utility call. If the application can accept untrusted compressed input, then the decompressor must be designed and tested like any other externally reachable component.

What to watch for: Tighten size ceilings, expansion limits, and timeouts wherever compressed input is handled, and verify those limits in production paths rather than relying on library defaults. If nested archives or repeated decompression are possible, evaluate those paths separately because they often bypass simple file-size checks.

Practitioner takeaway: The safest pattern is to reject oversized expansion early and to process untrusted archives in a constrained environment before they can touch core services.

Related resources from NHI Mgmt Group

• Who is accountable when a public Apache HTTP Server instance is left vulnerable to HTTP/2 bomb attacks?
• What should security teams do first when bomb threat extortion emails start reaching employees directly?
• Why do bomb hoax extortion emails create risk even when the demand seems implausible?
• What happens when bomb threat extortion emails reach organizations that are not prepared to handle them?