One cheap request that stops the product

Availability rarely fails to a flood of traffic; it fails to a single request that asks for far more work than it costs to make. A search with no upper bound, a report that scans everything, an upload with no size limit, a regular expression that backtracks, a nested payload that explodes when parsed. One request, cheap to send, can hold a worker, exhaust memory or lock a table long enough to stall the product for everyone else.

Why it happens

Inputs are validated for correctness, not for cost. A field checks that a number is a number, and never that it is below a sane maximum. Pagination defaults to a reasonable page size and lets the caller ask for a million. The expensive operation was written for the sizes seen in testing, and the size limit was never made explicit because ordinary use never reaches it.

How the attack unfolds

An attacker looks for the operation whose cost they control: the search that accepts any query, the export that has no row cap, the endpoint that parses whatever it is given. They send the largest, deepest, most expensive version the endpoint will accept, and repeat it just often enough to keep the workers busy. The product does not crash dramatically; it degrades, requests time out, and legitimate users are told to try again later.

It took two packets to crash a host that had been reviewed for twenty-seven years.The Record · OpenBSD, April 2026

Why review misses it

Every normal input works, so review and tests pass. The failure needs an input larger or deeper than anyone thought to try, and cost is not something a diff shows. The endpoint is correct for the sizes it was tested with, and silent about every size beyond them.