The National Vulnerability Database, CVE and CVSS Explained

Updated: October 2026

Your scanner flags a CVE, the report says 9.8, and somebody asks whether to patch tonight. That number came from one of several systems that describe the same bug in different ways. Here's how the national vulnerability database, CVE, CVSS, KEV and EPSS fit together, and how to use them to decide what gets patched first.

What Is the National Vulnerability Database (NVD)?

The National Vulnerability Database is the US government's catalog of known software vulnerabilities. NIST runs it. It takes every published CVE and adds the details a scanner needs: a severity score, the weakness type (CWE), and a list of affected products written as CPE names.

That last part matters more than it sounds. A CVE record says "a flaw in product X before version 4.2". The NVD turns that into machine-readable product and version ranges, so your vulnerability scanner can match it against what's installed. NIST calls this work enrichment.

The NVD doesn't discover vulnerabilities, and it doesn't assign CVE IDs. It sits in the middle of a chain that starts with a researcher or a vendor and ends with a line in your scan report.

CVE vs NVD vs CVSS: Who Does What

Five names show up in every vulnerability report, and each one answers a different question.

A CVE is only an identifier. CVE Numbering Authorities (CNAs) assign it. CNAs are vendors like Microsoft and Google, plus researchers and coordinators, with MITRE as the root. The ID gives everyone one name for the same bug.

CVSS is the scoring formula. The current version, 4.0, came out in November 2023. The number you see most often is the base score, which rates the flaw in a vacuum: how it's reached, how complex the attack is, and what it breaks. It says nothing about whether anyone is attacking it.

KEV and EPSS fill that gap. CISA's Known Exploited Vulnerabilities catalog lists CVEs with reliable evidence of exploitation in the wild and a clear fix. EPSS is a machine-learning model that estimates the chance a CVE gets exploited in the next 30 days, updated daily for every CVE.

The NVD Backlog, and What Changed in 2026

In early 2024, NVD enrichment slowed to a crawl. New CVEs kept arriving with IDs and descriptions, but without the scores and product data that scanners rely on. NIST's own update on March 19, 2025 put it plainly: its processing rate was "no longer sufficient to keep up with incoming submissions", CVE submissions had risen 32% in 2024, and the backlog was still growing.

NIST then started triaging. On April 2, 2025, every unenriched CVE published before 2018 was marked Deferred, meaning NIST doesn't plan to enrich it. On April 15, 2026, a bigger shift took effect. NIST now enriches first the CVEs in the KEV catalog, CVEs in federal government software, and critical software under Executive Order 14028. Everything else is "Lowest Priority - not scheduled for immediate enrichment". Backlogged CVEs published before March 1, 2026 moved to a Not Scheduled category.

NIST also stopped adding its own severity score when the CNA has already scored the CVE. So the 9.8 on your report may come from the vendor, not from NIST.

For a small IT team, the practical effect is simple. Some CVEs that matter to you will sit in the NVD without product data for a long time. A scanner that leans only on NVD matching can miss them, or flag them without a score. It's worth asking your scanner vendor which other sources they pull from, such as vendor advisories or the CNA's own record.

The 2025 CVE Funding Scare

The CVE Program itself had a close call. On April 15, 2025, a MITRE letter warned that the contract funding the program expired the next day. That would have stopped new CVE IDs being assigned. CISA extended the contract by 11 months at the last minute, and a group of CVE board members set up the CVE Foundation to push for a more independent structure.

The funding question ran into 2026. In March 2026, CISA's acting director said the program was now fully funded. The worry still shaped how teams think about their tooling, as this r/cybersecurity thread shows:

The lesson for IT teams: don't build a patching process that depends on a single feed.

How to Read an NVD Entry

Open any CVE on the NVD site and you'll see the same blocks. Here's what each one tells you.

The description comes from the CNA. It names the product, the affected versions, and the type of flaw. Read it first, because it's the only part guaranteed to be there.

The severity block shows CVSS scores and who assigned them. You may see a NIST score, a CNA score, or both. When they disagree, the vector string explains why. AV:N means the attack works over the network. PR:N means no privileges are needed. UI:N means no user has to click anything. Those three together are the worrying combination.

The weakness block lists the CWE, the class of bug, like CWE-78 for OS command injection. The references link to vendor advisories and patches, which are usually the fastest route to a fix. The known affected software block holds the CPE configurations. If it's empty, NIST hasn't enriched the record yet.

Red Hat's security team walks through CVE and CVSS in a short explainer:

Why CVSS Alone Is a Bad Patch Order

Sort a scan report by CVSS and you'll get hundreds of criticals. They can't all be this week's job, and plenty of them will never see an exploit. CVSS measures how bad a flaw would be, not how likely anyone is to use it against you.

The signals also disagree. A 9.8 in a product with no public exploit can matter less than a 7.5 that sits in the KEV catalog and faces the internet. The poster in this thread describes exactly that problem:

The top reply starts with exposure: internet-facing systems first, then the hosts behind critical services.

A Patch Order Built on KEV, EPSS and Exposure

A better order uses all the signals, with CVSS as the tiebreaker rather than the driver.

1. In KEV and exposed. Anything in the KEV catalog on an internet-facing system is an emergency. Patch or mitigate within days.
2. In KEV, internal. Still urgent, because attackers who get inside use the same bugs. Schedule it this cycle.
3. High EPSS and exposed. No confirmed exploitation yet, but the model says it's likely. Treat it like KEV if it faces the internet.
4. Critical CVSS, low EPSS. Patch in the normal monthly cycle.
5. Everything else. Batch it with routine updates, and don't let it crowd out the first three.

CISA's current directive for federal agencies, BOD 26-04, is built on the same idea of fixing KEV entries first, and CISA encourages every organization to use the catalog. You don't need a federal mandate to copy the approach.

This order only works if you know where each vulnerable version is installed. That's where the inventory side of the job matters. OpenFrame can run a version check as a script across a client's devices and collect the output in one place, which turns a KEV entry into a list of machines to patch.

The patching itself is a separate job, covered in our guide to patch management software.

For the scanners that feed this process, see our vulnerability management software comparison.

The Short Version

CVE names the bug. The NVD adds the product data and a score. CVSS rates how bad it could be, KEV says it's being exploited, and EPSS says how likely that is soon. Since 2024 the NVD has fallen behind, and since April 2026 it enriches KEV and critical software first, so don't build your process on one feed. Patch what's exploited and exposed first, and let CVSS break ties.

To see what exploitation looks like from the attacker's side, read what an exploit is and why the gap between disclosure and attack keeps shrinking.