The CVE System: How Vulnerabilities Get Their Names

When a flaw in a piece of software becomes public, the first thing it gets is a name. That name is a CVE identifier, something like CVE-2024-12345, and it lets a vendor advisory, a scanner finding, a patch note, and a news headline all point at the exact same problem. Without it, the industry would be arguing over whether two reports describe one bug or two.

CVE, Common Vulnerabilities and Exposures, is a program that assigns those identifiers and keeps a public record for each one. It is operated by MITRE with sponsorship from CISA, and it has become the shared vocabulary of vulnerability management. Understanding how an ID gets created, and how CVE differs from the database that scores it, clears up most of the confusion people have about vulnerability data.

What a CVE ID is

A CVE ID has a simple structure: the prefix CVE, the year, and a sequence number, for example CVE-2024-12345. The year is the year the ID was reserved, which is not always the year the vulnerability becomes public. The number has no meaning beyond uniqueness; a higher number does not imply a worse flaw.

Each ID maps to one vulnerability. The associated record carries a short description, the affected products and versions, and references to advisories or research. The point of the record is identity and traceability. It tells you which flaw this is and where to read more, and it leaves the scoring and deep analysis to other systems.

CNAs: how assignment scales

No single office could name every vulnerability in the world's software. The CVE program solves this with a federated model built on CVE Numbering Authorities, or CNAs.

A CNA is an organisation authorised to assign CVE IDs within a defined scope. Most large software vendors are CNAs for their own products. Open-source projects, security research firms, bug bounty platforms, and national coordination centres are CNAs too. A small set of CNAs of last resort handle vulnerabilities that fall outside every other CNA's scope.

Role	Who fills it	Scope
Vendor CNA	Software and hardware makers	Their own products
Open-source CNA	Major projects and foundations	Their own codebases
Coordinator CNA	Research groups, national CERTs	Third-party and multi-vendor issues
CNA of last resort	Designated top-level authorities	Anything no other CNA covers

This federation is why the program keeps up with a global flood of vulnerabilities. Assignment happens close to the source, where the people who understand the flaw already are, and the program coordinates the whole network rather than doing every assignment centrally.

The lifecycle of a record

A CVE ID does not spring into existence fully described. It moves through states.

Reserved. A CNA sets aside an ID for a vulnerability that has been reported but not yet disclosed. The ID exists, but the details are deliberately withheld. This is normal during coordinated disclosure, where researcher and vendor agree to keep specifics quiet until a patch is available. A reserved entry looks empty on purpose.

Published. Once the vulnerability is disclosed, the CNA populates the record with a description, affected products, and references, and the entry becomes public. This is the state most people see.

Rejected or disputed. Sometimes an ID is withdrawn because the issue turned out not to be a valid vulnerability, or a vendor disputes the claim. The record reflects that status so the history stays honest.

CVE versus the NVD

This is the distinction that trips people up most, so it is worth stating plainly.

CVE is the identifier and the core record. It is run by MITRE under the CVE program. It answers: what is this vulnerability, what does it affect, and where can I read about it.

The NVD, the National Vulnerability Database, is a separate database run by NIST. It ingests CVE records and enriches many of them with additional analysis, most visibly a CVSS score, along with product mappings and other metadata. It answers: how severe is this, expressed as a number.

System	Run by	Provides
CVE	MITRE (CISA-sponsored)	The ID, description, affected products, references
NVD	NIST	CVSS scores and enrichment layered on CVE records

The two are complementary. A CVE gives the flaw its name and its facts. The NVD is one consumer that adds a severity view. Other databases and vendors consume CVE records too, which is why the same CVE can appear with different enrichment in different places while the identity stays constant.

How to use the CVE system well

1. Treat the CVE ID as the join key. It is the one identifier that connects advisories, scanners, EPSS, KEV, and your ticketing system. Always record it.
2. Do not read severity into the number. The sequence in a CVE ID is arbitrary. For severity, go to the CVSS score in the NVD or the vendor advisory. See CVSS Explained.
3. Expect gaps and lag. A record can sit reserved for a while, and NVD enrichment can trail the CVE publication. Plan workflows that tolerate incomplete data rather than assuming every field is filled the moment a CVE appears.
4. Follow the references. The reference links in a record point to the authoritative advisory and patch, which is usually where the actionable detail lives.
5. Layer the signals. The CVE names the flaw; EPSS estimates likelihood, KEV confirms exploitation, CVSS rates impact. Together they turn a raw ID into a prioritisation.

The CVE system does one thing and does it reliably: it gives every disclosed vulnerability a stable, shared name and a factual record. The severity scores, likelihood models, and exploitation catalogs all hang off that name. Get comfortable with how IDs are reserved, who assigns them, and where CVE ends and the NVD begins, and the rest of the vulnerability data ecosystem stops looking like a tangle.

A walkthrough of a CVE's journey

