Differences

This shows you the differences between two versions of the page.

--- meta:verdict [2026/09/12 02:07] – created - external edit 127.0.0.1
+++ meta:verdict [2026/09/12 02:17] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== 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, and that's the part I care about. So every CVE page here gets one of these four instead.
+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.
+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 =====
-The bug is real and the code is wrong, but I couldn't get to it from anywhere an attacker would actually be standing. Needs a configuration nobody runs, or a code path that got removed two versions back, or credentials that already own the box.
+The bug is real but I couldn't reach it.
+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.
+The preconditions go on the page. If your environment meets them then the verdict doesn't apply to you, and you should patch.
 ===== Reachable =====
-Untrusted input reaches the vulnerable code on a default install. I haven't made it do anything interesting yet, but nothing is standing in the way.
+Attacker-controlled input gets to the vulnerable code on a default install.
+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.
+Most of my pages end up here. The path exists, the bug is real, and I haven't turned it into anything.
 ===== Exploitable =====
-I got it to do the thing it isn't supposed to do. Crash, leak, execute, whatever the bug class promises. Usually in a lab, usually with a debugger open, usually held together with tape.
+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.
+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 =====
-It works reliably, unattended, against a stock install. This is the one I'm least likely to show you much of.
+The same, except it works against a stock install without me knowing anything about the specific target, and it works more than once.
+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 =====
-These are my read and not a standard, and I'll get some of them wrong. If a page says Theoretical and you have a working path to it, tell me and I'll change it.
+This is my own scale and nobody else uses 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.