A short history of CVE IDs and how the numbering works

The Common Vulnerabilities and Exposures system was officially launched for the public in September 1999. Each entry gets an ID in the form CVE-YEAR-NNNN. MITRE maintains the system and acts as editor, with many vendors and projects assigning IDs for their own products as CVE Numbering Authorities.

The ID format

An ID such as CVE-2021-44228 has three parts: the prefix, the year, and a sequence number. The year is the year the ID was assigned or reserved, not necessarily when the flaw was found or fixed.

The Wikipedia article notes a syntax change that took effect on 13 January 2015. Before it, the number had four digits. After it, the number can grow longer when a year needs more IDs. So an ID with five digits is valid.

Who assigns IDs

MITRE serves as editor and primary CNA. Vendors including Microsoft, Oracle, HP and Red Hat assign IDs for their own products. The CERT Coordination Center can assign IDs for products no other CNA covers. Some open source projects have applied to become CNAs for their own software.

This spread of assigners explains why a bug can have a CVE ID before most people have heard of it. It also explains why quality varies from entry to entry.

Funding

The program was historically funded by the National Cyber Security Division of the US Department of Homeland Security. The article says that in 2025 the MITRE contract was set to expire but was extended by 11 months. It adds that after a funding risk on 16 March 2026, acting CISA director Nick Andersen stated that the program is now being fully funded.

This is as stated by that article at the time of writing. If you depend on CVE data for compliance work, check current status from the program itself.

Practical use

• Treat a CVE ID as a name, not a score. Severity comes from other sources.
• Record the ID in your tickets so reports from scanners, advisories and vendors can be matched.
• Do not assume that a missing ID means a missing vulnerability. Some flaws are tracked only in vendor advisories or package ecosystems.

Common mistakes with CVE data

A few mistakes come up often. Teams sort by CVE ID number as though it showed importance, which it does not. They treat a missing ID as safety, when some issues are tracked elsewhere. And they forget that an entry can be updated, so a record read last year may differ today. Fetch current data when it matters, and store the date you read it. For audits, keep the ID alongside your own ticket, the decision you made, and the reason. That trail is worth more than the entry itself when someone asks later.

Quick check

Safeguard matches CVE data against your SBOM and dependencies, and a free scan is available at gold.safeguard.sh/scan.

Sources

• Common Vulnerabilities and Exposures

Last reviewed: 19 October 2026.