| Both sides previous revision Previous revision | |
| meta:verdict [2026/09/12 02:14] – external edit 127.0.0.1 | meta:verdict [2026/09/12 02:17] (current) – external edit 127.0.0.1 |
|---|
| ====== The Reachability Verdict ====== | ====== 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. | Every CVE page here gets one of four verdicts. They describe how far I actually got with the bug, not how bad it would be in the worst case. |
| |
| 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. | CVSS scores a hypothetical. A 9.8 assumes the attacker is already in a position to use it, and most of the time getting into that position is the whole problem. |
| |
| ===== Theoretical ===== | ===== Theoretical ===== |
| |
| The bug is real. The code is genuinely wrong. I just couldn't find anywhere an actual attacker could stand to reach it. | The bug is real but I couldn't 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. | Usually that means the vulnerable function is only called from somewhere an attacker can't get to. An installer that runs once during setup. A parser behind a config option that defaults to off. A path that requires you to already be an administrator, in which case the CVE describes an admin doing something admins can do anyway. |
| |
| 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. | The preconditions go on the page. If your environment meets them then the verdict doesn't apply to you, and you should patch. |
| | |
| 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. | |
| |
| ===== Reachable ===== | ===== Reachable ===== |
| |
| 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. | Attacker-controlled input gets to the vulnerable code on a default install. |
| |
| 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. | I need to be able to demonstrate it, usually with a breakpoint on the vulnerable function and my input sitting in the arguments. Getting there is not the same as doing something with it. Validation further down, an exception handler, or the value just not being useful enough will all stop a reachable bug from going anywhere. |
| |
| 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. | Most of my pages end up here. The path exists, the bug is real, and I haven't turned it into anything. |
| |
| ===== Exploitable ===== | ===== Exploitable ===== |
| |
| 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. | I got the bug to produce the effect its class implies. A crash with a controlled value, memory disclosure, command execution, an arbitrary file read. |
| | |
| 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. | These are lab results and the conditions matter, so they go on the page. Usually it is one version at one patch level with mitigations disabled and a payload built against that specific binary. Reliability is often bad. I'll say what it was. |
| |
| ===== Weaponized ===== | ===== Weaponized ===== |
| |
| 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. | The same, except it works against a stock install without me knowing anything about the specific target, and it works more than once. |
| |
| 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. | I don't get here often. When I do the page gets shorter rather than longer. You get the bug class, affected versions, the patch, and how I reasoned about it. You don't get working code. Everything here is patched and public before I publish, though that isn't the same as everyone having applied it. |
| |
| ===== On the ratings ===== | ===== On the ratings ===== |
| |
| This is my read, not a standard. Nobody ratified it, there's no working group, and I'll get some of them wrong. | This is my own scale and nobody else uses it. |
| |
| 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. | It also measures how hard I looked, and that varies. Theoretical can mean the bug is genuinely unreachable, or it can mean I spent an afternoon on it and stopped. I try to say which one. If you have a path to something I marked Theoretical, tell me and I'll update the page. |
| |