Why do decompression bombs create denial-of-service risk even without authentication?

Why decompression bombs cause denial-of-service before any login happens

A decompression bomb is dangerous because the service commits CPU, memory, disk, or worker time to processing a file before it knows whether the file is benign. The attacker is not trying to bypass the user interface, they are trying to force expensive work in the server’s file-handling path. That makes the risk about resource exhaustion, not authentication state.

Once the archive is handed to an automatic extractor, the parser may expand a tiny input into an enormous output, recurse through nested archives, or allocate buffers and temporary files long before any authorization decision would matter. In other words, the security boundary is crossed at ingestion and parsing, not at account login.

The practical consequence is that even anonymous endpoints can be exposed if they accept uploads, fetch remote files, preview attachments, or index content on receipt. If the service treats every file as something to be unpacked or inspected immediately, the attacker only needs a path to supply the content, not a valid session.

What makes the processing path the real attack surface

Decompression bombs exploit a mismatch between input size and processing cost. A small compressed object can expand into a very large in-memory structure or a large on-disk payload, and the decompressor may have to read enough of the file to discover that fact. That cost is paid by the server, so the attack can starve threads, exhaust storage, or trigger crash loops even when the source is unauthenticated.

The risk is highest where file handling is synchronous, where uploads are scanned inline, or where downstream services automatically render previews and thumbnails. A service can be perfectly strong at identity verification and still be vulnerable if it trusts file input too early. The key question is whether the system validates and bounds the work before full decompression begins.

Services that retrieve files from third parties face the same issue. If an application fetches an archive from a URL, webhook, or shared mailbox and then unpacks it automatically, the attack path starts as soon as that file enters the pipeline. Authentication to the user portal does not change the fact that the decompressor is now doing unbounded work on attacker-controlled content.

How to think about the control problem in practice

A decompression bomb is usually not defeated by access control alone. The right controls are size limits, recursion limits, timeouts, streaming validation, sandboxing, and hard caps on output expansion. The aim is to make decompression fail closed when expansion is disproportionate, rather than letting the file processor discover the problem only after resources are already consumed.

For teams operating upload or ingestion services, the key design decision is where to place the expensive parsing step. The safer pattern is to reject or quarantine obviously risky content first, then decompress in a constrained environment with explicit limits on output volume, nesting depth, and execution time. The more the service depends on automated extraction, the more important those bounds become.

Secrets exposure and parser abuse often become visible only after an attacker has already forced the server into high-cost processing, so the same control principle applies across file-handling and credential-handling paths: limit what one untrusted input can make the system do.

Risk and Threat Considerations

Decompression bombs create denial-of-service risk because they weaponize trusted processing, not trusted identity. The result can be worker exhaustion, storage depletion, queue backlogs, and cascading failures in any service that automatically inspects files at scale, including mail gateways, document processors, and security scanners.

Failure mechanism: The decompressor expands attacker-controlled content into disproportionate CPU, memory, or disk demand before the service can finish validation, so repeated requests can pin workers or crash the processing tier.

Impact: Availability drops, other requests are delayed or rejected, and a single unauthenticated file can become an effective denial-of-service trigger against shared infrastructure.

Practitioner Guidance

What to verify: Confirm that upload, preview, and ingest pipelines enforce explicit expansion limits, recursion depth limits, and execution timeouts before full decompression. If the control only checks file type after unpacking begins, the environment is still exposed.

What good looks like: The service can reject or quarantine a file based on bounded metadata and never lets one object consume an unbounded share of worker capacity. Constrained decompression should be observable, rate-limited, and isolated from the main request path.

Common mistake: Treating authentication as the main defense and assuming unauthenticated endpoints are the only concern. The real question is whether untrusted content can force expensive processing, regardless of who sent it.

Practitioner takeaway: For decompression bombs, availability is protected by controlling expansion cost, not by controlling who clicks upload.

Related resources from NHI Mgmt Group

• Why do service accounts and privileged roles create governance risk even when authentication is strong?
• Why do unsafe decompression paths create more risk than a routine denial of service issue?
• Why do large distributed denial of service attacks create operational risk even when no data is stolen?
• Why does denial of inventory create risk even without a traditional exploit?