How CVEs Work: Understanding the Vulnerability Identification System

When the Log4Shell vulnerability hit in December 2021, the entire internet scrambled to figure out if they were affected. The vulnerability had a name that stuck in the news cycle, but more importantly, it had an identifier: CVE-2021-44228. That seven-character prefix - CVE - represents a system that has been cataloging security vulnerabilities since 1999, and understanding how it works is fundamental to working in cybersecurity.

CVE stands for Common Vulnerabilities and Exposures. It is a standardized naming system for publicly known security vulnerabilities. Each vulnerability gets a unique identifier (like CVE-2021-44228) that serves as a universal reference point - when a vendor publishes a patch, a security scanner flags a finding, or a researcher writes an advisory, they all reference the same CVE ID.

What Is a CVE?

A CVE entry is surprisingly minimal. It contains:

• CVE ID: The unique identifier in the format CVE-YYYY-NNNNN (year of assignment, sequential number)
• Description: A brief text describing the vulnerability
• References: Links to advisories, patches, and related information
• Status: Reserved (ID assigned but details not yet public), Published, or Rejected

That is it. A CVE entry does not include severity scores, exploit code, affected version details, or remediation guidance. Those come from other sources that reference the CVE - most notably the National Vulnerability Database (NVD), which enriches CVE entries with CVSS scores and detailed metadata.

The CVE system is maintained by the MITRE Corporation, funded by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). It has been the backbone of vulnerability management since its creation, despite ongoing debates about its scope and scalability.

CVE Numbering Authorities

graph TD
    subgraph TopLevel["CVE Program Structure"]
        MITRE[MITRE - CVE Program Root]
        CISA[CISA - Sponsor]
    end
    subgraph RootCNAs["Root CNAs"]
        R1[MITRE Root CNA]
        R2[CISA Root CNA]
    end
    subgraph TopLevelCNAs["Top-Level CNAs"]
        T1[JPCERT/CC - Japan]
        T2[BSI - Germany]
        T3[INCIBE - Spain]
    end
    subgraph RegularCNAs["Regular CNAs - 300+"]
        C1[Microsoft]
        C2[Google]
        C3[Apple]
        C4[Red Hat]
        C5[Oracle]
        C6[Apache]
        C7[GitHub]
        C8[Siemens]
        C9[...hundreds more]
    end
    subgraph Researchers["Researchers"]
        RE1[Independent Researchers]
        RE2[Security Firms]
        RE3[Academics]
    end
    CISA --> MITRE
    MITRE --> R1
    MITRE --> R2
    R1 --> T1
    R1 --> T2
    R1 --> T3
    T1 --> C1
    R1 --> C2
    R1 --> C3
    R1 --> C4
    R1 --> C5
    R1 --> C6
    R1 --> C7
    T2 --> C8
    RE1 -->|"Request CVE"| R1
    RE2 -->|"Request CVE"| C1
    RE3 -->|"Request CVE"| R1

The CVE assignment hierarchy - over 300 CNAs can assign CVE IDs within their scope

CVE Numbering Authorities (CNAs) are organizations authorized to assign CVE IDs within their defined scope. There are over 300 CNAs worldwide, organized in a hierarchy:

The CVE Program (MITRE) manages the overall program, defines the rules, and acts as the "CNA of last resort" for vulnerabilities that no other CNA covers.

Root CNAs manage groups of other CNAs within their scope. CISA serves as a root CNA for the U.S. government and its ecosystem.

Regular CNAs assign CVEs for vulnerabilities in their own products or their defined scope. Microsoft assigns CVEs for Microsoft products. Google assigns CVEs for Google products and Android. Red Hat assigns CVEs for Red Hat products. And so on.

GitHub is a notable CNA because it can assign CVEs for any open-source project hosted on GitHub, making it easier for open-source maintainers to get CVE IDs without going through MITRE directly.

When you discover a vulnerability, the CNA you request a CVE from depends on the affected product:

• Vulnerability in a Microsoft product? Request from Microsoft's CNA
• Vulnerability in an open-source project on GitHub? Request through GitHub's CNA
• Vulnerability in a product whose vendor is not a CNA? Request from MITRE or CISA

The CVE Lifecycle

A CVE entry goes through several stages from discovery to publication:

1. Discovery: A researcher, vendor, or automated system discovers a vulnerability.

2. CVE ID Request: Someone requests a CVE ID from the appropriate CNA. This can happen before or after the vulnerability is publicly known. Many vendors request CVE IDs during the patch development process so they can include the ID in their security bulletin.

3. Reservation: The CNA assigns a CVE ID with "Reserved" status. At this point, the ID exists but the details are not public. Reserved CVEs are placeholders - they tell the community "a vulnerability has been identified but details are pending."

