CVSS, KEV, and EPSS: Three Signals, Not One Answer

Security teams have no shortage of numbers, ratings, and red warning icons telling them what to patch.

CVSS gives us a severity score. CISA maintains the Known Exploited Vulnerabilities catalog. EPSS gives us a probability.

Put all three on a dashboard and they can look like competing answers to one question: What should we fix first?

They aren't.

Each signal answers a different question. Confusing those questions can send a remediation team sprinting toward the wrong fire. Or at least toward the loudest smoke alarm.

Here's the short version:

• CVSS: How severe could this vulnerability be under a defined set of technical conditions?

• CISA KEV: Has CISA determined that the vulnerability has been exploited in the wild?

• EPSS: What is the estimated probability that exploitation activity will be observed in the next 30 days?

Those are three useful answers. None of them knows whether you run the affected product, whether an attacker can reach the vulnerable function, or what the system means to your organization.

That part is still your job.

CVSS: How Bad Could It Be?

The Common Vulnerability Scoring System provides a common language for describing the technical severity of a vulnerability.

CVSS 4.0 separates its metrics into four groups: Base, Threat, Environmental, and Supplemental.

1. The Base score describes characteristics intrinsic to the vulnerability.

2. Threat metrics can reflect conditions that change over time.

3. Environmental metrics let an organization account for its own situation.

4. Supplemental metrics add optional context, such as whether exploitation can be automated, recovery difficulty, safety impact, and provider urgency. They don't change the calculated CVSS score.

That distinction matters because the Base score is the number most people see. A high Base score can tell you that successful exploitation may have serious consequences. It doesn't tell you that attackers are exploiting the vulnerability, that your system is exposed, or even that your organization uses the affected software.

FIRST, the Forum of Incident Response and Security Teams, maintains CVSS and is explicit about this: a CVSS Base score measures severity, not risk.

Think of CVSS as an inspection of a defective lock. The inspection describes the defect, what an intruder may need to use it, and what could happen if the attempt succeeds. It doesn't tell you which building has the lock, who can reach the door, or what's behind it.

CVSS is important. But severity alone doesn't tell you what to fix first.

CISA KEV: Has Someone Used It?

CISA's Known Exploited Vulnerabilities catalog identifies vulnerabilities for which there is reliable evidence of exploitation in the wild.

KEV is not a forecast. It means the vulnerability has crossed an important line from possible to observed.

CISA uses three criteria for adding a vulnerability: it has a CVE identifier, there is reliable evidence of active exploitation, and there is a clear remediation action such as an update or mitigation.

That makes KEV one of the strongest urgency signals available to defenders. If a vulnerability affecting a product you use appears in KEV, find out where that product is running and how exposed it is. Quickly.

KEV still doesn't know whether the affected function is reachable in your environment, whether a compensating control blocks the attack, or whether the system runs payroll or displays the lunch menu.

Known exploitation changes the conversation. It doesn't finish it.

CISA isn't the only organization maintaining a known-exploited-vulnerability catalog. VulnCheck operates a broader KEV dataset intended to identify exploitation earlier, with supporting references for its listings. ENISA also maintains an EU KEV Catalogue focused on vulnerabilities exploited in attacks targeting entities within the European Union. These catalogs use different sources and inclusion criteria, so a vulnerability may appear in one before, or without, appearing in another. In this article, "KEV" refers specifically to CISA's catalog unless otherwise noted.

EPSS: What Are Attackers Likely to Try Next?

The Exploit Prediction Scoring System estimates the probability that exploitation activity for a published CVE will be observed in the next 30 days.

EPSS produces two values that are easy to confuse:

• Probability is the model's estimate of exploitation activity in the next 30 days. An EPSS score of 0.05 means 5%.

• Percentile is a relative ranking. A vulnerability in the 90th percentile has a higher EPSS probability than 90% of the vulnerabilities currently scored.

EPSS scores are recalculated every day. They can move when new information appears, including exploit code, security research, detection signatures, or changes in attacker activity.

That's a feature, not a rounding error.

EPSS doesn't measure damage. It doesn't know whether you're affected. And it isn't a complete risk score. FIRST also warns against multiplying EPSS by CVSS and calling the result risk. The math looks tidy. The meaning isn't.

EPSS is most useful when teams have thousands of findings and need help identifying vulnerabilities that may attract attacker attention before exploitation is confirmed in KEV.

One Vulnerability, Three Signals

Consider CVE-2026-87902, a vulnerability in WordPress Core.

An unauthenticated attacker can manipulate WordPress page-template resolution so the application includes a readable local PHP file outside the active theme directory. Under specific theme, server, and PHP conditions, that can lead to remote code execution.

WordPress fixed the issue in version 7.1.2 and backported fixes to older release branches.

Now look at the three signals.

CVSS

The vulnerability has more than one published CVSS score because the scores use different versions of the standard:

• CVSS 3.1: 8.1, High

