A single vulnerability advisory often carries several labels at once: CVE-2026-XXXXX, CVSS 9.8, EPSS 0.94, "added to KEV". Each comes from a different organization and answers a different question: which vulnerability is this, how severe is it technically, how likely is it to be exploited soon, and is someone already exploiting it. Treating them as interchangeable usually ends the same way: scarce patching effort goes to vulnerabilities with high scores that nobody is attacking, while the one that is actually being exploited slips through.

This article is for IT staff and managers who run vulnerability scans, schedule patches, or need to read security advisories. By the end you should be able to answer two questions about any vulnerability: does it affect us, and if so, how fast do we need to act?

CVE: an ID for each vulnerability

The mission of the CVE (Common Vulnerabilities and Exposures) Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities, with one CVE Record for each vulnerability[1]. IDs follow the format CVE-year-number, and their value is that a vendor bulletin, a scanner report, an advisory and an internal ticket can all point to exactly the same flaw.

The program is sponsored by the US Cybersecurity and Infrastructure Security Agency (CISA). A CVE Board oversees operations and strategy, the Secretariat (currently MITRE) maintains the program's infrastructure, and the actual work of assigning IDs and publishing records is done by partner organizations around the world called CVE Numbering Authorities (CNAs)[2]. Taiwan's TWCERT/CC is one of them: it assigns IDs within its vulnerability coordination role and publishes the related findings as TVN (Taiwan Vulnerability Note) advisories[3].

Two things to keep in mind when you see a CVE ID:

  • The ID says nothing about severity or whether anyone is exploiting the flaw. It only means the vulnerability has been formally registered.
  • CVE covers publicly disclosed vulnerabilities. Misconfigurations and weak passwords in your own environment, and flaws that have not been disclosed, will never appear in the CVE list. A scan report with no CVEs is not proof that a system is secure.

NVD no longer scores every CVE

Many people look up CVEs on NIST's National Vulnerability Database (NVD), which used to add CVSS scores and affected-product data to each record. In April 2026 NIST announced that, after CVE submissions grew 263% between 2020 and 2025, it would from April 15 prioritize enrichment of CVEs in the KEV catalog, software used by the US federal government, and critical software. Other CVEs are still added but marked lowest priority and not enriched right away, and NIST will no longer routinely issue a separate severity score when a CNA has already provided one[4]. In practice: a missing score on NVD does not mean a vulnerability is minor. Check the vendor's advisory or the score supplied by the CNA instead.

CVSS: technical severity, not risk

The Common Vulnerability Scoring System (CVSS) is maintained by FIRST. The current version, 4.0, was published in November 2023[5]. It turns the characteristics of a vulnerability into a score from 0 to 10 with qualitative ratings: 0.1–3.9 Low, 4.0–6.9 Medium, 7.0–8.9 High and 9.0–10.0 Critical[5].

Where the score comes from

CVSS 4.0 has four metric groups: Base, Threat, Environmental and Supplemental[5]. Base metrics describe the flaw itself, such as whether it can be triggered remotely over the network, whether the attacker needs an account, whether a user has to take some action, and the impact on confidentiality, integrity and availability. The specification asks that every score be labeled with the metrics it uses: CVSS-B for Base only, CVSS-BT with Threat, CVSS-BE with Environmental, and CVSS-BTE with all three[5].

What the score does not tell you

FIRST's user guide is explicit: Base scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk. They should be supplemented with an analysis of the environment and with threat information that changes over time, and only a CVSS-BTE score that includes both comes closer to "risk"[6]. Most scores published by vendors and public databases cover Base metrics only, so they cannot know:

  • whether the vulnerability is already being exploited;
  • whether the affected product exists in your company, or is exposed to the internet;
  • whether other controls you have in place already block the attack path.

You will also often see both a CVSS 3.1 score (the previous version) and a 4.0 score for the same vulnerability. The two versions use different metrics and formulas, so pick one version for your patching thresholds and always record which version and which metric combination a score refers to.

EPSS: probability of exploitation in the next 30 days

The Exploit Prediction Scoring System (EPSS), also maintained by FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It is expressed as a value from 0 to 1 and published every day for every CVE[7].