4. Publication: When the vulnerability is publicly disclosed (typically when a patch is available), the CNA updates the CVE entry with a description and references. The status changes to "Published."

5. NVD Enrichment: The NVD team analyzes the published CVE and adds CVSS scores, CPE (Common Platform Enumeration) data identifying affected products, and additional references. This enrichment process can take days to weeks after initial publication.

6. Ongoing Updates: CVE entries can be updated as new information becomes available - additional affected products, corrected descriptions, new references, or changed CVSS scores.

Rejection: Some CVE IDs are rejected if the reported issue is not actually a vulnerability, is a duplicate of an existing CVE, or does not meet CVE assignment criteria. Rejected IDs are not reused.

CVSS Scoring Explained

The Common Vulnerability Scoring System (CVSS) provides a numerical score (0.0 to 10.0) that represents the severity of a vulnerability. The current version is CVSS v4.0, though v3.1 scores are still widely used.

graph TD
    subgraph BaseMetrics["CVSS Base Metrics"]
        subgraph Exploitability["Exploitability Metrics"]
            AV[Attack Vector\nNetwork/Adjacent/Local/Physical]
            AC[Attack Complexity\nLow/High]
            PR[Privileges Required\nNone/Low/High]
            UI[User Interaction\nNone/Required]
        end
        subgraph Impact["Impact Metrics"]
            C[Confidentiality\nNone/Low/High]
            I[Integrity\nNone/Low/High]
            A[Availability\nNone/Low/High]
        end
        S[Scope\nUnchanged/Changed]
    end
    subgraph Scoring["Score Ranges"]
        CR[Critical: 9.0-10.0]
        HI[High: 7.0-8.9]
        MD[Medium: 4.0-6.9]
        LO[Low: 0.1-3.9]
        NO[None: 0.0]
    end
    Exploitability --> S
    Impact --> S
    S --> CR
    S --> HI
    S --> MD
    S --> LO
    S --> NO

CVSS v3.1 base metrics and their possible values - these combine mathematically into the final score

CVSS consists of three metric groups:

Base Score (the number everyone references)

The base score captures the intrinsic characteristics of the vulnerability. It does not change over time. The metrics:

Attack Vector (AV): How the attacker reaches the vulnerable component. Network (remotely exploitable - most dangerous), Adjacent (requires same network segment), Local (requires local system access), or Physical (requires physical access to the device).

Attack Complexity (AC): How difficult the attack is to execute. Low (no special conditions needed) or High (requires specific configuration, race conditions, or other prerequisites).

Privileges Required (PR): What level of access the attacker needs before exploitation. None (unauthenticated), Low (regular user), or High (administrator).

User Interaction (UI): Whether exploitation requires a victim to do something. None (fully autonomous) or Required (victim must click a link, open a file, etc.).

Scope (S): Whether exploiting the vulnerability affects resources beyond the vulnerable component. Unchanged (impact limited to the vulnerable component) or Changed (impact extends to other components). A web server vulnerability that allows reading files from the underlying OS has changed scope.

Confidentiality, Integrity, Availability (C, I, A): The impact on each security property. None (no impact), Low (limited impact), or High (total loss of that property).

Example: Log4Shell (CVE-2021-44228)

CVSS 3.1 Score: 10.0 (Critical)

• AV: Network (exploitable remotely via crafted log messages)
• AC: Low (no special conditions needed)
• PR: None (no authentication required)
• UI: None (no victim interaction needed)
• S: Changed (can execute code on the underlying server)
• C: High (full server access)
• I: High (can modify anything)
• A: High (can crash or destroy)

Temporal Score

Adjusts the base score based on factors that change over time: whether exploit code exists, whether a patch is available, and the confidence in the vulnerability report. Temporal scores are used less frequently because they require ongoing maintenance.

Environmental Score

Allows organizations to customize the score based on their specific environment. If a vulnerability affects a component that is not deployed in your network, the environmental score would be lower than the base score. Most organizations do not use environmental scores systematically.

The National Vulnerability Database

The National Vulnerability Database (NVD), maintained by NIST, is the U.S. government's repository of vulnerability management data. It builds on CVE by adding:

CVSS scores: The NVD provides official CVSS scores for most published CVEs. These scores are calculated by NVD analysts, and sometimes differ from scores provided by the CNA (vendor). When there is a disagreement, both scores may be listed.

CPE data: Common Platform Enumeration entries identify exactly which products and versions are affected. CPE uses a structured naming scheme like cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:* that vulnerability scanners use for automated matching.

