What Is a CVE? Common Vulnerabilities and Exposures

When a Log4j advisory, a Microsoft patch note, a vulnerability scanner finding, and a threat-intel feed all need to talk about the same flaw, they use one string: CVE-2021-44228. That identifier is why a scanner in Berlin, an analyst in Austin, and a vendor bulletin in Tokyo are provably discussing the same bug and not three that sound alike. Before CVE existed, two tools could report "the Apache buffer overflow" and mean different vulnerabilities, or report it under two names and double-count the same one. The identifier removed that ambiguity.

Common Vulnerabilities and Exposures (CVE) is the system that assigns those identifiers. It is a public dictionary, one entry per known flaw, each entry a unique ID plus a short description and references. It is not a database of how to exploit anything, not a severity score, and not a scanner. It is the naming layer the rest of the vulnerability ecosystem is built on top of. This guide covers what a CVE is and what a record contains, who assigns them and how the program is governed, the lifecycle of a record from reservation to publication, how CVE differs from CVSS and the NVD, and how a defender actually uses CVE IDs day to day.

What is a CVE?

A CVE is a unique, public identifier for one specific, known security vulnerability or exposure. The acronym expands to Common Vulnerabilities and Exposures, and in practice "a CVE" means one entry in that list: an ID like CVE-2021-44228, attached to one flaw, with a brief description and a set of references.

The distinction the program draws is in the name. A vulnerability is a weakness in a product that an attacker can exploit directly to compromise confidentiality, integrity, or availability, a buffer overflow, an authentication bypass, an injection flaw. An exposure is a configuration or mistake that is not itself the break-in but gives an attacker a stepping stone or information they should not have, an exposed service, leaked data, a setting that widens what an attacker can reach. Both get CVE IDs.

What a CVE is not matters as much as what it is. It is not a measure of how bad the flaw is, that is CVSS, a separate standard. It is not a database of exploit code or remediation steps, the record points to references but does not host attacks. And it is not a scanner or a product, it is a naming convention that scanners, advisories, and feeds all reference so they interoperate. The single job of a CVE ID is to be a stable, shared name for one flaw, so every tool and team that touches it is provably talking about the same thing.

That shared name is what makes the rest of the stack work. A vulnerability management program correlates a scanner finding, a vendor patch, a threat-intel report, and a ticket by matching on the CVE ID. Without it, that correlation is fuzzy string-matching on product names and is wrong often enough to be dangerous.

What a CVE record contains

A CVE record is deliberately minimal. The core of an entry is three things:

• The CVE ID. The unique identifier, in the format CVE-YYYY-NNNN, where YYYY is the year the ID was assigned (not necessarily the year the flaw was found or disclosed) and NNNN is a sequence number of four or more digits.
• A description. A short, structured summary of the flaw: the affected product and versions, the vulnerability type, and the impact. Enough to identify the flaw, not enough to weaponize it.
• References. Links to authoritative sources, the vendor advisory, the patch, the researcher's write-up, that carry the detail the record itself omits.

The ID format carries a piece of history worth knowing. The original syntax, used from CVE's start in 1999, was CVE-YYYY-NNNN with exactly four digits, which capped the program at 9,999 IDs per year. As public vulnerability reporting outgrew that ceiling, the CVE Board changed the syntax so the sequence number can be four or more digits. The new syntax took effect on January 1, 2014. So CVE-2014-12345 and CVE-2023-1234567 are both valid, the sequence portion simply grew. Older IDs were not renumbered; they already fit.

What a record does not contain is as important as what it does. There is no CVSS score in the base CVE record by default, no patch instructions, and no exploitability rating. That enrichment, scoring, weakness classification, affected-platform data, lives in downstream databases like the NVD, which is exactly the division of labor the CVE Program is built around.

Who assigns CVEs: the program and CNAs

CVE is not a single organization handing out numbers from one desk. It is a federated program with a defined governance structure, and understanding that structure explains why CVE scales to tens of thousands of IDs a year.

