CVE, CVSS and CISA KEV Explained: How Vulnerabilities Are Scored and Prioritized
Every security advisory, scanner report and patch note leans on the same small set of public systems. CVE gives a vulnerability its name. CVSS says how bad it could be. EPSS estimates how likely it is to be attacked soon. CISA’s Known Exploited Vulnerabilities catalog (KEV) says it already has been. They are run by different organizations, answer different questions, and get confused with each other constantly. Anyone who has to decide what to patch first, or who reads that a flaw is “a 9.8”, needs to know what each number actually means. This page explains the pieces and how they fit together, as of October 2026, after two turbulent years in which the funding and staffing behind several of them nearly gave out.
CVE: the naming system
CVE (Common Vulnerabilities and Exposures) is a dictionary, not a database of fixes or scores. Its job is to give each publicly disclosed vulnerability one unique identifier so that a vendor advisory, a scanner, a news story and a patch can all refer to the same bug. The format is CVE-year-number, such as CVE-2021-44228 (Log4Shell). The year is when the ID was assigned or reserved, which isn’t always the year the bug became public, and the sequence number has had four or more digits since 2014.
A CVE record holds a short description, the affected products and versions, and references. It may also carry scores and weakness types, but those are additions, not the core.
IDs are issued by CVE Numbering Authorities (CNAs). These are vendors (Microsoft, Google, Red Hat), open-source foundations, national CERTs, bug bounty platforms and security firms that are authorized to assign IDs within a defined scope, usually their own products. Above them sit Roots, which recruit and supervise CNAs in a region or sector. MITRE runs the program as the top-level Root and Secretariat under a contract from CISA, the US Cybersecurity and Infrastructure Security Agency. A volunteer CVE Board, drawn from industry, government and academia, advises on policy.
Volume has grown fast. 48,185 CVEs were published in 2025, up from 39,962 in 2024, and 365 different CNAs assigned at least one. Much of the growth comes from more CNAs covering open-source projects and WordPress plugins, and lately from automated and AI-assisted bug hunting.
The 2025 contract scare and what followed
On April 15, 2025, a letter from MITRE leaked warning that its contract to run the CVE program would expire the next day. For a few hours it looked as if the system the whole industry uses to name vulnerabilities could stop issuing IDs. CISA exercised an 11-month option on the evening of April 15, keeping the program running into March 2026.
Three things came out of the scare.
First, a group of CVE Board members announced the CVE Foundation, a nonprofit meant to give the program a home that doesn’t depend on a single US government contract. Second, Europe accelerated its own infrastructure. ENISA, the EU cybersecurity agency, launched the European Vulnerability Database (EUVD) on May 13, 2025, as required by the NIS2 directive. The EUVD pulls in CVE records, vendor advisories, KEV data and national CERT alerts and adds its own exploitation status; it supplements CVE instead of replacing it. ENISA had been a CNA since January 2024 and became a CVE Root in November 2025. Luxembourg’s CIRCL separately launched GCVE, a decentralized numbering scheme. Third, CISA published a “vision” document on September 10, 2025, describing broader international participation and more diverse funding for the program.
The cliff never came back. In January 2026 the CVE Board was told there would be no funding gap in March, and the renewed arrangement reportedly moved the program onto a protected line in CISA’s budget. As of October 2026 MITRE still operates CVE under CISA sponsorship, with the governance debate unresolved but no longer urgent.
NVD and the enrichment backlog
The National Vulnerability Database, run by NIST, is a separate thing that people often mistake for CVE itself. NVD takes each CVE record and “enriches” it: it adds a CVSS score, a CWE weakness category, and CPE strings (Common Platform Enumeration, the machine-readable product names that let scanners match a CVE to software on your network). Without CPE data, many scanners simply can’t tell you that a CVE applies to you.
In February 2024 NVD’s enrichment slowed sharply, and the backlog of unprocessed CVEs grew into the tens of thousands. NIST blamed rising volume and reduced support; it brought in contractors and enriched about 42,000 CVEs in 2025, more than in any earlier year, and still fell further behind.
In April 2026 NIST stopped trying to enrich everything. NVD now enriches only CVEs that are in the KEV catalog, that affect software used by the federal government, or that fall under the “critical software” definition from Executive Order 14028. Everything else is marked “Not Scheduled,” including unenriched CVEs published before March 1, 2026. NVD also stopped adding its own CVSS score when the CNA has already supplied one. Organizations can still ask NVD to enrich a specific high-impact CVE.
The practical effect: NVD is no longer a complete source of severity scores or product matching. Teams increasingly rely on CNA-supplied scores, CISA’s Vulnrichment data (CISA adds SSVC decision points and some CVSS and CWE data directly to CVE records as an “authorized data publisher”), the EUVD, and commercial feeds.
CVSS: how severe could it be
The Common Vulnerability Scoring System, maintained by FIRST (the Forum of Incident Response and Security Teams), produces a score from 0 to 10 describing a vulnerability’s technical severity. It is built from a vector string of metrics: how the attack is delivered, how hard it is, what privileges and user interaction it needs, and what it does to confidentiality, integrity and availability.
| Score | Rating |
|---|---|
| 0.0 | None |
| 0.1 to 3.9 | Low |
| 4.0 to 6.9 | Medium |
| 7.0 to 8.9 | High |
| 9.0 to 10.0 | Critical |
CVSS v3.1 (2019) is still the most widely used version. Its familiar 9.8 is what you get for a network-reachable bug with low complexity, no privileges, no user interaction, and full impact on all three properties. v3.1 has a “Scope” metric for bugs whose impact crosses a boundary, such as a VM escape, and optional Temporal and Environmental groups that hardly anyone fills in.
CVSS v4.0 was released in November 2023 and fixes several known complaints:
- A new Attack Requirements metric captures conditions outside the attacker’s control (a race condition, a specific configuration), separate from Attack Complexity.
- User Interaction splits into Passive and Active, so “user visits a page” and “user clicks through a warning” score differently.
- Scope is gone. Impact is now recorded separately for the vulnerable system and for subsequent systems, which is clearer.
- Temporal metrics become Threat metrics, reduced mostly to Exploit Maturity.
- A Supplemental group adds context that doesn’t change the score, including Safety, Automatable and Recovery.
- New naming makes clear which parts were used: CVSS-B (base only), CVSS-BT (base plus threat), CVSS-BE, and CVSS-BTE.
The most important thing about CVSS is what it doesn’t measure. A base score describes the worst plausible technical impact, assuming the bug is reachable. It says nothing about whether anyone is exploiting it, or about how exposed your particular system is. Most published CVEs score High or Critical, and only a small fraction is ever exploited. Patching by CVSS base score alone means patching thousands of things in a random order relative to real risk.
EPSS: how likely is exploitation
The Exploit Prediction Scoring System, also run under FIRST, answers a different question: what is the probability that this CVE will see exploitation activity in the next 30 days? It is a machine-learning model trained on real exploitation data from sensors and partners, fed with features such as the vendor, the bug class, public exploit code, and mentions in security lists. Scores are published daily for every CVE, free, along with a percentile.
The two numbers need care. A probability of 0.10 sounds low but typically lands around the 95th percentile, because most CVEs score near zero. EPSS measures attempts that sensors observed, not successful compromises. And it is a forecast for the whole internet, not for your network. Log4Shell sits at 0.99999; a typical obscure plugin bug sits below 0.01.
CISA KEV: is it being exploited right now
The Known Exploited Vulnerabilities catalog is CISA’s list of CVEs with reliable evidence of active exploitation in the wild. It started on November 3, 2021. To be added, a vulnerability needs a CVE ID, evidence of exploitation, and clear remediation guidance such as a patch or mitigation. Each entry carries a date added, a due date for federal agencies, and a flag for known use in ransomware campaigns. As of October 1, 2026, the catalog held 1,731 entries, a tiny slice of the hundreds of thousands of CVEs ever published.
KEV began as the enforcement list for Binding Operational Directive 22-01, which ordered US federal civilian agencies to fix listed vulnerabilities by a set deadline, usually two weeks for newer CVEs. On June 10, 2026, CISA replaced it. BOD 26-04, “Prioritizing Security Updates Based on Risk,” revokes both BOD 22-01 and the older BOD 19-02 and sorts each vulnerability on four yes-or-no questions: Is the asset publicly exposed? Is the CVE in KEV? Is exploitation automatable? Does it give total control of the system?
| Situation | Deadline under BOD 26-04 |
|---|---|
| In KEV and gives total control | 3 days, plus a check for prior compromise |
| Publicly exposed, automatable, total control (even if not in KEV) | 3 days |
| Most other KEV entries | 14 days |
| Lower-risk combinations | 60 days |
| None of the four factors | Fix at the next scheduled upgrade |
Agencies had to update their processes by August 7, 2026, and must be working to the new timelines by December 7, 2026. In CISA’s testing at one large agency, about 1% of vulnerability instances landed in the 3-day tier and over 60% could wait for the next upgrade. KEV is still published and still central; it is now one input among four instead of the whole rule. The directive binds only federal civilian agencies, but KEV is used far more widely as a free, curated “patch this now” list.
How teams combine them
Mature programs use these signals in layers, roughly in this order:
- Is it in KEV, or otherwise confirmed exploited? Treat it as urgent, especially on anything internet-facing. KEV entries with the ransomware flag go first.
- Is the affected asset exposed and important? Your own context (internet-facing, holds sensitive data, runs authentication) matters more than any public score. Identity infrastructure deserves special weight; the ShinyHunters breaches show how much damage follows from one weak link in SSO and SaaS access.
- Is EPSS high, or is exploit code public? A high EPSS score or a working proof-of-concept moves a bug up even before it reaches KEV.
- What does CVSS say about impact? Use it to break ties and to understand what an attacker would get, not to set the order on its own.
CISA’s SSVC model (Stakeholder-Specific Vulnerability Categorization), which BOD 26-04 draws on, turns this kind of reasoning into a decision tree with outcomes like Track, Attend and Act. Many commercial tools now compute something similar.
Good asset inventory is the part no public feed can supply. A zero trust architecture assumes some of these bugs will be exploited before they’re patched and limits what an attacker can reach afterwards. Some vulnerabilities also live in protocols instead of products and never fit neatly into the patch cycle at all; the KRACK attack on WPA2 needed fixes from hundreds of vendors for one design flaw.
What to watch
Three questions will shape this system over the next year. Can NVD’s narrower scope hold, or will more of the industry move to CNA scores, CISA Vulnrichment and the EUVD for enrichment? Will CVE governance move to an international or nonprofit model now that the funding crisis has passed? And will AI-assisted vulnerability discovery push CVE volume high enough that scoring every bug stops making sense, leaving exploitation evidence (KEV and EPSS) as the main way anyone decides what to fix?
For definitions of the terms used here, see the cybersecurity glossary. Related explainers cover passkeys, which remove a whole class of credential-theft risk, and post-quantum cryptography, the coming migration that no CVE will announce.