EPSS gives you two numbers that mean different things[8]:

  • Probability: the model's direct output. A value of 0.10 means an estimated 10% chance of exploitation activity within 30 days.
  • Percentile: how that probability ranks among all scored CVEs. Because most vulnerabilities have very low probabilities, a probability of just 0.10 already sits at about the 88th percentile, higher than roughly 88% of CVEs.

FIRST recommends showing both, for example "15.3% (92nd)", with the probability as the primary figure and the percentile as context. Percentiles shift if you only look at a subset of CVEs, such as those in your own environment; probabilities do not[8].

EPSS has clear limits. FIRST says it is not a severity score and not a complete risk score: it covers the threat likelihood component only, does not know what is in your environment or whether an attacker can reach it, and has no visibility into your asset inventory or compensating controls[9]. FIRST also warns against multiplying EPSS by CVSS to get a combined risk score. One is a calibrated probability and the other an ordinal ranking, so the product has no meaningful interpretation[9].

KEV: confirmed exploitation

CISA's Known Exploited Vulnerabilities (KEV) catalog adds a vulnerability when three criteria are met: it has a CVE ID, there is reliable evidence that it has been actively exploited in the wild, and there is a clear remediation action, such as a vendor-provided update[10]. In other words, KEV is not a prediction. It is a record of something that has already happened.

Under Binding Operational Directive BOD 26-04, issued in June 2026, US federal civilian agencies must remediate KEV vulnerabilities within set timeframes. The directive does not bind private companies, but CISA strongly recommends that every organization monitor the catalog and include a requirement to immediately address KEV vulnerabilities in its vulnerability management plan[10]. FIRST's EPSS guidance takes the same position: once a vulnerability is on KEV, treat it as actively exploited and prioritize it regardless of its EPSS score[9].

That is why KEV is the strongest "patch now" signal. CVSS tells you how bad the worst case could be, EPSS estimates the likelihood, and KEV tells you the attacks are already happening. Bear in mind that KEV only lists vulnerabilities with public evidence of exploitation and an available fix; absence from KEV does not mean a vulnerability is not being exploited.

Combining the four signals into a decision

Each indicator answers one question, and you need all four for a complete picture. A suggested order:

  1. CVE: do we have it? Compare the affected products and versions with your asset inventory. If nothing is affected, record that and close it.
  2. KEV: is it being exploited? If it is on KEV (or the vendor, TWCERT/CC or another authority reports active exploitation) and the affected system is internet-facing, treat it as an emergency: start patching or mitigation the same day and check for signs of compromise.
  3. EPSS: is exploitation likely soon? If it is not on KEV but its EPSS probability is high or rising quickly, schedule it for near-term patching. If you are used to filtering by CVSS "Critical", FIRST notes that roughly the 90th EPSS percentile (a probability of 0.04 or more) selects a similar number of vulnerabilities, which makes a reasonable starting point for the switch[9].
  4. CVSS: how bad is the impact? Use it to judge technical severity and scope, to rank items within the same priority level, and then adjust for your environment, for example whether the system is internet-facing or holds personal data or trade secrets.

For example, a CVSS 9.8 flaw that only exists on an internal test server and has a very low EPSS score should wait behind a CVSS 7.5 flaw on the company's SSL VPN that is already on KEV. Scores are only the starting point; whether someone is attacking, and whether attackers can reach the system, decide how urgent it is. To turn this into patching deadlines and a working process, continue with Patch management: how to prioritize when you can't fix everything.

Action checklist

  • In your vulnerability management tool or tracker, record for every finding the CVE, the CVSS score (with version and metric combination, such as CVSS-B 4.0), the EPSS probability and percentile, whether it is on KEV, and whether the affected system is internet-facing.
  • Compare new KEV entries with your asset inventory every day. CISA publishes the catalog as downloadable data files, so a simple script can do the matching.
  • When NVD has no score, use the vendor's advisory or the CNA's score (for products from Taiwanese vendors, check TWCERT/CC's TVN advisories). Never treat "no score" as "low risk".
  • Review vulnerabilities whose EPSS probability has risen sharply every week, especially on internet-facing systems.
  • In reports and tickets, do not just write "CVSS 9.8". Add "on KEV?" and "internet-facing?" so managers can judge urgency.
  • Do not multiply EPSS by CVSS to create a risk score, and do not simply patch in descending CVSS order.
  • Browse recent real-world cases under vulnerability advisories and practice ranking them with these four indicators, or subscribe to get updates as they are published.