Why CVSS Scores Are Lying to Your Security Team (And What to Use Instead)

CVSS scores tell you how severe a vulnerability could be under worst-case conditions, not how likely attackers are to use it. Prioritizing by CVSS scores alone can send your team after the wrong fixes. Pairing them with EPSS, the CISA KEV catalog and SSVC gives a better view of real-world risk.

Why Prioritizing by CVSS Alone Falls Short

CVE submissions increased 263% between 2020 and 2025, according to NIST. Your patch management process probably addresses only part of the backlog each month. The question is not whether you can patch everything; you cannot. The question is whether the vulnerabilities you are prioritizing are the ones attackers are actually using.

The evidence says no. A CVSS-first model ranks vulnerabilities by theoretical severity, and the CVSS specification itself describes its output as input to a process that also considers factors outside CVSS. Organizations that rely on CVSS first risk fixing the wrong things first while vulnerabilities attackers are actually using wait in the standard queue.

This is not a critique of CVSS as a scoring system. CVSS does what it was designed to do: measure the theoretical technical severity of a vulnerability in isolation. The problem is that theoretical severity in isolation is not what attackers use to decide what to exploit. They use opportunity, tooling availability, target concentration, and the likelihood of success in real environments. The CVSS base score does not measure any of those things, and using it as the primary prioritization signal produces a systematic mismatch between what your team is fixing and what your adversaries are targeting.

The good news is that better signals exist. EPSS, the CISA KEV catalog, and threat actor activity intelligence each measure dimensions of risk that the CVSS base score does not, and using them in combination with CVSS gives a more complete view of the vulnerabilities attackers are actually using.

What Is CVSS and What Does It Actually Measure?

CVSS, the Common Vulnerability Scoring System, is a standardized framework for rating the severity of security vulnerabilities on a scale from 0.0 to 10.0. It was developed by FIRST (Forum of Incident Response and Security Teams) and is currently in version 4.0. It is the most widely used vulnerability scoring system in the industry and the primary input to most vulnerability management programs, scanner outputs, and patch prioritization workflows.

The CVSS base score is calculated from a set of metrics that describe the vulnerability’s intrinsic characteristics: how the vulnerability is accessed (network, adjacent, local, physical), what level of privilege is required to exploit it, whether user interaction is needed, whether the impact is confined to the vulnerable system or extends to subsequent systems, and the potential impact on confidentiality, integrity, and availability. The result is a score that reflects how damaging the vulnerability could be if it were successfully exploited under the conditions it was designed for.

That conditional clause is the source of most of CVSS’s practical limitations. The base score measures severity under theoretical conditions. It does not measure the probability that those conditions will be met in the real world, whether exploit code is publicly available, whether attackers are actively targeting the vulnerability, whether the affected component is reachable in any given environment, or whether a threat actor group relevant to your industry has incorporated it into their toolkit.

What Are the Four Problems With Prioritizing by CVSS Scores?

Problem 1: CVSS Scores Do Not Predict Exploitation

The most important limitation of CVSS is the one that matters most operationally: a high CVSS score does not by itself tell you whether a vulnerability will be exploited in your environment or any environment.

The CVSS specification describes the base score as reflecting intrinsic characteristics under reasonable worst-case impact. It does not describe the likelihood of exploitation. Vulnerabilities with CVSS scores in the medium range (4.0 to 6.9) can still be exploited, and a high score does not guarantee any attacker interest. The Plex2Shell chain in Plex Media Server is a 2026 example. Three of its four CVEs score Medium in CVSS v3.1, from 4.3 to 6.5. Chained, they give remote code execution, and CISA lists all four as exploited.

The implication is that a team prioritizing by CVSS score alone may spend urgent remediation effort on vulnerabilities that attackers are not targeting, while deprioritizing some of the vulnerabilities attackers are actively using.

Problem 2: The NVD Is No Longer Scoring Most Vulnerabilities

NIST’s NVD program aimed to analyze all CVEs, adding details such as severity scores and product lists. On April 15, 2026, NIST changed its priorities in response to a 263% rise in CVE submissions between 2020 and 2025. NVD now prioritizes CVEs in the CISA KEV catalog, CVEs for software used within the federal government, and critical software under US Executive Order 14028. NIST also said it will no longer routinely provide a separate severity score for CVEs already scored by their submitting authority.

Backlogged CVEs with an NVD publish date before March 1, 2026 were moved to the Not Scheduled category, meaning they are not immediately enriched. For organizations whose vulnerability management pipeline depends on NVD CVSS scores as the primary input, this is a structural data gap. Some published CVEs will arrive in scanner outputs with no NVD-sourced severity score.

This is not a temporary backlog problem. It is a change in how the NVD prioritizes its work, driven by a volume of CVE publication that has outpaced the resources available to score everything. Programs that have not built alternative prioritization signals into their workflow are now operating on an increasingly incomplete dataset.

Where a score is missing or late, the signals below fill the gap.

Problem 3: CVSS Scores Remain Static While Threat Landscapes Change

A CVSS base score, once assigned, does not change. A vulnerability that had no public exploit code and no observed attacker interest when it was first scored continues to carry the same score years later, even if a reliable exploit is later published, even if it is added to the CISA KEV catalog, and even if ransomware groups begin incorporating it into active campaigns.

