What breaks when archive decompression has no output limits?

Why archive decompression becomes a denial-of-service problem

Archive formats are designed to compress repeated data efficiently, which means a tiny input can produce a much larger output once unpacked. When a parser accepts an untrusted archive without output caps, it gives the archive control over allocation pressure, disk growth, and CPU time. The failure is usually not a malformed file exception; it is resource exhaustion that can stall the host.

That is why decompression belongs in the same threat model as any other externally supplied workload. If the application expands archives synchronously, the attack can block request threads, saturate storage, and trigger cascading slowdowns in dependent services.

What actually fails first: memory, disk, or service availability

The first visible symptom depends on the implementation. Some systems stream decompressed data to disk until the filesystem fills; others buffer too much in memory and fail earlier with allocation pressure or garbage-collection churn. If the process keeps running, the host can still become unusable because CPU is spent inflating data rather than serving legitimate work.

In practice, the limiting factor is whatever resource the decompressor consumes fastest. That can mean file descriptors, temp space, worker threads, or a queue behind the parser, but the business outcome is the same: the service stops processing useful traffic.

Why output limits are a security control, not a convenience feature

Output limits turn decompression from an open-ended transformation into a bounded operation. A cap on total expanded bytes, per-file size, entry count, nesting depth, and wall-clock time constrains how much damage a single archive can cause before the parser aborts.

That control matters even when the archive is not obviously malicious. A legitimate-looking file can still hide a massive expansion ratio, and a parser that trusts compressed size alone has no reliable upper bound on actual resource consumption.

Risk and Threat Considerations

The core risk is an untrusted archive turning a routine preprocessing step into a cheap denial-of-service vector. Attackers prefer this path because the input is small, delivery is easy, and the defender pays the full expansion cost when the archive is opened.

Failure mechanism: The decompressor inflates data without a hard ceiling, so expansion ratio, recursion, or entry count drives uncontrolled CPU, disk, or memory use until the service stalls or the host runs out of resources.

Impact: The application can become unavailable, neighboring workloads may slow down, and automated jobs that depend on archive ingestion can backlog or fail repeatedly until cleanup and restart.

Practitioner Guidance

What to verify: Confirm that the archive handler enforces a maximum expanded size, per-entry size, total entry count, and a timeout for decompression. If any one of those limits is missing, assume the control is incomplete.

Decision rule: If the archive comes from outside the trust boundary, decompress it in a sandboxed worker with bounded storage and a hard abort path, rather than inside the main request or batch-processing process.

Practitioner takeaway: Treat decompression as an input-driven resource consumer, not a passive file operation; the important question is whether the service can fail closed before expansion itself becomes the attack.

Related resources from NHI Mgmt Group

• What breaks when a service processes untrusted archives without decompression limits?
• What breaks when humans verify AI output but do not own the workflow?
• What breaks when an AI assistant is connected to enterprise email and cloud systems without tight scope limits?
• What breaks when AI models can access sensitive data without output controls?