Understanding CVSS Scores: Why a Critical Vulnerability Isn't Always Critical for You

Picture two vulnerabilities landing in your scanner report on the same Tuesday morning. Both are rated CVSS 9.8. Both say "Critical" in angry red text. Both, on paper, look like the kind of thing that should stop your sprint planning and pull your whole team into a war room.

One of them gets weaponized within 72 hours, shows up in ransomware playbooks, and lands on CISA's Known Exploited Vulnerabilities list before the week is out. The other sits quietly for the next three years. Nobody ever builds a working exploit for it. It never appears in a single incident report.

Same score. Wildly different outcomes. If you've worked in vulnerability management for more than a few months, you've already lived this story, probably more than once. It's the single most common source of friction between security teams and everyone else in the business: a number that says "drop everything" doesn't always deserve that reaction, and a number that looks unremarkable can occasionally be the one that burns you.

This isn't a flaw in CVSS. It's a misunderstanding of what CVSS was ever built to do.

1.1      What CVSS Actually Measures

The Common Vulnerability Scoring System, now in its fourth major revision since FIRST (the Forum of Incident Response and Security Teams) introduced it, was designed to answer one specific question: describe the technical severity of a vulnerability using a reasonable worst-case scenario, without taking a specific organisation's environment into account.

That's it. That's the whole job description. CVSS was built to be a standardized, vendor-neutral way of describing technical severity. It was never designed to tell you how likely an attack actually is, or how much damage it would do to your specific organization if it happened.

The Base score, the number everyone actually looks at, is calculated purely from the intrinsic characteristics of the vulnerability itself: how an attacker would reach it, how difficult the attack is to carry out, whether privileges or user interaction are needed, and what happens to confidentiality, integrity, and availability if it succeeds. None of that math knows or cares whether the vulnerable system sits on the open internet or in a locked server room nobody has touched since 2019.

CVSS 4.0, published in late 2023, tried to make this distinction harder to miss. It formally split the score into named combinations: CVSS-B is the base score alone, the one vendors publish in their advisories. CVSS-BT adds Threat information, such as the maturity of exploitation techniques. CVSS-BE and CVSS-BTE layer in Environmental metrics that let an organization adjust the score for their own deployment. The naming convention exists precisely because the industry kept quoting bare Base scores as if they were the final word on risk, when the framework itself always intended them to be a starting point.

1.2      The Gap, in Numbers

If you want proof that a high CVSS score and real-world danger aren't the same thing, the data is uncomfortably clear.

The broader exploitation base rate is surprisingly low. FIRST reports that, in any given 30-day window, roughly 2-3% of published CVEs are observed with exploitation activity. That doesn't mean the remaining vulnerabilities are harmless; it means that severity alone is a poor proxy for which vulnerabilities attackers are actually going to target

FIRST, which owns and manages CVSS and hosts the EPSS Special Interest Group, has published a direct comparison that makes the tradeoff explicit. If you remediate every vulnerability scoring 7 or higher on CVSS, you'll catch about 82 percent of the vulnerabilities that eventually do get exploited. Sounds great, until you realize that roughly 96 percent of the patching effort behind that number was spent on vulnerabilities that were never going to be exploited in the first place. Compare that to using EPSS, the Exploit Prediction Scoring System, a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild within the next 30 days. It uses vulnerability characteristics and threat-intelligence signals to estimate exploitation likelihood. Setting a threshold around the 10 percent mark on EPSS catches about 63 percent of exploited vulnerabilities, with dramatically less wasted effort chasing dead ends.

CISA's Known Exploited Vulnerabilities catalog, the closest thing the industry has to a confirmed "these are actually being exploited in the wild" list, currently sits at somewhere around 1,500 entries. That's a genuinely tiny slice of the total universe of published CVEs, hundreds of thousands at this point. FIRST estimates the KEV catalog represents roughly half a percent of all published vulnerabilities. In any given 30-day window, only about 2.5 to 3 percent of published CVEs show any observed exploitation activity at all.

None of this means EPSS is a silver bullet either, worth saying plainly since it's easy to swap one oversimplified number for another. Academic research tracking vulnerabilities that eventually landed in the KEV catalog found that only about 20 percent of them had an EPSS score above 0.5 before they were actually exploited, and more than a fifth had no EPSS score at all prior to exploitation. Prediction is hard. The point isn't that EPSS replaces CVSS. It's that neither one, alone, tells you what you actually need to know.