Tracing one vulnerability from discovery to a published record makes the abstract lifecycle concrete, and shows why records sometimes look incomplete when you find them.

A researcher discovers a flaw in a widely used application. Their first step is usually to report it privately to the vendor rather than publish it, which begins coordinated disclosure. The vendor, if it is a CNA for its own products, reserves a CVE ID for the issue. At this point the identifier exists and is essentially a placeholder. Anyone who looks it up finds a reserved entry with almost no detail, which is the system working as intended, because publishing details before a fix exists would arm attackers against unpatched users.

Behind the reservation, the vendor and researcher work through the fix. They confirm the affected versions, develop and test a patch, and agree on a disclosure date. The reserved CVE ID travels through all of this as the shared reference, so the vendor's internal tracking, the researcher's notes, and the eventual advisory all point at the same identifier even while the details are embargoed.

On the agreed disclosure date, the vendor publishes the patch and populates the CVE record. The reserved entry becomes a published one, gaining a description of the flaw, the list of affected products and versions, and references to the vendor advisory and patch. The identifier that was a placeholder is now a full, public record that scanners can key on and defenders can act against.

After publication, a second process often runs. The NVD ingests the newly published CVE record and enriches it, most visibly by assigning a CVSS score and mapping affected products in its own format. This enrichment can lag the CVE publication, sometimes by a noticeable gap, which is why a fresh CVE can appear with a full description but no severity score for a while. The identity and facts come from the CVE program, and the severity view arrives separately from the NVD.

Detection and workflow signals

The CVE system is data infrastructure, so the signals worth tracking are about how records flow through your tooling and where they lag.

• A reserved CVE referenced in a vendor pre-announcement. When a vendor signals a coming fix and cites a reserved ID, it is worth capturing early so you are ready to act the moment the record publishes.
• A newly published CVE matching your inventory. The core signal is a fresh record for a product you run. Matching CVE publications against an asset inventory, joined on vendor and product, is what turns the feed into action.
• CVE published but NVD enrichment missing. A record with a description and affected products but no CVSS score yet is common, because NVD analysis trails CVE publication. Workflows that wait for a severity score before acting will stall on exactly the freshest flaws.
• A CVE marked rejected or disputed. A withdrawn or contested record means the issue may not be a valid vulnerability, so tickets keyed to it should be re-checked rather than actioned blindly.
• The same CVE with different enrichment in different sources. Because many databases consume CVE records and add their own analysis, the identity stays constant while the surrounding scores and metadata vary. Treat the CVE ID as the anchor and reconcile the enrichment.

Common misconceptions

"A higher CVE number means a more serious flaw." The sequence number carries no severity meaning. It only ensures uniqueness within a year. A CVE ending in a large number is not worse than one ending in a small number, and the year in the ID is the year it was reserved, which is not always the year the flaw became public.

"CVE and the NVD are the same thing." They are separate systems run by different organisations. CVE, operated by MITRE, assigns the identifier and the core record. The NVD, operated by NIST, is one consumer that adds CVSS scoring and enrichment on top. People conflate them because the NVD is where many first see a CVE with its severity attached.

"An empty CVE record means the system failed." A freshly reserved CVE with almost no detail is usually coordinated disclosure working correctly. The ID is locked in so everyone can reference the coming fix, while the specifics stay embargoed until a patch ships. The blank record is deliberate.

"Every vulnerability gets a CVE." Only vulnerabilities that fall within a CNA's scope and are reported through the process receive an ID. Some flaws are fixed silently, some fall outside any CNA's coverage, and some are disputed. The catalog is broad and it is not exhaustive.

"The CVE description tells me everything I need." The record is deliberately concise, aimed at identity and traceability. The actionable detail, the exact affected builds, the patch, the mitigation, usually lives in the vendor advisory linked from the references. The record points you there rather than reproducing it.

CVE compared with the systems around it

The CVE ID is the anchor, and several other systems attach to it. Keeping their roles straight is what makes vulnerability data coherent.

System	Run by	Answers
CVE	MITRE (CISA-sponsored)	What is this flaw, what does it affect, where to read more
NVD	NIST	How severe is it, expressed as a CVSS score plus enrichment
CVSS	FIRST (standard)	How much damage a successful exploit would cause
EPSS	FIRST	How likely exploitation is in the near term
KEV	CISA	Is it confirmed to be exploited in the wild right now

The CVE names the flaw and states the facts. CVSS, delivered through the NVD or a vendor, rates its potential impact. EPSS estimates the probability it will be exploited soon. KEV confirms whether exploitation is already happening. Each of these is a distinct question, and each hangs off the CVE identifier as the join key. See CVSS Explained, EPSS Explained, and The KEV Catalog Explained for how the layered signals are built and used together.

How the CVE program evolved

