What Is a CVE? How a Vulnerability Gets Its ID

CVE-2021-44228 is a name. It is not a score, not a warning, and not a claim that anyone has ever attacked the thing it names. It happens to name Log4Shell, which was about as serious as software flaws get, but the identifier itself carried none of that on the day it was issued. Everything you associate with it arrived afterwards, from several different organisations, on several different schedules.

That structure is the single most useful thing to understand about CVEs. Almost every confusing thing about them follows from it: why a brand-new ID shows no severity, why two vulnerability trackers report different scores for the same flaw, and why an ID your scanner just flagged can return nothing at all from a lookup and still be perfectly real.

A CVE ID is a name#

The identifier exists so that a scanner finding, a vendor advisory, a patch note, a ticket and a news article can all point at the same flaw without ambiguity. Before CVE IDs, they often could not, and two teams could spend a morning discovering they were discussing different bugs.

The format is fixed by the CVE Record Format schema: the literal CVE, a four-digit year, then a sequence number of four to nineteen digits. The sequence is not padded to a fixed width, which surprises people who write parsers. CVE-2021-44228 and CVE-2014-0160 are both well-formed, and so is an ID with far more digits than either. If you validate CVE IDs anywhere in your own tooling, match that range rather than assuming four.

The year is the year the identifier was issued, not the year the flaw was written, found, or fixed. Those can be decades apart, and the sequence number tracks neither. The first record the NVD API returns, CVE-1999-0095, is a Sendmail flaw carrying a publication date of 1 October 1988, eleven years before the year in its own ID. CVE-1999-0001, a lower number in the same year, is dated December 1999. Sorting by ID is not sorting by age.

Who issues the number#

IDs are handed out by CNAs, or CVE Numbering Authorities. These are organisations authorised to assign identifiers within a defined scope. The CVE Program's published list held 549 CNAs across 44 countries when we read it on 22 September 2026, and it grows steadily.

Scope is the interesting part. Adobe's entry, for example, covers "Adobe issues only". A vendor CNA assigns IDs for flaws in its own products, which means the organisation closest to the code usually writes the first description. Log4Shell's record names security@apache.org as its source: Apache assigned its own CVE.

Two practical consequences. First, the quality and precision of a description vary with who wrote it, because a vendor's security team and a third-party coordinator are not writing to the same brief. Second, when a flaw falls outside every vendor scope, a coordinating CNA picks it up, which is why some records name a researcher's coordinator rather than the software's maker.

Reserved, published, rejected#

An ID is reserved before it is published. A CNA attaches an identifier to a flaw it is working on, and the record stays private while the fix is prepared. The record format carries a dateReserved field for exactly this, with a disclaimer attached in the schema itself: the reservation date does not necessarily indicate when the vulnerability was discovered, shared, or made public.

Once the embargo lifts, the record is published. In the published record format a record's state is either PUBLISHED or REJECTED. Rejection is a real and healthy outcome: duplicates and entries that turn out not to describe a vulnerability get rejected rather than deleted, so the ID never silently means something else later. Rejected records say why, in plain language. One from a week of September 2026 publications reads, in full: "Rejected reason: Red Hat Product Security has come to the conclusion that this CVE is not needed."

This is why a lookup returning nothing is rarely evidence of a fake. A well-formed ID that no source knows is usually reserved but not yet published, or published minutes ago and not yet propagated. The official CVE List repository refreshes roughly every seven minutes, and downstream databases add their own lag on top.

The score comes from somewhere else#

The CVE record is one artifact. The severity score, the weakness classification and the curated reference list are a different one, produced by the National Vulnerability Database, which NIST runs. NVD ingests published CVE records and enriches them. On 22 September 2026 it held 396,088 of them.

So the chain is: a CNA assigns and describes, the CVE Program publishes, NVD analyses. Three steps, three clocks. When two vulnerability trackers show different CVSS scores for one ID, it is usually because one is showing the vendor's own submitted score and the other is showing NVD's independent assessment. Neither is lying. They are different opinions about the same flaw, and the record format is built to hold both.

Awaiting analysis is a real state#

