The Reachability Verdict

CVSS tells you how bad a bug would be if everything lined up. It doesn't tell you whether anything actually lines up. A 9.8 that needs a config nobody runs and credentials you'd never have is, in practice, a worse use of your afternoon than a 6.1 sitting on the front page of the login form.

So every CVE page here gets one of these four instead. They're about whether I could get to the bug, and what happened when I did.

The bug is real. The code is genuinely wrong. I just couldn't find anywhere an actual attacker could stand to reach it.

This is where most of the scary numbers go to die. The vulnerable function is only called from an installer that runs once. The bad parser is behind a config flag that ships off and nobody turns on. Or my personal favorite, the advisory says “authenticated remote attacker” and the authentication in question is administrator, which means the bug lets an admin do a thing admins were already allowed to do.

Theoretical is not me calling the vendor a liar. The patch is usually correct and you should still apply it. It means I followed the call graph and every path that reaches the bad code starts somewhere you'd already had to have won.

If the preconditions are strange but real, it stays Theoretical and I'll spell them out, so you can check whether you're the one shop on earth running it that way. Somebody always is.

Attacker-controlled data gets to the vulnerable code on a default install, and I can show it. A breakpoint that hits, a stack trace, a log line with my garbage sitting in it.

What I can't do yet is make it matter. The parser swallows my malformed input, execution walks straight into the bad memcpy, and then nothing interesting happens. Or it throws an exception that gets caught three frames up by something clearly written by a person who had been burned before.

This is the most honest rating on the list and the one I use most. The guardrail is missing and the road leads right to it, but I haven't driven off. Plenty of bugs sit here permanently. Some of them sit here because I got bored, and I'll say so on the page rather than dressing it up.

I made it do the thing it isn't supposed to do. Crash with a register I control, hand back memory that was never mine, run a command, read a file off disk. Whatever the bug class was advertising, it delivered.

Read the caveats, because there are always caveats. This is usually one VM at one patch level with mitigations turned down, a debugger attached, and a payload that only works because I know the exact build. It falls over if you look at it funny. I have written “Exploitable” on something with a 40% success rate, and the page said 40%.

The line between this and Reachable is impact, not elegance. Ugly and working beats clean and hypothetical.

Reliable, unattended, against a stock install, no debugger, no special knowledge of the target build. Point it, run it, it works, and it works again ten minutes later on a box I've never seen.

It is a high bar and I don't clear it often. When I do, the page gets noticeably thinner. You get the bug class, the affected versions, the patch, and the reasoning. You don't get the exploit, and asking nicely won't change it. Everything here is patched and public before it goes up, but “already patched” and “everybody has patched it” are famously not the same sentence.

This is my read, not a standard. Nobody ratified it, there's no working group, and I'll get some of them wrong.

The verdict is also a snapshot of how hard I looked. Theoretical sometimes means genuinely unreachable and sometimes means I spent an afternoon on it and gave up, and I'll tell you which one you're getting. If a page says Theoretical and you have a working path to it, tell me. I'll change it and put your name on it.