What Is a CVE?

A CVE is a unique identifier and its accompanying public record for one specific, publicly disclosed software vulnerability. CVE stands for Common Vulnerabilities and Exposures, the name of the program that issues those identifiers, which began in 1999 and is sponsored by CISA within the US Department of Homeland Security and operated by MITRE.

In everyday use, the word has drifted toward the flaw itself, as in patching a CVE or a product having three CVEs. Strictly, the CVE is the label and the record attached to it, and the distinction matters because what that record contains varies far more than most people assume.

Reading a CVE Identifier

The format is CVE, then the year, then a sequence number of four or more digits. CVE-2021-44228 and CVE-2016-7654321 are both valid.

The year is the part that misleads, because it records when the identifier was assigned, or when the vulnerability was first made public if that came earlier. It says nothing about when the flaw was introduced, when it was discovered, or when it was fixed. A vulnerability found in 2015 and disclosed in 2016 carries a 2016 identifier when the request came that year, and a 2015 one where an earlier request had already been sitting reserved.

Sequence numbers were capped at four digits until the program ran out of room. The original syntax allowed 9,999 identifiers per year, so the CVE Board changed it effective 1 January 2014, with identifiers in the new syntax first issued in January 2015.

Inside a CVE Record

The record format requires an identifier, a description, the affected products, the affected versions, and public references. Everything past that is optional, including CVSS metrics, weakness classification, credit to whoever found the flaw, and remediation advice.

Two records published on the same day can therefore carry wildly different amounts of information, depending on whether the assigning authority filled in the optional fields, and nothing in the schema obliges anyone to.

Records also stopped being single objects, and since 2024 one can hold several containers. Alongside the assigning CNA's there is a CVE Program container holding references the program contributes, plus containers from Authorized Data Publishers, who enrich records without assigning identifiers. CISA runs such a publisher, adding scoring and weakness data to records through its Vulnrichment effort, which exists largely because enrichment elsewhere could not keep pace.

Whatever remains missing arrives from elsewhere, since the National Vulnerability Database adds its own analysis, exploitation evidence comes from CISA's Known Exploited Vulnerabilities catalog, and fix guidance comes from the vendor.

Who Assigns a CVE Identifier

Assignment is federated, and organizations authorized as CVE Numbering Authorities receive blocks of identifiers and issue them for vulnerabilities inside an agreed scope, usually their own products or an ecosystem they maintain. Microsoft, Google, the Linux kernel project, and hundreds of others operate this way, reporting through Root organizations up to MITRE and CISA as Top-Level Roots.

Participation is voluntary, carries no fee, and requires no contract, and MITRE acts as the CNA of Last Resort for anything falling outside every other scope.

This is where the variation in record quality originates, because a disciplined vendor publishes precise version ranges and affected components, while an authority treating assignment as paperwork leaves downstream consumers guessing at what is affected.

Reserved, Disputed, and Rejected Records

An identifier moves through states, and a published record is only one of them. Reserved means an identifier has been allocated but its details are not yet public, which is why an identifier can appear in a vendor advisory before it resolves anywhere. Disputed means someone contests that the issue is a vulnerability at all, and the program takes no position on who is right. Rejected means the record was withdrawn, duplicated, or assigned in error.

These states also explain a discrepancy that confuses anyone comparing sources, since the published count on cve.org excludes reserved and rejected identifiers while NVD's total includes rejected ones, so the two numbers never match.

What the 2025 Contract Episode Revealed

On 15 April 2025, a MITRE vice president told the CVE Board that the contracting pathway funding the program would expire the following day, warning of deterioration across national vulnerability databases, tool vendors, and incident response. CISA executed a contract option within hours, extending operations by eleven months, and later characterized the matter as contract administration rather than a funding lapse.

The near-miss produced durable consequences anyway. A CVE Foundation launched the same day to pursue governance independent of a single government sponsor, and a decentralized identifier scheme was proposed as an alternative allocation model. ENISA's European Vulnerability Database went live the following month, though that had been mandated under the NIS2 Directive long before April and is better read as arriving at a convenient moment than as a response. An identifier system the whole industry treats as permanent infrastructure turned out to rest on a contract renewal.

What a CVE Cannot Tell You

Plenty of real risk never receives an identifier at all, including flaws in an organization's own code, misconfigurations, exposed credentials, and abuse of features working as designed, which is the territory covered by CVE-less threats.

Even for vulnerabilities that do carry one, the identifier reports that a flaw exists in a product somewhere. It does not report whether the affected component loads in your application, whether the vulnerable function is ever called, or whether any path reaches it.

Raven Runtime SCA determines which vulnerable components load and execute inside the running application, so a queue of CVE identifiers becomes a list ordered by what the software does rather than by what is installed. See how it works at Runtime SCA.