CWE classification: Each CVE is mapped to a Common Weakness Enumeration (CWE) identifier that categorizes the type of vulnerability. CWE-79 is cross-site scripting, CWE-89 is SQL injection, CWE-787 is out-of-bounds write, and so on.

References: Links to vendor advisories, patches, exploit databases, and related information.

The NVD provides this data through a web interface (nvd.nist.gov) and APIs that vulnerability management tools use to check whether your software has known vulnerabilities. Nessus, Qualys, OpenVAS, and similar scanners all consume NVD data.

NVD processing backlog: In recent years, the NVD has struggled with a significant processing backlog. New CVEs can take weeks or months to receive CVSS scores and CPE data from NVD. This has led to growing reliance on CNA-provided scores and alternative vulnerability databases like OSV (for open source) and VulnCheck.

Looking Up Product Vulnerabilities

Knowing how to research vulnerabilities in specific products is a core security skill. Here is how to do it effectively:

NVD Search (nvd.nist.gov): Search by keyword, CVE ID, or CPE name. The advanced search lets you filter by CVSS score range, date range, and vulnerability type. This is the primary reference for most security professionals.

CVE.org: The official CVE list. Less enriched than NVD but more authoritative for CVE metadata. Useful when NVD data is delayed.

Vendor security pages: Most major vendors maintain their own security advisory pages. Microsoft's Security Response Center (MSRC), Apple's security updates page, and Cisco's Security Advisories are examples. These often provide more detailed information than the CVE/NVD entries.

Exploit-DB (exploit-db.com): Maintained by OffSec, this database archives publicly available exploit code indexed by CVE. Useful for penetration testers who need to test specific vulnerabilities in lab environments.

GitHub Advisory Database: Specifically for open-source vulnerabilities. GitHub's database is often updated faster than NVD for open-source projects and includes dependency information that helps developers assess their exposure.

OSV (Open Source Vulnerabilities): A distributed vulnerability database for open source, run by Google. It uses a standardized format and covers multiple ecosystems (npm, PyPI, Go, Maven, etc.).

For hands-on vulnerability research and validation, tools that interact with actual systems provide context that database entries cannot. The BLEShark Nano lets you examine real wireless protocols and configurations, which is valuable when researching CVEs that affect WiFi or BLE implementations - you can see how vulnerable configurations actually behave in practice.

Limitations of the CVE System

The CVE system is imperfect. Understanding its limitations helps you use it more effectively:

Not all vulnerabilities get CVEs. The CVE system primarily covers software vulnerabilities in products with identifiable vendors. Configuration errors, cloud misconfigurations, zero-days held by intelligence agencies, and vulnerabilities in obscure products may never receive CVE IDs.

CVE volume is growing faster than analysis capacity. Over 28,000 CVEs were published in 2023 alone, up from roughly 18,000 in 2020. The NVD and the broader vulnerability management ecosystem are struggling to keep pace. Many CVEs receive minimal analysis.

CVSS scores are imperfect. A CVSS score is a mathematical model of severity, not a real-world risk assessment. A CVSS 9.8 vulnerability in a niche application used by 50 organizations is less impactful than a CVSS 7.5 vulnerability in software running on millions of servers. CVSS does not account for prevalence, exploitability in the wild, or value of the affected assets.

Duplicate and disputed CVEs exist. Sometimes the same vulnerability receives multiple CVE IDs from different CNAs. Sometimes CNAs and NVD disagree on whether something qualifies as a vulnerability. The system handles disputes, but resolution can be slow.

Timing varies widely. Some CVEs are published months before a patch is available. Others are published simultaneously with a patch. And some vulnerabilities are exploited in the wild long before they receive a CVE. The CVE publication date is not a reliable indicator of when a vulnerability was first known or exploited.

Using CVE Data in Practice

Vulnerability management programs use CVE data to track which known vulnerabilities exist in their environment, prioritize patching based on severity and exploitability, and report on their security posture. Scanners like Nessus and Qualys cross-reference installed software against NVD data to generate findings.

Penetration testers use CVE data to identify known vulnerabilities in target systems and find available exploit code. The CVE-to-Metasploit module mapping is a standard workflow during engagements.

Security researchers use CVE data to track vulnerability trends, identify recurring weakness patterns in specific products, and find research targets. Analyzing which CWE types are most common in a product category can guide research priorities.

Developers use CVE data (often through tools like Dependabot, Snyk, or npm audit) to identify vulnerable dependencies in their projects and prioritize updates.

Incident responders use CVE data to identify the vulnerability exploited in an attack, understand its impact, and determine the appropriate remediation steps.

The CVE system is not perfect, but it remains the closest thing the security industry has to a universal language for vulnerabilities. Understanding how it works - its strengths, its processes, and its limitations - is essential knowledge for anyone working in cybersecurity.