A CVSS score gets treated in a lot of organisations as a single number that settles the argument — 9.8 means drop everything, 4.3 means it can wait for the next patch cycle. That's a misuse of what the score actually measures. CVSS Base Score is the intrinsic, environment-independent severity of a vulnerability — how bad it is in the abstract, not how much it actually threatens the systems you run today. Treating it as a finished risk verdict instead of an input to one is where most of the frustration with CVSS actually comes from, and it's usually a misunderstanding of the metrics themselves that causes it.
What the exploitability metrics actually measure
Four of the eight base metrics describe how easy the vulnerability is to actually exploit, and they're where a lot of scoring disagreements start because people eyeball them instead of reading the definitions closely.
Attack Vector (AV) is how close an attacker needs to be — Network (reachable from the internet), Adjacent (same broadcast domain or logical network segment), Local (needs local access to the machine), or Physical (needs to physically touch the device). This is the single biggest swing factor in a score: the same underlying flaw scored as Local instead of Network can be the difference between a 9-point and a 5-point base score, which is exactly why it's worth double-checking rather than defaulting to Network out of habit.
Attack Complexity (AC) is Low or High, and it specifically measures conditions outside the attacker's control that have to be true for the exploit to work — race conditions, specific configurations, information that has to be gathered first. It is not a measure of how technically sophisticated the exploit code is. A complex-to-write exploit that reliably works every time it's attempted is still Low complexity; a simple flaw that only works under a narrow timing window is High.
Privileges Required (PR) and User Interaction (UI) round these out: does the attacker need to already have some level of access before the attack works, and does a victim need to do something — click a link, open a file — for it to succeed. A vulnerability requiring zero privileges and zero user interaction is inherently more dangerous than a functionally similar one that needs an authenticated user to click something first, and the score reflects that directly.
Scope: the metric almost everyone gets wrong
Scope is consistently the most misapplied base metric, and misapplying it doesn't just shift the score a little — it changes which formula gets used to calculate it. Scope Unchanged (S:U) means the vulnerable component and the component that suffers the impact are the same security authority. Scope Changed (S:C) means exploiting the vulnerability lets the attacker affect resources beyond the vulnerable component's own security scope — a sandbox escape that reaches the host OS, a hypervisor guest that breaks out to affect the host, a browser plugin vulnerability that reaches beyond the browser's sandbox into the wider system.
The practical test: ask whether the vulnerable component and the impacted component report to the same authorization authority. If a flaw in application A can only ever damage application A's own data and users, Scope is Unchanged, no matter how severe the damage. If it lets an attacker cross into a different trust boundary entirely — a different application, the underlying OS, a different tenant in a multi-tenant system — Scope is Changed. Getting this wrong in either direction produces a genuinely incorrect score, not just a slightly-off one, because the base score formula treats Scope Changed vulnerabilities with a different, more punishing calculation specifically because "reaches beyond its own boundary" is a materially worse property for a vulnerability to have.
How the pieces actually combine into one number
The base score isn't a simple average of eight inputs — it's built from two sub-scores that get combined differently depending on Scope. The Impact sub-score comes from Confidentiality, Integrity and Availability (C/I/A), each rated None, Low or High, combined into a single Impact value. The Exploitability sub-score comes from Attack Vector, Attack Complexity, Privileges Required and User Interaction combined together. Impact and Exploitability are then added and capped at 10 — but when Scope is Changed, both the Impact calculation itself and the final combining formula use different multipliers specifically calibrated to push Changed-scope vulnerabilities higher for the same underlying C/I/A ratings, reflecting that cross-boundary impact is worse than same-boundary impact even when the raw confidentiality/integrity/availability damage looks identical on paper.
None of this needs to be done by hand — that's what a calculator is for — but knowing that Scope changes the actual formula, not just one input among equals, is what makes the difference between correctly identifying a Changed-scope flaw and quietly under-scoring something that deserves to be treated as more severe.
A concrete comparison: two 9.8s that aren't equally urgent
Take two hypothetical findings, both scoring 9.8: an unauthenticated remote code execution flaw in a public-facing web application with a working exploit already in circulation, and an unauthenticated remote code execution flaw in an internal admin panel that's never been exposed outside the corporate VPN, with no known exploit and no proof-of-concept published. The base metrics driving both scores can genuinely be identical — Network vector, Low complexity, no privileges required, no user interaction, High impact across confidentiality, integrity and availability. The base score doesn't distinguish them at all, and by design it isn't supposed to.
What actually separates them is entirely outside the base metric group: one is reachable from the internet right now and being actively exploited; the other requires VPN access that isn't available to an outside attacker and has no evidence of exploitation anywhere. Patch both — a 9.8 is a 9.8 for a reason — but the first belongs in an emergency change window today, and the second can reasonably go through a normal patch cycle within the week. A triage process that only looks at the base number treats these identically and either burns emergency-change budget on the internal finding or, worse, deprioritises the internet-facing one because "it's the same score as three other things already in the queue."
Why a 9.8 doesn't automatically mean drop everything
Base Score deliberately excludes two things that matter enormously for real prioritisation: whether the vulnerability is actually being exploited right now, and whether it applies to your specific environment. CVSS has metric groups for exactly this — Temporal metrics (exploit code maturity, whether a fix exists, confidence in the report) and Environmental metrics (how much the affected systems actually matter to you, and any compensating controls already in place) — and most organisations compute the base score and stop there, which throws away the parts of the standard actually designed for triage.
In practice: a 9.8 with no public exploit, no proof-of-concept, and a component that only runs on an internal, firewalled system is a real vulnerability that should get patched on a reasonable schedule — not a 2am page. A 7.5 with a working exploit already circulating publicly, actively being scanned for on the internet, hitting an internet-facing system you actually run, deserves faster action than the base score alone would suggest. This is exactly the reasoning behind approaches like CISA's Known Exploited Vulnerabilities list and exploit-prediction scoring — they exist because base severity and actual urgency are correlated but not remotely the same thing, and treating the base score as the whole answer skips the part of the analysis that determines whether something is actually on fire.