Cybersecurity

What is a CVE? Understanding Common Vulnerabilities and Exposures

Learn what CVE identifiers are, how they work, and why they're essential for cybersecurity. Understand the CVE ID format, who assigns them, and how they help organizations track and fix security vulnerabilities.

By Inventive HQ Team

A CVE (Common Vulnerabilities and Exposures) is a unique, permanent identifier assigned to a publicly disclosed security flaw in software or hardware — formatted CVE-YYYY-NNNNN, like CVE-2021-44228 (Log4Shell). It is run by the MITRE Corporation and funded by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). The CVE ID is only a name: it lets every vendor, scanner, patch tool, and researcher point at the exact same flaw without ambiguity. Severity, affected versions, and fix guidance come from other systems (CVSS, CWE, CPE) that reference the CVE.

That's the definition an AI Overview will hand you. What it can't show you is the shape of the thing — how a CVE ID is actually built, where an ID sits in the vulnerability lifecycle, and how CVE differs from the half-dozen acronyms it travels with. The diagrams and tables below do that.

What is CVE?

CVE stands for Common Vulnerabilities and Exposures. It's a standardized identification system for publicly known cybersecurity vulnerabilities in software and hardware.

Anatomy of a CVE identifier The identifier CVE-2021-44228 broken into its three parts: the CVE prefix, the assignment year 2021, and the sequence number 44228. Anatomy of a CVE ID Log4Shell, one of the most exploited flaws ever CVE Fixed prefix "it's a CVE"

-

2021 Year ID was assigned not the discovery year

-

44228 Sequence number (4+ digits) sequential, not a ranking

Think of CVE as a universal language for security vulnerabilities—like a Social Security Number for security flaws. When a vulnerability is discovered, it receives a unique CVE ID that everyone in the security community can use to reference that specific issue.

Key points:

  • CVE provides a standard naming convention
  • Makes vulnerability tracking consistent across tools and databases
  • Operated by MITRE Corporation with U.S. government funding
  • Launched publicly in September 1999

CVE ID Format Explained

Every CVE ID follows this structure:

CVE-YYYY-NNNNN

Breaking it down:

  • CVE – Identifies this as a CVE identifier
  • YYYY – The year the CVE was assigned (not necessarily when discovered)
  • NNNNN – A unique sequential number (originally 4 digits, now 5+ as volume increased)

Examples:

  • CVE-2024-12345 – The 12,345th CVE assigned in 2024
  • CVE-2014-0160 – The famous "Heartbleed" vulnerability
  • CVE-2021-44228 – "Log4Shell", one of the most critical vulnerabilities ever

Important note: The year reflects when the CVE ID was assigned, not when the vulnerability was discovered or disclosed. Sometimes there's a lag between discovery and public assignment.

What Information Does a CVE Provide?

Each CVE entry contains:

1. CVE ID

The unique identifier (e.g., CVE-2024-12345)

2. Description

A brief explanation of the vulnerability:

  • What software/hardware is affected
  • What type of vulnerability it is
  • What could happen if exploited

Example:

"A buffer overflow in XYZ Web Server 1.0-3.5 allows remote attackers to execute arbitrary code via a crafted HTTP request."

3. References

Links to additional information:

  • Vendor advisories
  • Patch releases
  • Security research
  • Proof-of-concept exploits

4. Status

  • Reserved: CVE ID assigned but details not yet public
  • Published: Information available
  • Rejected: Determined not to be a valid vulnerability
  • Disputed: Disagreement about whether it's a real vulnerability

Who Assigns CVE IDs?

The CVE system operates through a network of organizations:

MITRE Corporation

The primary CVE Numbering Authority (CNA) and system operator. MITRE:

  • Maintains the CVE List
  • Manages CVE ID assignments
  • Ensures quality and consistency
  • Provides the central CVE database

CVE Numbering Authorities (CNAs)

Organizations authorized to assign CVE IDs within their scope. As of 2025, there are over 350 CNAs across 40+ countries, including:

Vendors:

  • Microsoft
  • Apple
  • Google
  • Oracle
  • Cisco

Security organizations:

  • CERT Coordination Center
  • JPCERT/CC (Japan)
  • CNCERT (China)

Open source projects:

  • Linux distributions
  • Apache Software Foundation
  • Python Software Foundation

Why multiple CNAs?

  • Speeds up CVE assignment
  • Vendors can assign IDs for their own products
  • Reduces bottlenecks
  • Ensures global coverage

CVE vs. Other Vulnerability Identifiers

CVE isn't the only vulnerability identifier system:

SystemWhat it namesExampleWhen you reach for it
CVEA specific, disclosed flawCVE-2021-44228Talking about one exact vulnerability across teams and tools
CVSSHow severe that flaw is (0.0–10.0)9.8 CriticalRanking what to patch first
CWEThe type of weaknessCWE-502 (unsafe deserialization)Root-cause analysis and secure-coding fixes
CPEThe affected product/versioncpe:2.3:a:apache:log4j:2.14.1Matching a CVE to your actual inventory
OVALA machine test for presenceoval:...:def:12345Automated scanning that checks "am I vulnerable?"
Which should I use?Start with the CVE to identify the flaw, then use CVSS to prioritize, CPE to confirm it affects you, and CWE to fix the underlying pattern

CVE is the foundation every other system hangs off. A single published CVE typically carries a CVSS score, one or more CWE mappings, and a list of affected CPEs — all keyed to that one ID.

Why CVE Matters for Your Organization

1. Universal Communication

When Microsoft says "patch CVE-2024-12345," everyone knows exactly which vulnerability they mean. No confusion, no ambiguity.

2. Tool Integration

Security tools use CVE IDs to identify vulnerabilities:

  • Vulnerability scanners report CVEs found
  • Security information and event management (SIEM) systems correlate CVEs
  • Patch management tools prioritize by CVE severity
  • Threat intelligence feeds reference CVEs
Advertisement

3. Compliance Requirements

Many frameworks require CVE tracking:

  • PCI DSS: Requires patching critical vulnerabilities
  • HIPAA: Mandates vulnerability management
  • ISO 27001: Requires vulnerability assessment
  • NIST: References CVEs in security controls

4. Risk Assessment

CVE IDs link to:

  • CVSS severity scores
  • Exploit availability
  • Affected versions
  • Patch availability

This helps prioritize what to fix first.

5. Historical Tracking

CVE IDs create an audit trail:

  • When was the vulnerability discovered?
  • When did we patch it?
  • Which systems were affected?
  • How did we respond?

How CVE Fits into the Vulnerability Lifecycle

A CVE ID is often born before the public ever hears about the flaw. It is reserved during private coordinated disclosure, sits dormant while a patch is built, and only flips to "Published" on release day — after which the NVD enriches it. Here's the path from discovery to remediation:

CVE vulnerability lifecycle Six stages: discovery, CVE reserved, coordination and patch development, public disclosure and CVE published, NVD enrichment with CVSS, and remediation. From discovery to patched PRIVATE (coordinated disclosure) PUBLIC 1 Discovery
<circle cx="285" cy="130" r="26" fill="#f8fafc" stroke="#2813e8" stroke-width="2"/>
<text x="285" y="134" font-weight="700">2</text>
<text x="285" y="172">CVE ID</text>
<text x="285" y="188" fill="#b91c1c">reserved</text>

<circle cx="475" cy="130" r="26" fill="#f8fafc" stroke="#2813e8" stroke-width="2"/>
<text x="475" y="134" font-weight="700">3</text>
<text x="475" y="172">Disclosed +</text>
<text x="475" y="188" fill="#15803d">published</text>

<circle cx="600" cy="130" r="26" fill="#f8fafc" stroke="#f59e0b" stroke-width="2"/>
<text x="600" y="134" font-weight="700">4</text>
<text x="600" y="172">NVD adds</text>
<text x="600" y="188">CVSS + CWE</text>

<circle cx="700" cy="130" r="26" fill="#f8fafc" stroke="#15803d" stroke-width="2"/>
<text x="700" y="134" font-weight="700">5</text>
<text x="700" y="178">Patched</text>

The CVE exists at step 2 — but stays hidden until the vendor is ready at step 3. Severity (CVSS) doesn't attach until step 4, days to weeks later.

1. Discovery Someone finds a security flaw (researcher, vendor, attacker)

2. CVE Request Reporter or CNA requests a CVE ID (often done privately before public disclosure)

3. CVE Assignment CNA assigns CVE-YYYY-NNNNN (CVE may be "reserved" initially)

4. Coordination Vendor develops patch while CVE details remain private (responsible disclosure)

5. Public Disclosure CVE details published, patches released, CVE status changes to "Published"

6. Enrichment NVD adds CVSS scores, CWE mappings, and detailed analysis

7. Remediation Organizations patch systems, security tools scan for CVE, compliance verified

CVE Growth Over Time

The number of CVEs assigned has grown exponentially:

  • 1999-2005: ~5,000 CVEs/year
  • 2010: ~4,600 CVEs
  • 2015: ~6,500 CVEs
  • 2020: ~18,000 CVEs
  • 2024: ~34,000+ CVEs
  • Total (mid-2025): Over 296,000 CVE records

Why the growth?

  • More software being developed
  • More researchers looking for vulnerabilities
  • Better reporting mechanisms
  • Increased awareness of security
  • More CNAs assigning CVEs faster

Common Misconceptions

Myth 1: "CVE = Severity"

False. CVE is just an identifier. Severity comes from CVSS scores (managed by NVD) or vendor assessments.

Myth 2: "All vulnerabilities get CVEs"

False. Only publicly disclosed vulnerabilities receive CVEs. Internal bugs or unreported issues don't get CVE IDs.