1.3      Exploitability Is a Moving Target

CVSS Base scores are designed to describe the relatively stable, intrinsic characteristics of a vulnerability. They aren't intended to continuously track changes in the threat landscape. Real-world exploitability is anything but stable. A vulnerability's danger level shifts constantly based on things no Base score can capture: whether working exploit code has been published, whether it's been folded into a widely used framework like Metasploit, whether a ransomware crew has started using it as an initial access vector, whether the vendor's patch is trivial to reverse-engineer into a proof of concept.

This is exactly the gap the old CVSS Temporal metrics, now rebranded as Threat metrics in version 4.0, were meant to fill, and exactly why tools like EPSS exist as a complement rather than a rival. A vulnerability that scored a modest 6.5 at disclosure can become genuinely urgent the moment a working exploit shows up on GitHub. A vulnerability that scored a terrifying 9.8 can stay theoretical forever if it turns out to be finicky to trigger reliably outside a lab environment. Attackers, like everyone else, tend to go after the vulnerabilities that are cheap and reliable to exploit at scale, not necessarily the ones with the scariest number attached.

1.4      Where You Run It Matters as Much as What It Is

Here's the piece that CVSS structurally cannot account for on its own: your environment.

A critical, remotely exploitable vulnerability in an internet-facing VPN appliance sitting in front of your production network is an entirely different animal from the identical vulnerability sitting in a decommissioned test instance behind three layers of network segmentation, with no route from the internet and compensating controls like MFA and egress filtering standing in the way. The CVSS Base score doesn't change between those two scenarios. Your actual risk absolutely does.

This is the idea behind asset context, and it's why frameworks like CISA's Stakeholder-Specific Vulnerability Categorization, or SSVC, exist alongside CVSS rather than instead of it. Built by Carnegie Mellon's Software Engineering Institute in collaboration with CISA, SSVC deliberately steps away from a single severity number and instead asks a small set of pointed questions: is this vulnerability currently being exploited anywhere, can the attack be automated at scale, what's the worst technical outcome if it succeeds, and how essential is the affected system to your organization's mission. Depending on the answers, SSVC sorts a vulnerability into one of four buckets, from Track (keep an eye on it) up to Act (drop what you're doing). Critically, the same CVE can land in completely different buckets depending on which system it's sitting on, which is precisely the nuance a bare CVSS score can't provide.

The questions worth asking about any given "critical" finding are the same ones a good incident responder asks instinctively: Is this asset actually reachable from outside? What does it have access to if it's compromised, and is that a path to something that actually matters, your customer database, your source code, your production credentials? Are there compensating controls already sitting in the way, network segmentation, a WAF rule, an EDR agent that would catch the post-exploitation behavior even if the initial exploit lands? And honestly, is anyone likely to bother?

A vulnerability in a niche piece of internal tooling that requires authenticated local access is a very different proposition from one in an edge device that every opportunistic scanner on the internet is already probing.

1.5      Putting It Together

None of this is an argument for ignoring CVSS. It's still the closest thing the industry has to a common language for describing technical severity, and for compliance purposes, contractual SLAs, and vendor communication, it's not going anywhere. The argument is against treating it as a complete risk assessment on its own, because it was never designed to be one. A more honest picture of risk looks something like three questions layered on top of each other. First, severity: what does CVSS say could theoretically happen? Second, likelihood: what do EPSS, threat intelligence and CISA KEV tell us about exploitation likelihood and observed exploitation activity? Third, and often the piece that gets skipped under deadline pressure, impact to you specifically: given where this vulnerability sits in your environment, what it's connected to, and what controls already stand in the way, does it actually threaten something that matters?

A critical CVSS score on an internet-facing system holding sensitive data, with a public exploit already circulating, deserves every bit of the urgency the red text implies. That same score on an isolated internal tool, with no known exploit and a mission prevalence of basically zero, deserves a calm conversation and a place in next month's patch cycle, not a 2am page.

The number was always meant to start the conversation, not end it. Treating it as the whole answer isn't rigor. It's just letting a spreadsheet make a decision that actually needs a human who understands the environment.