Before CVE existed, every vendor, scanner, and research group named vulnerabilities in its own way. The same flaw might carry a different label in each tool, and defenders wasted effort working out whether two advisories described one bug or two. There was no shared vocabulary, which made correlating data across sources slow and error-prone.

CVE was introduced in 1999 to solve exactly that. The idea was simple and durable: give every publicly known vulnerability a single, stable identifier that any tool or report could reference, so the industry could talk about the same flaw with the same name. MITRE operated the program, and it quickly became the common language of vulnerability management, adopted by scanners, advisories, and databases alike.

Two developments shaped the modern program. The first was the NVD, which NIST built on top of CVE records to add severity scoring and enrichment, creating the two-system split that still confuses people today. The second was the federation of assignment through CNAs. Rather than name every vulnerability from one central office, the program authorised vendors, projects, and coordinators to assign IDs within their own scopes, which let it scale to a global flood of disclosures. More recent changes have modernised the record itself into a structured JSON format maintained through the program's public services, so records are machine-readable and flow cleanly into tooling. The purpose has held constant since 1999: one stable name per flaw, so everything else can hang off it.

Reading a CVE record field by field

A published CVE record is a structured entry, and knowing what each part is for helps you get the right information from it and avoid asking it for things it does not provide.

The identifier is the anchor, the CVE-YEAR-NUMBER string that every other system references. Treat it as the primary key. The description is a short, factual summary of the flaw, written for identity rather than depth, so it tells you what class of vulnerability this is and roughly where it lives, and it deliberately stops short of exploitation detail.

The affected products section lists the vendors, products, and version ranges the flaw applies to. This is the field you match against your asset inventory to decide whether a record concerns you. It is also the field that benefits most from the structured format, because machine-readable version ranges let tooling determine applicability without a human reading prose.

The references are where the actionable detail lives. These links point to the authoritative vendor advisory, the patch, and often the original research. When you need the exact affected builds, the fix version, or the recommended mitigation, the references are where you go, because the record itself keeps the summary brief and defers the specifics to the source.

The assigning CNA and the record's state round out the picture. The CNA tells you who is responsible for the record, which is usually the vendor for its own products and a coordinator for multi-vendor issues. The state, whether reserved, published, rejected, or disputed, tells you how much to trust the contents and whether to act. A published record from the product's own vendor CNA is the strongest form, because the organisation that owns the code is standing behind the facts.

Held together, these fields explain the division of labour the whole system rests on. The CVE record establishes identity and points to the truth, the vendor advisory carries the operational detail, and the enrichment systems layer severity and exploitation data on top. Read the record for what it is built to give you, follow the references for the rest, and the identifier ties every view back to the same flaw.

Frequently asked questions

What does a CVE ID actually look like? It follows the format CVE, a year, and a sequence number, for example CVE-2024-12345. The year is when the ID was reserved, which is not always when the flaw became public, and the sequence number only ensures uniqueness. It carries no severity meaning.

Who assigns CVE IDs? A federated network of CVE Numbering Authorities, or CNAs, assigns them within defined scopes. Most large vendors are CNAs for their own products, and open-source projects, research firms, bug bounty platforms, and national coordination centres are CNAs too. A small set of CNAs of last resort handle vulnerabilities that fall outside every other scope.

What is the difference between CVE and the NVD? CVE, run by MITRE, is the identifier and the core record: what the flaw is, what it affects, and where to read more. The NVD, run by NIST, is a separate database that ingests CVE records and adds enrichment, most visibly a CVSS severity score. CVE gives the flaw its name and facts, the NVD adds a severity view.

Why does a CVE I looked up have almost no information? It is probably in the reserved state. A CNA sets aside an ID for a reported but not yet disclosed flaw, so the identifier exists while the details stay embargoed until a patch is ready. This is normal during coordinated disclosure, and the record fills in when the vulnerability is published.

Can a CVE be removed or invalidated? Yes. A CVE can be marked rejected if the reported issue turns out not to be a valid vulnerability, or disputed if a vendor contests the claim. The record reflects that status so the history stays honest, and a rejected or disputed entry should be re-checked rather than actioned as a confirmed flaw.

Does every vulnerability get a CVE? No. Only flaws that fall within a CNA's scope and are reported through the process receive an ID. Some are fixed silently, some fall outside any CNA's coverage, and some are disputed. CVE coverage is broad and not exhaustive.

How should I use a CVE ID in my workflow? Treat it as the join key that connects advisories, scanners, EPSS, KEV, and your ticketing system, and always record it. Pull severity from the CVSS score in the NVD or vendor advisory, add EPSS for likelihood and KEV for confirmed exploitation, and follow the reference links for the authoritative patch detail. The CVE ties all of those views to one flaw.

Related guides

• CVSS Explained
• EPSS Explained
• The KEV Catalog Explained
• Coordinated Vulnerability Disclosure Explained
• Zero-Day Vulnerabilities