The CVE Program is sponsored by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), part of the Department of Homeland Security. It is operated by the MITRE Corporation, which runs the program as its Secretariat, maintains the public CVE List and website, and also serves as a Top-Level Root. MITRE keeps the CVE List a free, open standard for the community.

The work of assigning IDs is distributed to CVE Numbering Authorities (CNAs). A CNA is an organization authorized by the program to assign CVE IDs and publish records for vulnerabilities within a defined scope, usually its own products. Vendors like Microsoft, Red Hat, Cisco, and Oracle are CNAs for their own software; open-source projects, coordination centers, and bug bounty platforms are CNAs too. More than 450 organizations now participate as CNAs across dozens of countries. That federation is the point: the vendor who knows the bug best assigns its ID and writes its record, rather than routing everything through one central team.

The CNAs are organized in a hierarchy. Top-Level Roots (MITRE and CISA's roots) sit at the top, Roots administer groups of CNAs beneath them, and CNAs do the actual assignment. A CNA assigns IDs out of a block reserved for it, which lets assignment happen in parallel and even before a flaw is public, without two CNAs ever colliding on the same number.

The CVE record lifecycle

A CVE ID does not appear fully formed. It moves through defined states, and knowing them prevents a common mistake: treating a reserved-but-empty ID as if it were nothing, or treating it as if it were a confirmed, scored vulnerability.

Reserved. A CNA reserves an ID for a vulnerability it is working on, often during coordinated disclosure, before any detail is public. At this stage the ID exists but the record is essentially a placeholder. You will see this state when a vendor references a CVE ID in advance of its advisory. The ID is real; the public detail is not there yet.

Published. Once the CNA populates the record with a description, affected versions, and references, the record is published to the CVE List. This is the point at which the flaw is publicly known under its CVE ID and downstream consumers, scanners, the NVD, threat-intel feeds, can ingest it.

Rejected (or disputed). Not every reserved ID becomes a real vulnerability. An ID may be rejected if it turns out to be a duplicate, not actually a security issue, or assigned in error. A record can also be disputed when parties disagree on whether the flaw is valid. A rejected ID is retired, never reused, so the number stays a stable, permanent reference even when the answer was "this was not a vulnerability."

The lifecycle is why a CVE ID is a durable anchor. Reserved IDs let coordinated disclosure happen without leaking the flaw, published records give everyone the same reference, and rejected IDs are tombstoned rather than recycled, so a given string always means exactly one thing forever.

CVE vs CVSS vs NVD

The three acronyms travel together and get conflated constantly. They are three different things doing three different jobs, and a defender needs all three.

CVE is the identity layer. It answers "which flaw?" with a unique name and a minimal description. That is its entire job.

Common Vulnerability Scoring System (CVSS) is the severity layer. It answers "how bad?" with a numeric score from 0.0 to 10.0 and a qualitative rating of None, Low, Medium, High, or Critical. CVSS is a separate open standard maintained by FIRST (the Forum of Incident Response and Security Teams), not by the CVE Program. The current version is CVSS v4.0, published in November 2023. A CVE ID names the flaw; a CVSS score rates it. The base CVE record does not carry a CVSS score.

The National Vulnerability Database (NVD) is the enrichment layer. Run by the U.S. National Institute of Standards and Technology (NIST), the NVD ingests CVE records from the CVE List and adds analysis on top: a CVSS score, a CWE (Common Weakness Enumeration) classification of the underlying weakness type, and CPE (Common Platform Enumeration) data describing exactly which products and versions are affected. The NVD does not discover or name vulnerabilities; it consumes the CVE List and enriches it. When a tool shows you "CVE-2021-44228, CVSS 10.0, affects Apache Log4j 2.x," the ID is CVE's, the score is CVSS, and the bundling of the two against specific product versions is largely the NVD's enrichment.

The clean way to hold it: CVE names the flaw, CVSS rates it, NVD enriches it. The CVE ID is the join key that lets the other two attach their data to the right flaw.

How defenders use CVE IDs

The CVE ID is a working tool in the SOC and the vulnerability management program, not a piece of trivia. Several daily workflows run on it.

Correlation across tools. A vulnerability scanner reports findings by CVE ID, the patch management system tracks fixes by CVE ID, and the threat-intel feed flags active exploitation by CVE ID. The ID is the join key that turns three separate data sources into one picture: this asset has this flaw, a patch exists, and it is being exploited in the wild right now. That last signal, the move from "a CVE exists" to "this CVE is being exploited," is what should drive prioritization, and CISA's Known Exploited Vulnerabilities (KEV) catalog tracks exactly that, keyed by CVE ID.

Scoping the attack surface. Matching the CVE IDs in your environment against your asset inventory tells you which exposures actually apply to you. A critical CVE in software you do not run is noise; the same CVE in an internet-facing host on your attack surface is an emergency. The ID is what makes that match precise instead of a guess based on product names.

Detection and threat hunting. When an advisory drops, detection engineers and threat hunters pivot on the CVE ID to find vendor IOCs, proof-of-concept behavior, and exploitation telemetry tied to that specific flaw. The ID is the search term that ties an alert, a log pattern, and a known vulnerability together.

The thing to internalize is that a CVE ID without context is only half the story. The ID tells you which flaw; you still need CVSS for severity, the NVD or vendor advisory for affected versions, the KEV catalog or intel feed for active exploitation, and your own inventory for relevance. The discipline of vulnerability management is assembling those layers on top of the shared name, and the CVE ID is what makes the layers line up.

Frequently Asked Questions

What does CVE stand for?

CVE stands for Common Vulnerabilities and Exposures. It is a public program that assigns a unique identifier to each known security vulnerability or exposure, so that everyone, vendors, scanners, analysts, and feeds, can refer to the same flaw by the same name.

What is the difference between a CVE and a CVSS score?

A CVE is the identifier for a flaw; a CVSS score rates how severe that flaw is. CVE answers "which vulnerability?" with a unique name, while CVSS answers "how bad is it?" with a number from 0.0 to 10.0 and a rating of None to Critical. They are maintained by different bodies, the CVE Program and FIRST, and the base CVE record does not include a CVSS score.

Who assigns CVE IDs?

CVE IDs are assigned by CVE Numbering Authorities (CNAs), organizations authorized by the CVE Program to assign IDs within a defined scope, usually their own products. The program is sponsored by CISA and operated by MITRE, and more than 450 organizations now participate as CNAs, including vendors, open-source projects, and coordination centers.

What does the CVE ID format mean?

A CVE ID has the format CVE-YYYY-NNNN: the CVE prefix, the year the ID was assigned, and a sequence number of four or more digits. The year is when the ID was assigned, not necessarily when the flaw was found. The sequence number was expanded from a fixed four digits in 2014 so the program could issue more than 9,999 IDs in a single year.

Is CVE the same as the National Vulnerability Database (NVD)?

No. The CVE List is the dictionary of identifiers and descriptions, maintained by the CVE Program. The NVD, run by NIST, ingests CVE records and enriches them with CVSS scores, CWE weakness classifications, and CPE product data. CVE names the flaw; the NVD adds the analysis on top.

What does it mean when a CVE is "reserved"?

A reserved CVE ID has been allocated by a CNA for a vulnerability that is still being worked on, often during coordinated disclosure, but does not yet have a public description. The ID exists and is valid, but the detail appears only once the record is published. You will often see reserved IDs referenced in advance of a vendor advisory.

The bottom line

A CVE is a unique, public name for one known security flaw, an ID like CVE-2021-44228, plus a short description and references. Its single job is to be a stable, shared identifier so that scanners, advisories, threat-intel feeds, and analysts are provably talking about the same vulnerability rather than guessing from product names.

The identifiers are assigned by a federated program: sponsored by CISA, operated by MITRE, and distributed to more than 450 CNAs who name and document flaws within their own scope. Each record moves through a defined lifecycle, reserved, published, rejected or disputed, so a CVE ID always means exactly one thing, permanently. CVE is only the identity layer; CVSS rates severity and the NVD enriches with weakness and product data. For a defender, the ID is the join key that ties a scanner finding, a patch, an exploitation signal, and an asset together into a decision about what to fix first.