What is a CVE? Definition, ID format, and what to do about them

A CVE (Common Vulnerabilities and Exposures) is a unique, public identifier for a specific security flaw in a specific piece of software or hardware. One flaw, one ID, recognized by every vendor, scanner, and security team in the world. When someone says “patch CVE-2021-44228”, everyone involved knows they mean the Log4Shell flaw in Apache Log4j, not some other logging bug.

That shared name is the entire point. Before the CVE program launched in 1999, every security vendor described the same flaw its own way, and matching your scanner’s alert to your vendor’s advisory was guesswork. The CVE list turned that mess into a common language.

This guide covers what the ID actually tells you, who hands them out, and, since more than 40,000 new ones now arrive every year, how a small team decides which ones deserve attention this week.

What does CVE stand for?

CVE stands for Common Vulnerabilities and Exposures. The program is run by the MITRE Corporation with funding from the US Department of Homeland Security through CISA. Despite the American funding, it functions as the global standard: vendors from every region request and assign CVE IDs.

Two terms inside the acronym are worth separating:

• A vulnerability is a flaw in code or design that an attacker can use to break a security property: run their own code, read data they should not see, escalate privileges.
• An exposure is a weaker condition, something that gives an attacker a foothold or information without being an outright flaw.

In practice nearly everything on the list today is a vulnerability, and people use “a CVE” loosely to mean “a publicly catalogued vulnerability.”

How a CVE ID is structured

Every ID follows the same pattern:

CVE-2021-44228
 |     |     |
 |     |     +-- sequence number (4 or more digits)
 |     +-------- year the ID was assigned or reserved
 +-------------- literal "CVE" prefix

Two details trip people up:

• The year is when the ID was assigned or reserved, not necessarily when the flaw was found or disclosed. A bug discovered in December can carry the next year’s prefix, and research published years later can carry an old one.
• The sequence number says nothing about severity. CVE-2024-3400 is not milder than CVE-2024-21887 because the number is smaller. Severity lives in separate scoring systems, mainly CVSS.

Who assigns CVE IDs?

Not a central committee. The program delegates assignment to CVE Numbering Authorities (CNAs): software vendors, security companies, research organizations, and national CERTs authorized to issue IDs for flaws in their own scope. Microsoft assigns IDs for Windows bugs, Red Hat for its distributions, and so on. There are now several hundred CNAs across dozens of countries, with MITRE acting as the root authority and the assigner of last resort.

The practical consequence: anyone can report a vulnerability, but the ID usually comes from the vendor whose product is affected. If you find a flaw in a product whose vendor is a CNA, you report it to them; if there is no responsible CNA, you can request an ID from MITRE directly.

The life of a CVE record

A CVE passes through a small number of states, and knowing them explains some confusing moments:

1. Reserved. An ID exists but details are withheld, usually while the vendor builds a patch under coordinated disclosure. If you look up a reserved CVE and find an empty page, that is normal, not a cover-up.
2. Published. The description, affected products, and references go public. From this moment scanners and security teams can act on it.
3. Rejected or disputed. Some entries turn out to be duplicates, not actually flaws, or contested by the vendor. The record stays, marked accordingly, so the ID is never reused.

After publication, the NVD (National Vulnerability Database), run by NIST, enriches the record with a CVSS severity score, affected-product identifiers, and links. This is why most teams read CVEs through NVD or a tool built on it rather than the raw CVE list: cve.org tells you the flaw exists, NVD tells you how bad it might be and exactly which versions are affected.

Not every vulnerability gets a CVE

The inverse of the definition matters just as much. A CVE catalogues flaws in published, shared software. Whole classes of real-world risk never receive one:

• Vulnerabilities in your own custom code, internal apps, and APIs.
• Misconfigurations: the world-readable storage bucket, the admin panel with no MFA, the default credential nobody rotated.
• Business-logic flaws unique to your workflows.

Scanning for CVEs answers “which known flaws in third-party software am I running?” It says nothing about the categories above; those are found by penetration testing and configuration review. A clean CVE scan is not a clean bill of health.

How many CVEs are there, and why the count matters

The pace is the core operational problem. The program crossed 40,000 new CVEs published in a single year in 2024, a record, and the volume has kept climbing since; the running totals are public on the CVE program’s metrics page. That averages out to well over a hundred new entries every day, weekends included.

No team patches at that rate, and no team needs to. Three numbers put the flood in perspective:

• Only a small minority of CVEs ever see exploit code in the wild.
• CISA’s Known Exploited Vulnerabilities catalog, the confirmed in-the-wild list, holds roughly 1,300 entries against the 200,000+ catalogued overall: well under 1%.
• EPSS, the exploit-prediction model from FIRST, scores most CVEs near zero probability of exploitation in the next 30 days.

The takeaway: the existence of a CVE is a fact about software, not an instruction to act. The instruction comes from matching CVEs against what you actually run, then ranking by exploitation evidence. We walk through that ranking logic, CVSS against EPSS against KEV, in our prioritization guide.

What a small team should do about CVEs

A workable CVE process for a team without a dedicated security function fits in four steps:

1. Know what you run. An asset and software inventory is the prerequisite for everything. A CVE in software you do not run is noise.
2. Match continuously. New CVEs land daily; quarterly scans leave months of exposure. Continuous matching of published CVEs against your inventory turns the flood into a short, relevant list.
3. Rank by evidence, not by score alone. KEV-listed first, high-EPSS second, raw CVSS after that. This ordering puts the CVEs in active use ahead of the ones that merely look scary.
4. Set patch deadlines by tier. For example: KEV-listed flaws in internet-facing systems within 48 hours, high-EPSS within the sprint, the rest in the monthly cycle. Deadlines you can keep beat aspirations you cannot.

Quick answers

Is every CVE dangerous? No. Severity ranges from negligible to critical, and even critical-rated CVEs are mostly never exploited. Treat the ID as a name, not a verdict.

Can I look up a CVE for free? Yes. The authoritative record is at cve.org, and NVD adds severity scoring and affected versions, both free.

Who can request a CVE ID? Anyone who finds a qualifying flaw in published software. Report it to the affected vendor if they are a CNA, or to MITRE otherwise.

Does a CVE mean a patch exists? No. CVEs are regularly published before a fix ships, and some never receive one. The record’s references list the vendor advisory when there is one.

What is the difference between CVE and CVSS? CVE is the name of the flaw; CVSS is a 0 to 10 score estimating how severe it would be if exploited. One identifies, the other rates.