Myth 3: "CVE year = discovery year"

False. The year indicates when the CVE was assigned, not when discovered. A 2024 CVE might be for a vulnerability discovered in 2023.

Myth 4: "CVEs are ranked"

False. CVE numbers are sequential, not ranked. CVE-2024-00001 isn't necessarily worse than CVE-2024-99999.

Myth 5: "Fix all CVEs immediately"

False. Not all CVEs affect you. Prioritize based on:

  • Whether you use the affected software
  • Whether it's exploitable in your environment
  • CVSS score and exploit availability
  • Business risk

How to Use CVE Information

For Security Teams:

  1. Subscribe to CVE feeds for your technology stack
  2. Scan systems for CVE presence
  3. Prioritize patching based on CVE severity and exploit availability
  4. Track CVE remediation in ticketing systems
  5. Report CVEs in compliance documentation

For IT Administrators:

  1. Check vendor advisories for CVE patches
  2. Test patches in development before production
  3. Schedule maintenance for CVE remediation
  4. Document patching with CVE references
  5. Monitor for CVE exploits in IDS/IPS

For Developers:

  1. Review dependencies for known CVEs
  2. Use CVE scanning tools in CI/CD pipelines
  3. Update libraries with CVE fixes
  4. Reference CVEs in security notes
  5. Report vulnerabilities to get CVE assigned

CVE Resources

Official sources:

Search tools:

Mailing lists:

  • Full CVE disclosure lists
  • Vendor-specific security announcements
  • Product security lists (like oss-security)

Conclusion

CVE identifiers are the foundation of modern vulnerability management. They provide a universal language that enables security teams, vendors, researchers, and tools to communicate clearly about specific security issues.

Understanding CVE helps you:

  • Track vulnerabilities systematically
  • Prioritize security work effectively
  • Communicate clearly with stakeholders
  • Meet compliance requirements
  • Integrate security tools efficiently

Whether you're a security professional, system administrator, or developer, CVE IDs are an essential part of managing cybersecurity risk.


Need to look up a CVE? Use our CVE Lookup tool to search the National Vulnerability Database, calculate CVSS scores, and access detailed remediation guidance.

Frequently Asked Questions

What does CVE stand for?

CVE stands for Common Vulnerabilities and Exposures. It is a free, publicly available catalog of known security flaws in software and hardware, run by the MITRE Corporation and funded by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Each entry gets a unique CVE ID so every vendor, scanner, and researcher refers to the same flaw by the same name.

What does a CVE ID look like?

A CVE ID follows the format CVE-YYYY-NNNNN, for example CVE-2021-44228 (Log4Shell). YYYY is the year the ID was reserved or assigned, and NNNNN is a sequential number that is at least four digits and grows as needed (Log4Shell used five). The number is not a ranking and the year is not the discovery date.

Is a CVE the same as a severity score?

No. A CVE is only an identifier — it tells you which flaw is being discussed, not how dangerous it is. Severity comes from a separate system, CVSS (Common Vulnerability Scoring System), which produces a 0.0–10.0 score. The NVD adds a CVSS score to most CVEs after they are published, but the CVE ID itself carries no severity.

Who assigns CVE IDs?

CVE IDs are assigned by CVE Numbering Authorities (CNAs) — organizations authorized by the CVE Program to issue IDs within a defined scope. There are more than 350 CNAs, including vendors like Microsoft, Apple, and Google who assign IDs for their own products, plus MITRE itself as the "CNA of last resort" for anything not covered by another authority.

What is the difference between CVE and NVD?

The CVE List (run by MITRE) is the authoritative catalog of vulnerability IDs and short descriptions. The NVD (National Vulnerability Database, run by NIST) ingests every CVE and enriches it with CVSS scores, CWE weakness mappings, and affected-product data (CPE). Put simply: MITRE names the flaw, NVD analyzes it.

Does every security vulnerability get a CVE?

No. Only publicly disclosed vulnerabilities that fall within a CNA's scope receive CVE IDs. Internal bugs, unreported issues, and flaws in products not covered by any CNA may never get an ID. A missing CVE does not mean a product is secure.

What does "CVE Reserved" mean?

"Reserved" means a CVE ID has been allocated but its details are not yet public — usually because a vendor is still building a patch under coordinated disclosure. Once the patch ships and details are released, the status changes to "Published." Other statuses include Rejected (not a real vulnerability) and Disputed (parties disagree it is a flaw).

Should I patch every CVE that affects my software?

Not necessarily, and not all at once. Prioritize by real risk: whether you actually run the affected component, whether it is reachable and exploitable in your environment, the CVSS score, and — most importantly — whether it is being actively exploited (check CISA's Known Exploited Vulnerabilities catalog). A high CVE count is normal; a smart patch order is the goal.

CVEvulnerabilitiessecurityNVDMITRE