• CVSS 4.0: 9.2, Critical

That isn't a contradiction. The two versions use different metric structures. A score without its CVSS version and vector is incomplete information.

Both scores tell us the potential technical impact is serious. Neither proves exploitation.

KEV

CISA added the vulnerability to KEV on September 25, 2026, after exploitation was observed in the wild.

CISA's KEV listing tells us that exploitation is no longer theoretical. This is the point where debating whether 8.1 is less alarming than 9.2 becomes an excellent way to spend time while someone else attacks the server.

If you run an affected version, determine where it is and whether the vulnerable path is reachable.

EPSS

FIRST's EPSS API reported the following on October 31, 2026:

• EPSS probability: 95.769%

• EPSS percentile: 99.872%

Those figures are a dated snapshot. Readers who check later may see different values because EPSS is recalculated daily.

In this case, KEV already gives us direct evidence of exploitation. EPSS still helps describe how strongly the model ranks the vulnerability, but it doesn't make the KEV evidence more confirmed. Confirmed is already confirmed.

The Same CVE Doesn't Create the Same Risk Everywhere

Assume an organization finds the affected WordPress version on three systems:

1. A public website that processes customer information.

2. An intranet site reachable by employees and other internal systems.

3. A lab server that contains no important data and is accessible to only a few internal employees.

All three systems have the same CVE, the same public CVSS scores, the same KEV status, and the same EPSS score.

Their risk isn't the same.

The public server gives attackers the broadest opportunity to reach the vulnerable application. It also supports an important service and handles sensitive information. Investigate and remediate it immediately.

The intranet server has less direct exposure, but "internal" doesn't mean "safe." A compromised laptop, stolen credentials, or an attacker already inside the network may provide a path to it. Its reachability, data, and connections to other systems still matter.

The lab server still needs attention, but the organization has more options. It may be possible to shut it down or isolate it while production systems are fixed first.

And if the organization doesn't run WordPress at all, this vulnerability isn't in its environment. A scary score can't compromise software you don't have. Inventory occasionally gets to be the hero.

I covered the broader prioritization process in How to Prioritize Vulnerability Remediation (Without Losing Your Mind). The important point here is narrower: CVSS, KEV, and EPSS describe the vulnerability and attacker activity. Your environment determines what those signals mean for you.

Where EPSS Adds Something Different

EPSS becomes especially useful when a vulnerability isn't in KEV.

CVE-2026-73034, for example, affects DB-GPT, an open-source platform for building data applications and AI agents. The vulnerability could let an unauthenticated attacker write files outside the intended directory and potentially execute code.

The vulnerability has a CVSS 3.1 score of 9.8 and a CVSS 4.0 score of 9.3. Public proof-of-concept material exists. As of November 2, 2026, it was not listed in CISA's KEV catalog.

Those facts need careful wording. A public proof of concept is evidence that exploitation may be practical. It is not the same as reliable evidence that attackers are exploiting the vulnerability in the wild.

On September 27, 2026, FIRST reported an EPSS score of 5.703%, placing the vulnerability at about the 93rd percentile. That dated EPSS value doesn’t prove exploitation either. It tells a security team that the model ranked the vulnerability above most scored CVEs at that point in time.

If an organization operates an affected DB-GPT server exposed to untrusted users, the combination of high technical severity, unauthenticated access, public exploit material, and an elevated EPSS ranking deserves prompt investigation. If the affected service is offline in an isolated lab, the organizational response can be different.

This is where EPSS earns its place. It helps teams sort among vulnerabilities that haven't crossed KEV's evidence threshold.

Give Each Signal a Job

Don't force these signals to compete. Give each one a job.

Use CVSS to understand potential technical impact

Read the vector, not just the number. Confirm the CVSS version. Look at the attack requirements and the potential effect on confidentiality, integrity, and availability.

Use KEV to identify demonstrated attacker activity

If a vulnerability appears in KEV and you use the affected product, determine where it is, whether the vulnerable function is reachable, and what CISA or the vendor recommends.

Use EPSS to anticipate likely exploitation

Use EPSS to help sort vulnerabilities that aren't already known to be exploited. Record the date whenever you cite a score because tomorrow's score may be different.

Then add your environment

Ask five questions:

1. Do we run the affected product and version?

2. Can an attacker reach the vulnerable function?

3. What privileges or access would successful exploitation provide?

4. What data, systems, identities, or business processes are connected to it?

5. Can we patch, mitigate, isolate, monitor, or shut it down?

That is the difference between vulnerability data and a defensible decision.

Three Signals, Plus Your Context

1. CVSS measures technical severity.

2. KEV records known exploitation.

3. EPSS estimates near-term exploitation probability.

4. Your environment supplies exposure and business impact.

Use all four pieces.

The goal isn't to find one magic number that makes the decision for you. Security has enough magic numbers already.

The goal is to ask each source the question it was designed to answer, then decide which problem needs to be fixed first.