CVE vs. CVSS vs. EPSS Explained

Run a vulnerability scan against a reasonably sized environment and you can quickly end up with hundreds or even thousands of findings.

Some will be marked Critical. Others will be High, Medium, or Low. Many will have a CVE identifier, a CVSS score, and increasingly an EPSS score. Some may also appear in the CISA Known Exploited Vulnerabilities (KEV) Catalog.

At first glance, it can look like all of these numbers are trying to tell you the same thing.

They are not.

CVE, CVSS, and EPSS serve different purposes. CVE identifies a vulnerability. CVSS describes its technical severity. EPSS estimates the probability that the vulnerability will be exploited in the wild. KEV provides another important signal: whether a vulnerability is known to have been exploited.

Understanding that difference matters because vulnerability management is not simply a race to patch every vulnerability with the highest number.

A CVSS 9.8 vulnerability is not automatically the most urgent vulnerability in your environment. A CVSS 6.5 vulnerability may deserve immediate attention if it is exposed to the internet, affects a critical system, and has a high probability of exploitation. And if a vulnerability is already known to be exploited in the wild, that can change the priority again.

The goal is not to chase scores.

The goal is to understand risk.

What Is CVE?

CVE stands for Common Vulnerabilities and Exposures.

The simplest way to understand CVE is to think of it as a standardized identification system for publicly disclosed cybersecurity vulnerabilities.

A CVE identifier looks like this:

CVE-2021-44228

That identifier is associated with the Log4Shell vulnerability in Apache Log4j.

The important point is that the CVE identifier itself is not a severity score.

It does not tell you whether a vulnerability is Critical, High, or Low. It does not tell you whether attackers are currently exploiting it. It does not tell you whether the vulnerable software is installed in your environment.

It gives the vulnerability a standardized identifier that security products, researchers, vendors, vulnerability databases, and security teams can use when referring to the same issue.

Why CVE Exists

Imagine a security researcher discovers a vulnerability in a particular version of a software product.

The researcher might call it:

"Remote authentication bypass"

The vendor might call it:

"Security Issue #4821"

A security scanner might give it another internal identifier.

Another security company could use a completely different name.

That creates confusion.

The CVE system provides a common identifier that allows different organizations and security products to refer to the same vulnerability consistently.

This is particularly important when vulnerability information moves between different systems.

A vulnerability scanner can identify:

CVE-2026-XXXX

A threat-intelligence platform can use the same identifier.

A patch-management system can search for the same identifier.

A security team can use it when researching the vulnerability.

A vulnerability management platform can correlate all of those records.

That common language is one of the most important functions of CVE.

Who Assigns CVE IDs?

CVE IDs are assigned through the CVE Program, which uses authorized organizations known as CVE Numbering Authorities (CNAs).

MITRE plays a major role in the CVE Program, but it is incorrect to assume that every CVE is simply assigned directly by MITRE.

Many vendors and other authorized organizations operate as CNAs and can assign CVE identifiers for vulnerabilities within their assigned scope.

For example, a software vendor may assign CVEs to vulnerabilities discovered in its own products.

The important concept is the CVE ecosystem rather than a single organization assigning every identifier.

What a CVE Does Not Tell You

A CVE identifier answers one basic question:

"Which vulnerability are we talking about?"

It does not automatically answer:

• How severe is it?
• Is it exploitable?
• Is exploitation occurring right now?
• Is exploit code publicly available?
• Is the vulnerable product exposed to the internet?
• Is the affected system critical to the organization?
• Does your organization actually use the vulnerable configuration?
• How quickly should you patch it?

Those questions require additional information.

That is where CVSS, EPSS, threat intelligence, asset context, and other vulnerability-management signals become useful.

What Is CVSS?

CVSS stands for Common Vulnerability Scoring System.

CVSS is an open framework maintained by the Forum of Incident Response and Security Teams (FIRST) for describing and scoring the technical severity of vulnerabilities.