Every NVD record carries a status describing how far that analysis has got. The values you will meet are Awaiting Analysis, Undergoing Analysis, Analyzed, Modified, Deferred and Rejected.

They are not rare edge cases. NVD published 4,333 CVEs in the single week of 8 to 15 September 2026. Reading a 500-record sample from that week on 22 September, one to two weeks after publication: 195 were Analyzed, 121 were still Awaiting Analysis, 57 were Undergoing Analysis, 119 were Deferred, and eight were Modified or Rejected. Fewer than two in five carried a completed analysis.

If a record you care about sits in one of those states, the answer is not to wait. Go to the CNA's own advisory, which the record links, and read the vendor's assessment of the affected versions. That information existed before NVD got to it.

The exploitation list joins on the same ID#

The third dataset worth knowing is the Known Exploited Vulnerabilities catalog published by CISA, which lists CVEs with reliable evidence of exploitation in the wild. It keys on the same identifier, which is the whole point of the naming scheme.

It is a short list by design. The copy behind our tools, catalog version 2026.09.18, holds 1,716 entries, of which 360 carry a known-ransomware flag. Against 396,088 records in NVD, that is under half a percent. Inclusion is not a prediction or a score. It means observed attacks, and it is the field that most often settles an argument about scheduling.

The inverse does not hold. Absence from that catalog means CISA has not published confirmed evidence, not that a flaw is safe, and a result read today is a statement about today's catalog. Our comparison of CVSS, EPSS and KEV works through how the three signals are meant to be combined rather than substituted.

Reading one record end to end#

Put CVE-2021-44228 into the CVE Explorer and the assembled picture looks like this. The record was published on 10 December 2021, assigned by Apache. NVD's status is Analyzed. It carries a CVSS v3.1 base score of 10.0, rated critical, and a legacy CVSS v2 score of 9.3, rated high, which is a neat demonstration of why the version matters: the older scale understates it. Four weakness classes are attached, including CWE-502 for unsafe deserialisation, and the reference list runs to 103 entries, which by itself tells you how much attention the flaw drew.

The exploitation half is blunter. CISA added it to the catalog on 10 December 2021, the same day it was published, with a federal remediation deadline of 24 December and the ransomware flag set. Nothing about the severity score was needed to know what to do that week.

Our lookup reports the newest CVSS version a record carries and prefers NVD's own scoring where a vendor also submitted one, so the number you see is NVD’s own assessment on the newest scale the record carries, rather than whichever score happens to be listed first. The exploitation catalog is held locally, which means that when NVD is rate-limiting or unreachable, the page still answers the exploitation question and says plainly that the description could not be retrieved.

Where the ID stops helping#

Roughly four thousand new CVEs a week means reading them all is not a strategy anyone can execute. Worse, the identifier says nothing about whether you run the affected software, at what version, or whether the vulnerable component is reachable from anywhere that matters. That is an inventory question, and no lookup can answer it for you.

What a lookup does is turn one ID into a decision-shaped answer quickly. For a single flaw someone has just emailed you about, that is the CVE Explorer. For a scanner export with dozens of findings, ordering matters more than depth, so the bulk CVE triage tool ranks a pasted list by confirmed exploitation first. If what you actually need is to take apart the score itself, the CVSS calculator and our guide to reading a CVSS vector string cover what each metric in the vector is claiming.

When an ID lands in your inbox#

• Check exploitation before severity. A listed CVE is a scheduling decision already made. An unlisted 9.8 still needs the rest of this list.
• A "not found" result usually means new, not fake. Check the format first, then assume propagation lag and read the vendor advisory.
• Read the status field. Awaiting Analysis or Deferred tells you no NVD score has been produced, which is a different thing from a judgement that the flaw is minor.
• Find out whether you run it. Affected product and version, then reachability. Most CVEs are irrelevant to any given organisation.
• Use the score to order what is left. CVSS measures the flaw in isolation, so it is a sorting key for your remaining queue rather than a verdict on your risk.

The naming scheme does its job quietly. It gives a vendor, a researcher, a government catalog and your scanner a way to talk about one flaw without describing it from scratch every time. Once you know which link in that chain produced each field on the page, the disagreements between tools stop being mysterious and start being informative.