Resource Exhaustion: the small file that eats the machine

A few kilobytes can expand into terabytes. In a model pipeline that auto-unpacks everything it downloads, a decompression bomb is a denial-of-service weapon, and the scanner inspecting it has to be hardened against the same trick.

Not every attack tries to steal from you. Some just want to knock you over, and the cheapest way to knock over a system that processes files it downloads is to hand it a file that costs almost nothing to send and an enormous amount to open.

The classic version is the decompression bomb. A compressed archive can be crafted so that a tiny file on disk expands into something gigantic in memory, sometimes terabytes from a few kilobytes, by exploiting how well repetitive data compresses. The archive looks harmless by size. Then a pipeline tries to extract it, the uncompressed contents balloon, and memory or disk is exhausted. The process dies, and if that process was a shared ingestion service, everything behind it stalls with it.

Model pipelines are an unusually good target for this, because they are built to unpack things automatically. A model hub, a CI cache, a serving platform that accepts uploads, these all take archives from outside and expand them without a human in the loop. That is precisely the condition a decompression bomb is designed to exploit. The cost asymmetry is the point: the attacker spends nothing, the defender spends everything.

There is a nastier nested form too, the archive that contains archives that contain archives. Each layer multiplies the expansion, so a naive scanner that dutifully recurses into every layer can be made to blow up just by trying to look inside. Which leads to the part of this class that is easy to forget.

The scanner is a target too

Here is the uncomfortable bit. A security scanner is, by definition, a program that opens hostile files on purpose. If it is not careful, it is the easiest thing in your stack to take down, because you have pointed it directly at the attacker's input and told it to dig in.

So defending this class is two jobs, not one. The obvious job is flagging archives whose expansion ratio is wildly out of line with anything a real model needs, so that downstream systems never try to extract them. The less obvious job, and the one that separates a demo-grade tool from a production one, is making sure the scanner itself cannot be detonated by the files it inspects. That means bounding how deep it will recurse, capping how much total data it will ever decompress in a single pass, and limiting the size of any chunk of embedded logic it tries to parse before it commits to parsing it. We keep the specific limits to ourselves, because publishing them just tells an attacker how to build a file that sits one notch under every cap. The principle is the one any hardened parser follows: never let untrusted input decide how much work you do.

A tool that does the first job but not the second is a liability. It will catch the bomb in the lab and then fall over the first time someone aims a zip-of-zips at it in production.

Why the ratio, not the size

People sometimes ask why size alone is not the signal. It is because size alone punishes honest large models and misses small clever bombs. A legitimate model can be genuinely enormous and decompress to roughly what you would expect. A bomb is small and decompresses to something absurd. The tell is the relationship between the two, the leverage, not the absolute number. A file that claims to be a few megabytes and intends to become a few hundred gigabytes has announced itself, regardless of how small it looked in the download.

What to do about it

If you run anything that auto-extracts uploads, put hard limits on decompressed size and recursion depth, and enforce them during extraction, not after. Stream, measure as you go, and abort the moment the math stops making sense.

And do not assume your scanner is immune just because it is a security tool. Ask whoever built it, or whoever sold it to you, what happens when you feed it a nested bomb. The answer tells you whether they built it for a slide deck or for the real internet.