The current standard is CVSS version 4.0.

CVSS 4.0 was officially released by FIRST on November 1, 2023.

The system produces a numerical score from 0.0 to 10.0 and can also produce a qualitative severity rating such as:

• None
• Low
• Medium
• High
• Critical

The score is derived from a defined set of metrics rather than simply being someone's opinion.

But there is an important detail that is often missed:

CVSS Base Score represents severity, not complete organizational risk.

That distinction is extremely important.

CVSS 4.0: More Than Just One Number

CVSS 4.0 is divided into four metric groups:

1. Base
2. Threat
3. Environmental
4. Supplemental

These groups provide different types of information.

1. Base Metrics

The Base group describes the intrinsic characteristics of the vulnerability.

These characteristics are intended to remain relatively consistent regardless of where the vulnerable product is deployed.

CVSS 4.0 Base metrics include:

Attack Vector (AV)

Attack Vector describes how the vulnerability can be reached.

Examples include:

• Network
• Adjacent
• Local
• Physical

A vulnerability that can be exploited remotely over a network can generally have greater exposure than one requiring physical access.

However, the metric itself is not a statement that "Network automatically means dangerous."

The complete set of metrics determines the resulting score.

Attack Complexity (AC)

Attack Complexity describes conditions outside the attacker's control that must be satisfied for successful exploitation.

A vulnerability with Low Attack Complexity is generally easier to exploit under the defined conditions than one requiring High Attack Complexity.

Attack Requirements (AT)

Attack Requirements are a notable addition in CVSS 4.0.

They describe whether successful exploitation depends on a specific deployment or operational condition that must exist.

This helps CVSS distinguish vulnerabilities that are straightforward to exploit from those that depend on particular circumstances.

Privileges Required (PR)

Privileges Required describes the level of privileges an attacker must have before exploiting the vulnerability.

A vulnerability requiring no privileges is generally more exposed than one requiring significant privileges.

User Interaction (UI)

CVSS 4.0 changed the way User Interaction is represented.

It distinguishes between:

• None
• Passive
• Active

This provides more detail than the older CVSS 3.x model.

For example, an attack may require a victim to perform an action, or it may only require the victim to receive or process something without consciously taking an action.

CVSS 4.0 Impact Metrics

CVSS 4.0 also considers the impact of successful exploitation.

The impact metrics are divided into impacts on the vulnerable system and impacts on subsequent systems.

Vulnerable System Confidentiality (VC)

This considers the impact on confidentiality of the vulnerable system.

In simple terms:

Could exploitation expose sensitive information?

Vulnerable System Integrity (VI)

This considers the impact on the integrity of the vulnerable system.

Could an attacker modify important information or system data?

Vulnerable System Availability (VA)

This considers the impact on availability.

Could exploitation cause the affected system or service to become unavailable?

Subsequent System Confidentiality (SC)

This considers confidentiality impact on systems beyond the directly vulnerable component.

Subsequent System Integrity (SI)

This considers integrity impact on subsequent systems.

Subsequent System Availability (SA)

This considers availability impact on subsequent systems.

This distinction is useful because a vulnerability can sometimes compromise one component and then affect another system or security boundary.

CVSS Threat Metrics

CVSS 4.0 also contains a Threat metric group.

Threat information can change over time.

For example, a vulnerability may initially have no publicly known exploitation information. Later, proof-of-concept code may become available. Eventually, exploitation may be observed in the wild.

CVSS 4.0's Threat metrics are designed to capture this changing information.

One important metric here is Exploit Maturity.

It can account for the maturity of exploitation information, including whether exploitation techniques or proof-of-concept material are available.

This is one reason it is misleading to describe CVSS simply as "one permanent number."

The Base Score describes intrinsic severity, while additional metric groups can provide more context.

CVSS Environmental Metrics

The same vulnerability can have very different consequences depending on where it exists.

Consider two companies with the same vulnerable software.

Company A has the vulnerable system:

• isolated from the internet,
• protected by multiple security controls,
• used for testing,
• containing no sensitive information.

Company B has the same vulnerable software:

• directly exposed to the internet,
• connected to production databases,
• handling sensitive customer information,
• used by a critical business process.

The underlying vulnerability has not changed.

The organization's risk has.

CVSS 4.0 provides Environmental metrics to account for characteristics specific to the consumer's environment, including factors such as security requirements and mitigations.

This is a major reason why organizations should not blindly treat a vendor-provided Base Score as their final risk decision.

CVSS Supplemental Metrics

CVSS 4.0 also introduced Supplemental metrics.

These provide additional information about characteristics of a vulnerability without changing the core CVSS score in the same way the Base, Threat, and Environmental groups do.

Examples include characteristics related to:

• Automatable exploitation
• Recovery
• Value Density
• Vulnerability Response Effort
• Provider Urgency

Additional supplemental information can help security teams understand how a vulnerability behaves and how difficult remediation may be.

CVSS Is Not a Risk Score by Itself

This is probably the most important CVSS concept to understand.

A CVSS Base Score of 9.8 does not mean:

"Your organization has 9.8/10 risk."

It means the vulnerability has a high technical severity under the CVSS scoring methodology.

FIRST explicitly distinguishes CVSS Base severity from organizational risk.

Real risk depends on more than the vulnerability itself.

You also need to consider things such as:

• Whether the vulnerable software is actually deployed
• Whether the vulnerable version is present
• Whether the system is internet-facing
• Whether authentication is required
• Whether compensating controls exist
• Whether sensitive data is involved
• Whether the affected asset is business-critical
• Whether exploitation has been observed
• Whether reliable exploit code exists
• Whether the vulnerability is included in KEV
• How quickly the organization can remediate it

This is where vulnerability management becomes more than simply sorting a spreadsheet by CVSS.

What Is EPSS?

EPSS stands for Exploit Prediction Scoring System.

It is maintained by the EPSS Special Interest Group at FIRST, with scores generated by Empirical Security and published freely to the community.

EPSS answers a different question from CVSS:

How likely is this vulnerability to be exploited in the wild in the next 30 days?

EPSS provides a probability between 0 and 1.

It can also be expressed as a percentage.

For example:

0.05 = 5%
0.50 = 50%
0.95 = 95%

The important word here is probability.

EPSS is a prediction.

It is not a guarantee.

It is also not a statement that exploitation is definitely happening right now.

EPSS Is Not the Same as Active Exploitation

This distinction is critical.

Suppose a vulnerability has an EPSS score of:

0.95

It would be reasonable to treat that as a strong prioritization signal.

But it would be incorrect to write:

"Attackers are actively exploiting this vulnerability."

The EPSS score alone does not prove that.

A 95% EPSS score means the model estimates a high probability that the vulnerability will be exploited in the wild during the specified prediction window.

To establish that exploitation is actually occurring, you should look for additional evidence.

That evidence might come from:

• CISA KEV
• Threat-intelligence reports
• Vendor security advisories
• Incident-response telemetry
• Honeypot observations
• Security research
• Exploit monitoring
• Network detection
• Endpoint telemetry

This distinction makes EPSS much more useful because you are using it for what it actually is: a predictive signal.

EPSS v5 in 2026

If you're reading this article in 2026, there is another important update worth knowing.

EPSS v5 began publishing scores on June 15, 2026.

FIRST states that EPSS v5 includes several changes, including:

• A general model refresh
• Updated exploit-code detection on GitHub
• An improved calibration step
• Integration of VulnCheck KEV data
• GitHub popularity metrics
• Other model improvements

This matters because EPSS is not a static scoring system.

The model is periodically updated as new data becomes available and as model performance changes over time.

So an EPSS score can change even when the underlying vulnerability itself has not changed.

That is normal.

It reflects changing evidence and model predictions.

How CVE, CVSS, and EPSS Are Different

The easiest way to remember the difference is:

CVE = Identification

CVSS = Severity

EPSS = Exploitation Probability

They are complementary rather than competing systems.

Consider a vulnerability:

CVE-2026-XXXX

The CVE tells you which vulnerability it is.

Suppose its CVSS Base Score is:

9.8

That tells you the vulnerability is technically severe.

Now suppose its EPSS score is:

0.03

That means the model currently estimates a relatively low probability of exploitation within the next 30 days.

Now imagine another vulnerability:

CVE-2026-YYYY

with:

CVSS = 7.5

and:

EPSS = 0.85

The second vulnerability has lower technical severity but a much higher predicted probability of exploitation.

That does not automatically mean the second vulnerability should always be patched first.

It means you have another important signal to consider.

The final decision depends on your environment.

Why CVSS 9.8 Should Not Automatically Come First

This is where many vulnerability-management programs become inefficient.

Imagine that your scanner produces these findings:

If your only rule is:

"Patch the highest CVSS score first."

You would start with A.

But that may not be the best risk decision.

D deserves serious attention because it combines:

• Internet exposure
• A high exploitation probability
• Potentially significant operational consequences

B may also deserve immediate attention.

C could be extremely important because it affects a critical production system.

A may still need remediation, but its lower EPSS and internal exposure could mean that it is not the most urgent item.

This is the difference between severity-based prioritization and risk-based prioritization.

What Is the CISA KEV Catalog?

Another important source of vulnerability-management information is the CISA Known Exploited Vulnerabilities Catalog.

KEV stands for Known Exploited Vulnerabilities.

The catalog focuses on vulnerabilities for which there is evidence of exploitation in the wild.

That makes KEV different from EPSS.

EPSS is predictive.

KEV is evidence-based in the sense that the catalog identifies vulnerabilities known to have been exploited.

This distinction is extremely useful.

Consider two vulnerabilities:

Vulnerability A

CVSS: 9.8
EPSS: 0.02
KEV: No

Vulnerability B

CVSS: 7.5
EPSS: 0.70
KEV: Yes

Even though Vulnerability A has the higher CVSS score, Vulnerability B may deserve substantially more urgent attention because exploitation is already known.

This is exactly why no single score should be treated as the complete answer.

CVSS vs. EPSS vs. KEV

These three signals answer different questions.

CVSS

How severe is the vulnerability from a technical perspective?

EPSS

How likely is exploitation in the wild within the next 30 days?

KEV

Is this vulnerability known to have been exploited in the wild?

These signals can complement each other.

For example:

High CVSS + low EPSS + not in KEV

could indicate a technically severe vulnerability that currently has less evidence of near-term exploitation.

Meanwhile:

Moderate CVSS + high EPSS + KEV

could represent a much more urgent operational threat.

Again, this does not create an automatic universal priority ranking. Your environment still matters.

A Better Way to Prioritize Vulnerabilities

A mature vulnerability-management program should look at multiple dimensions.

A practical model might consider:

1. Technical Severity

Start with CVSS.

Ask:

• How severe is the vulnerability?
• What is the potential impact?
• How difficult is exploitation?
• What access is required?

2. Exploitation Probability

Look at EPSS.

Ask:

• Is exploitation predicted to be likely?
• Is the EPSS score increasing?
• Is there evidence suggesting increased attacker interest?

3. Known Exploitation

Check KEV and other threat-intelligence sources.

Ask:

• Is exploitation already known?
• Has the vulnerability been observed in attacks?
• Are reliable exploit techniques publicly available?

4. Asset Exposure

Look at the actual affected system.

Ask:

• Is it internet-facing?
• Is it reachable from untrusted networks?
• Is it behind authentication?
• Is it isolated?
• Are compensating controls present?

5. Business Importance

Not every server is equally important.

Ask:

• Does the system support a critical business process?
• Does it store sensitive information?
• Does compromise affect customers?
• Could compromise provide access to other systems?

6. Existing Mitigations

