Why would a reliable hypervisor escape stay unpublished and unpackaged for years?

## The ladder describes publication, not existence Every rung of the weaponisation ladder is a **publication event**. Somebody decided to make something public. That means the ladder is filtered through the incentives of whoever paid for the work, and for the most valuable capability classes those incentives point firmly away from publishing. A reliable escape from a guest virtual machine to the hypervisor is close to the top of that list. It crosses a boundary that an enormous amount of architecture treats as solid — cloud multi-tenancy, malware analysis environments, segregated build infrastructure, regulated workload separation. Building one takes sustained specialist effort against a small, heavily audited attack surface, and turning it from a fault into a repeatable escape is harder still. ## The economics of not publishing Look at what the holder gets from each choice. **Publish.** Reputation, conference talks, hiring leverage, and the flaw gets fixed. This is a genuinely good trade for an independent researcher or a vendor security team, and it is why most flaws do become public. **Sell.** There is a real market: acquisition programmes, brokers who aggregate capabilities for government clients, and vendors who build interception products. Capability classes that cross the strongest boundaries — hypervisor escape, full remote chains against hardened mobile platforms — sit at the very top of published price ranges precisely because they are scarce and because nothing else substitutes for them. **Use.** A capable operator may value having the thing more than either money or credit, and every use risks losing it. For anyone in the second or third category, publishing is pure destruction of value: the moment it is public, it gets fixed, and the asset they paid a great deal for is gone. Packaging it into a public framework is that same destruction, done more thoroughly and to a wider audience. So capabilities routinely **stall at rung 3** — a reliable exploit exists, is known to a handful of people, and is never packaged, never published, sometimes never even hinted at. ## Rungs get skipped, and rungs get skipped invisibly The tidy four-step story — flaw, crash, reliable exploit, tooling — is what happens when the finder wants credit. Other paths are common: - Private reliable exploit first, public advisory only after somebody catches it in use. The public ladder starts at rung 1 *after* the capability has already been used for months. - Vendor patch with no public detail, no proof of concept ever, and quiet reconstruction by whoever cares enough to diff the fix. - Capability built, held, made obsolete by an unrelated refactor, and never disclosed at all. Nobody outside the holder ever knows it existed. None of those produce the sequence you would draw on a whiteboard, and only the first ever becomes visible. ## What "no public exploit" therefore licenses you to claim Precisely one thing: **the commodity population cannot currently attack you through this flaw.** That is a real and useful statement. Indiscriminate mass exploitation needs the low rungs; if they do not exist, the sweeping-the-internet attacker is not coming through this door today. What it does not tell you: - Whether a capable actor can exploit it. Their rung is invisible to you by construction. - Whether anyone is exploiting it right now. Targeted use against a small number of victims is the use case that most justifies keeping something private. - Whether it will stay that way. Private capabilities become public on somebody else's schedule. The failure mode this question exists to catch is treating the ladder as a measurement of the world instead of a measurement of what has been posted. A candidate who discounts a flaw's risk because "there's no public exploit" is making a claim about a market, not about the code — and against an adversary who can fund a hypervisor escape, that claim is worth very little. ## Saying it well under questioning Frame the discount by the population it bounds, not by probability. "No public exploit means opportunistic mass attack through this flaw is unlikely this week; it does not lower our exposure to anyone with a budget, and it is not evidence the flaw is unused." Then be explicit about what would change your mind: a reliable exploit appearing publicly, the same capability turning up in packaged form, or credible word that it is being used. That is a defensible position. "No public exploit, therefore low risk" is not, and an interviewer probing this leaf is usually probing exactly that sentence.