Flaws Needing No Exploit

## Two things get called "an exploit" One is a *weakness* — the property of a system that lets something go wrong. The other is the *working attack* — the concrete thing an adversary runs to make it go wrong on purpose. The distance between those two is not a constant. It is largely a property of the **weakness class**, and it is the most useful thing that class tells you. For a memory-safety defect, the distance is exploit development: weeks of specialist work that frequently fails. For a **missing authorization decision**, the distance is zero. The description of the flaw *is* the working attack. Reading the sentence "the export endpoint does not check which tenant owns the report" hands you everything you need. ## The worked case A SaaS product exposes a reporting export. An authenticated user requests report `84213` and receives the file. Two facts combine: - Report identifiers are sequential integers allocated across the whole platform, so a neighbouring number is very likely another customer's document. - The server verifies that the caller holds a valid session and stops there. It never asks whether the report belongs to the caller's tenant. A user of tenant A requests `84212` and is served tenant B's export. Notice what is *not* happening. The request is not malformed. The integer is in range and parses fine. The session is genuine — it is the attacker's own. No memory is corrupted, no parser is confused, no timing window is hit. The intended code path runs to completion and does precisely what it was written to do; what it was written to do is the flaw. ## What the attack costs the adversary Nothing they do not already have. No exploit-development capability, no target-specific research, no reliability engineering. And crucially, **no version dependence**: there is no memory layout, allocator state, compiler version or operating-system build standing between the description and the result, so the same three-second action works against every deployment of that product at once. It is also enumerable — each increment is another customer's document, so the flaw scales linearly with patience rather than with skill. That is why the market of people who can use this class of flaw is *everybody who can create an account*, while the market for a memory-corruption defect is the small set of people or crews who can fund exploit development. Distance to a working attack is, in practice, a statement about **which adversaries can afford you**. ## The classes that behave this way Weaknesses usable on reading share a shape: the system's decision logic is absent or wrong, and the input that triggers them is legitimate. - An ownership or tenancy check that was never written. - An identifier treated as if possessing it were proof of entitlement. - A multi-step workflow whose later step can be requested directly. - A function that was assumed unreachable because the interface does not offer a button for it. - A default left as shipped, granting more than anyone intended. Weaknesses on the far side of the scale need something built before they do anything: memory corruption, type confusion, a race window measured in microseconds, a cryptographic weakness that needs computation. ## Two things this is not **It is not a claim that the missing check is always more damaging.** Impact is a separate axis. Code execution on a server can be worse than reading one tenant's export. The point is that impact is what happens *if* someone gets there, and distance is *whether they can*. **It is not solved by making the identifier hard to guess.** An unpredictable identifier raises the cost of finding a target; it does not restore the absent authorization decision, and identifiers travel — through shared links, exports, and other endpoints that legitimately hand them out. The flaw is still that possession of a number is being accepted as entitlement. ## Why this matters for exposure For exploit-required classes, publication of a flaw and the existence of a usable attack are separated by real work, sometimes by months, sometimes forever. For this class they are the same moment. The instant the behaviour is described to anyone — in a bug report, in a public write-up, in a conversation at a conference — every account holder on the platform has been handed a working attack. There is no head start to plan around.