A vulnerable system may have additional security controls.

For example:

• Web application firewall
• Network segmentation
• Access control
• Endpoint protection
• Application allowlisting
• Virtual patching
• Monitoring and detection
• Authentication controls

These controls may reduce practical exposure, although they should never be treated as a reason to ignore a vulnerability indefinitely.

A Simple Risk-Based Example

Suppose your vulnerability scanner finds two vulnerabilities.

Vulnerability A

CVSS: 9.8
EPSS: 0.01
KEV: No
Asset: Internal development server
Exposure: Limited
Business impact: Low

Vulnerability B

CVSS: 7.5
EPSS: 0.80
KEV: Yes
Asset: Internet-facing VPN appliance
Exposure: High
Business impact: Critical

Which should you investigate first?

Almost certainly B.

Not because 7.5 is higher than 9.8.

It isn't.

B deserves priority because the surrounding evidence indicates a much more immediate organizational threat.

The vulnerability is:

• Internet-facing
• Associated with known exploitation
• Predicted to have a high exploitation probability
• Affecting a critical system

Meanwhile, A is technically more severe but has much less evidence of immediate exploitation and affects a lower-value internal system.

This is what risk-based vulnerability management looks like in practice.

But EPSS Should Not Be Used Alone Either

There is another mistake worth avoiding.

Some organizations make the opposite mistake and start sorting everything purely by EPSS.

That is also flawed.

A vulnerability with a very high EPSS score does not automatically deserve the highest priority if:

• The vulnerable software is not installed
• The affected version is not present
• The vulnerable functionality is disabled
• The asset is isolated
• Strong compensating controls exist
• The affected system has little business importance

Likewise, a vulnerability with a low EPSS score should not necessarily be ignored if it affects an extremely critical system or creates severe consequences if exploited.

EPSS is one input into prioritization.

It is not a replacement for vulnerability analysis.

CVE, CVSS, EPSS and KEV in a Real Vulnerability Management Workflow

A practical workflow can look like this:

Step 1: Identify

Use CVE identifiers to establish exactly which vulnerabilities your scanners, vendors, and security tools are referring to.

Step 2: Understand Severity

Review the CVSS score and, where available, the underlying CVSS vector.

Do not blindly trust the number without understanding what produced it.

Step 3: Check Exploitation Probability

Review the current EPSS score.

A high EPSS score should increase attention, particularly when the affected system is exposed or important.

Step 4: Check Known Exploitation

Check whether the CVE appears in the CISA KEV Catalog and review other credible threat-intelligence sources.

Known exploitation should generally be treated as a strong prioritization signal.

Step 5: Check Your Environment

Determine whether the vulnerable product and affected version actually exist in your environment.

Then determine:

• Where it is deployed
• Who can reach it
• What data it handles
• What privileges it has
• Whether it is internet-facing
• What mitigations exist

Step 6: Prioritize

Combine the available information.

Do not simply sort a spreadsheet from 10.0 down to 0.0.

Step 7: Remediate or Mitigate

Apply the appropriate fix.

That may mean:

• Installing a security update
• Upgrading the vulnerable software
• Removing the vulnerable component
• Disabling the vulnerable feature
• Applying a vendor-recommended workaround
• Implementing a compensating control

Step 8: Verify

After remediation, verify that the vulnerability is actually resolved.

A patch-management system saying "installed" is not always sufficient.

A follow-up scan or validation should confirm that the vulnerable condition is gone.

Why the CVSS Vector Matters

One common mistake is to look only at:

CVSS: 9.8

and ignore the vector.

The vector provides the information behind the score.

For example, CVSS 4.0 vectors contain metrics such as:

AV
AC
AT
PR
UI
VC
VI
VA
SC
SI
SA

The vector allows another analyst to understand how the score was calculated.

This is important because two vulnerabilities with similar numerical scores can have very different exploitation characteristics.

For security professionals, the vector is often more informative than the headline number.

CVSS 3.1 Is Still Relevant

