Future TechnologyHow To Read A CVSS Score Without Getting It Wrong
Key takeaways
- A CVSS base score describes a vulnerability in isolation, not your exposure to it
- Attack vector, privileges required and user interaction move the score more than most people expect
- A 7.0 being actively exploited on an internet-facing box outranks a 9.8 sitting behind three layers of authentication
- Layer three checks on top of the score: is it in CISA's Known Exploited Vulnerabilities catalogue, is the service reachable from the internet, does it need authentication
Every security headline leads with a number. GitLab 9.4. Windows AFD 7.0. Oracle shipped 943 fixes in one cycle. Almost nobody explains what the number encodes, which is how teams end up patching the biggest digit first and leaving the thing that is actually being exploited running.
What a CVSS score actually measures
The base score is built from a handful of metrics, and each one is a question about the vulnerability in isolation.
The exploitability metrics
Attack vector asks where the attacker has to be: network, adjacent network, local, or physical. Network is the worst case and it pushes the score up hard.
Attack complexity asks whether the exploit works reliably or needs a race condition and a favourable wind. Privileges required asks whether the attacker needs an account first. User interaction asks whether somebody has to click something.
Scope asks whether the bug can reach beyond the component it lives in. A container escape changes scope. A crash inside one service usually does not.
The impact metrics
Confidentiality, integrity and availability, each rated none, low or high. Reading data, changing data, and stopping the service. A vulnerability that does all three at high, over the network, with no privileges and no user interaction, is how you get a 9.8.
Why the base score is a bad triage tool on its own
Here is the part that matters. The base score describes the vulnerability. It says nothing about you.
CVE-2026-68820, the Windows Ancillary Function Driver for WinSock elevation of privilege flaw, carries a 7.0. CVE-2026-19478, the GitLab GraphQL flaw, carries a 9.4 and needs no authentication at all. On paper the GitLab bug wins. In practice the answer depends entirely on whether you run a public GitLab instance, and whether the Windows flaw is already being chained on a machine that faces the internet.
Oracle's latest cycle makes the point at scale: 943 fixes, 262 in Fusion Middleware, 182 of them exploitable remotely with no authentication. No security team on earth tests 943 patches. The workable answer is triage, and triage needs more than a number.
The three checks that decide it
Run these in order, and hand them to a colleague who does not work in security.
First, is it in CISA's Known Exploited Vulnerabilities catalogue? Confirmed exploitation beats theoretical severity every time. It is also the basis for the tightening remediation clocks we covered in CISA's three day patch window.
Second, is the affected service reachable from the internet? An unreachable 9.8 is a scheduled task. A reachable 7.5 is this afternoon.
Third, does exploitation need authentication? Unauthenticated plus internet-facing plus known exploited is the combination that ends weekends.
Everything else queues behind those three, including a lot of high scores that will never be touched by anyone. This is the same reasoning that makes exposed operational technology so dangerous, which we explained in what a PLC is and why it matters for cybersecurity, and it is why supply chain compromises like the Shai-Hulud npm worm bypass the scoring conversation entirely.
One more layer if you want it
CVSS tells you how bad a bug could be. EPSS estimates how likely it is to be exploited in the next 30 days. Used together they are far better than either alone, and neither replaces knowing what you actually have running.
The score is a starting point. Your asset inventory is the answer.