This static nature means the base score cannot reflect the change in a vulnerability’s real-world risk profile over time. CVSS 4.0 does include Threat metrics, such as exploit maturity, that may change over time, but a score quoted from the Base metrics alone stays fixed. CVE-2024-4577, a critical PHP vulnerability with a CVSS v3.1 base score of 9.8 in its NVD record, was added to the CISA KEV catalog on June 12, 2024. The base score does not record that change, so a team reading only the score has no signal that the vulnerability moved from theoretical risk to confirmed exploitation. The reverse also happens: GitLab’s CVSS 10.0 regex compiler flaw, CVE-2026-110264, carried the top score but was not in the KEV catalog on 22 October 2026, so the score alone could not say whether anyone was exploiting it yet.

The inverse is also true. A vulnerability may carry a high CVSS score assigned at disclosure that never changes, even as the affected software version ages out of widespread use, compensating controls are widely deployed, and attacker interest moves elsewhere. The score is frozen at the moment of theoretical maximum risk, regardless of how that risk has evolved.

Problem 4: CVSS Scores Are Tied to Patching Engineering Time Rather Than Attacker Timelines

A CVSS-first queue orders work by severity, not by attacker behavior. Vulnerabilities with a high probability of exploitation can therefore wait in the standard queue while lower-risk vulnerabilities are fixed first. Teams can end up patching low-risk vulnerabilities faster than high-risk ones.

This is not irrational behavior. It is the predictable outcome of using CVSS severity as the primary queue signal. Low-risk vulnerabilities that happen to score high in CVSS get fast-tracked through patch cycles. High-risk vulnerabilities that score medium in CVSS wait in the standard queue. The queue is optimized for CVSS severity, not for attacker behavior, and the result can be a remediation pattern that is at odds with actual risk.

What Should You Use Instead of CVSS Scores? Three Signals That Reflect Attacker Behavior

Signal 1: CISA KEV (Known Exploited Vulnerabilities Catalog)

The CISA KEV catalog is the most operationally reliable prioritization signal available. CISA describes it as the authoritative source of vulnerabilities that have been exploited in the wild. As of October 2026, the catalog page lists 1,734 entries representing confirmed, real-world attacker activity rather than theoretical risk assessments.

Every vulnerability in the KEV catalog has been actively exploited. That is not a prediction or a probability. It is a documented fact. Any organization with a KEV entry in their environment should treat it as an immediate remediation priority regardless of the associated CVSS score.

The KEV catalog’s limitation is its retrospective nature: a vulnerability must already have been observed in exploitation before it can be added. It catches confirmed threats, not emerging ones. This is why KEV should be used as the first and highest-priority filter rather than the only filter.

Signal 2: EPSS (Exploit Prediction Scoring System)

EPSS is a data-driven machine learning model maintained by the EPSS Special Interest Group at FIRST that estimates the probability a given published CVE will be exploited in the wild within the next 30 days. The model is trained on exploitation telemetry from IDS and IPS systems, exploit code published on GitHub, dark web forum activity, proof-of-concept demonstrations, and CISA KEV additions.

EPSS outputs both a probability score between 0 and 1 and a percentile ranking against all other scored CVEs, published every day. The percentile is operationally important: an EPSS score of 0.1 (10% probability) sounds low in absolute terms, but if it places the vulnerability in the 95th percentile of all CVEs, it means this vulnerability is more likely to be exploited than 95% of all other known vulnerabilities.

A practical workflow is: triage by KEV first (binary, confirmed exploitation signal), then by EPSS percentile (probabilistic, focused on the highest-ranked CVEs for zero-day-equivalent urgency), and use CVSS only as a tiebreaker within those filtered sets. This approach narrows the urgent queue to vulnerabilities with actual evidence of exploitation or high exploitation probability, while keeping coverage focused on the threats attackers are using.

Signal 3: Threat Actor Activity Intelligence

EPSS and KEV both operate at the global, internet-scale level. They tell you what attackers across the internet are doing with a given vulnerability. Threat actor activity intelligence adds the dimension that neither provides: which threat groups are relevant to your specific sector, geographic region, and technology stack, and which vulnerabilities they are actively incorporating into their campaigns.

A vulnerability actively used by a threat actor group known to target financial services organizations in the EMEA region is a different priority for a bank in Germany than the same vulnerability is for a logistics company in Southeast Asia, even if both organizations see the same CVSS score and EPSS probability. Threat actor intelligence contextualizes the global signal to your specific threat landscape.

This signal also provides the earliest warning of emerging exploitation. Dark web forums and underground channels frequently surface discussions of vulnerability exploitation, initial access broker listings that reference specific CVEs, and ransomware group technical exchanges about new tools and techniques days or weeks before those activities appear in KEV or produce measurable EPSS movement. For organizations with access to this intelligence, it represents the forward-looking signal that both CVSS and KEV cannot provide.

How Do You Use These Signals Together in a Practical Framework?

The most effective vulnerability prioritization framework combines all four signals into a decision sequence that mirrors attacker decision-making rather than theoretical severity. The goal is to answer four questions about each vulnerability in your queue before deciding its remediation priority.

Vulnerabilities that do not meet any of the first three criteria can be addressed on a standard remediation schedule. Vulnerabilities that meet one or more criteria move to the fast-track queue regardless of their CVSS score. This is the practical implementation of what the research literature refers to as vulnerability management chaining, and it shrinks the urgent set to the vulnerabilities with evidence of exploitation or high exploitation probability while keeping coverage of the threats that matter.

Real-World Examples: When CVSS Gets It Wrong

How Brandefense Supports Risk-Based Vulnerability Prioritization

Brandefense’s threat intelligence capabilities address the signal gap that CVSS and even EPSS cannot fill: the specific threat actor activity that contextualizes global vulnerability data to your sector, your technology stack, and your threat landscape.