Although CVSS 4.0 is the current standard, you will still encounter CVSS 3.1 in vulnerability scanners, vendor advisories, security databases, and older vulnerability records.

That does not mean CVSS 3.1 is "wrong."

It is an older version of the standard.

CVSS 3.1 remains an important part of the vulnerability-management ecosystem, while CVSS 4.0 provides the current framework.

When writing vulnerability-management tooling or documentation, it is therefore important to record the CVSS version.

For example:

CVSS 3.1: 9.8

is not exactly the same thing as:

CVSS 4.0: 9.8

The version and vector matter.

Common Mistakes in Vulnerability Management

Mistake 1: Patching Everything in CVSS Order

A list sorted by CVSS is not a risk model.

It ignores important information about exploitation, exposure, and business context.

Mistake 2: Treating EPSS as Proof of Exploitation

EPSS is predictive.

A high score does not prove that attackers are currently exploiting the vulnerability.

Use KEV, threat intelligence, and telemetry to investigate actual exploitation.

Mistake 3: Ignoring Internet Exposure

A vulnerability on an isolated internal machine is not necessarily equivalent to the same vulnerability on an internet-facing system.

Exposure changes the practical risk.

Mistake 4: Ignoring Asset Importance

A vulnerability affecting a disposable test server is not automatically as urgent as the same vulnerability affecting a production identity server.

Context matters.

Mistake 5: Assuming "Not in KEV" Means Safe

KEV is an important signal, but absence from KEV does not mean a vulnerability is harmless or impossible to exploit.

It simply means that it is not currently represented in that catalog as a known exploited vulnerability.

Mistake 6: Treating Scores as Permanent

EPSS changes over time.

Threat conditions change.

Exploit availability changes.

Vulnerability information changes.

Your prioritization should therefore be revisited rather than treated as a one-time decision.

The Difference Between Severity and Risk

This is the concept that ties everything together.

Severity describes how bad a vulnerability can be under the scoring methodology.

Risk considers the likelihood and consequences of that vulnerability in a particular environment.

For example:

A critical vulnerability in an unused isolated system may represent less immediate organizational risk than a high-severity vulnerability in an internet-facing system that is actively being targeted.

That does not make the critical vulnerability unimportant.

It means the organization has to decide where limited remediation resources will reduce the most risk.

That is the purpose of prioritization.

A Practical Mental Model

If you work in vulnerability management, remember these four questions:

CVE

What vulnerability is this?

CVSS

How technically severe is it?

EPSS

How likely is exploitation?

KEV

Is exploitation already known?

Then ask the question that none of these systems can answer by themselves:

How does this vulnerability affect my organization?

That final question requires asset inventory, exposure information, business context, security controls, and organizational priorities.

CVE vs. CVSS vs. EPSS vs. KEV: Quick Comparison

These systems are not replacements for each other.

They work best together.

Final Takeaway

Vulnerability management becomes much easier to understand once you stop treating CVE, CVSS, EPSS, and KEV as different versions of the same score.

They answer different questions.

CVE identifies the vulnerability.

CVSS measures technical severity.

EPSS estimates the probability of exploitation.

KEV identifies vulnerabilities known to have been exploited.

And none of them, by themselves, tells you the complete risk to your organization.

The strongest vulnerability-management programs combine these signals with real information about their own environments.

A practical prioritization decision should consider the vulnerability's technical severity, exploitation probability, known exploitation, internet exposure, asset criticality, available mitigations, and potential business impact.

That is the difference between simply managing vulnerabilities and actually managing vulnerability risk.

A vulnerability scanner can give you a list of problems.

CVEs help you identify them.

CVSS helps you understand their severity.

EPSS helps you estimate which ones are more likely to be exploited.

KEV helps you recognize vulnerabilities for which exploitation is already known.

But your environment is what turns those facts into a real security decision.

The goal is not to patch the biggest number first. The goal is to reduce the most meaningful risk first.