Common Vulnerabilities and Exposures
Common Vulnerabilities and Exposures (CVE) is a public dictionary that catalogs cybersecurity vulnerabilities with unique identifiers, descriptions, and references for each entry, enabling standardized tracking and mitigation of publicly disclosed security flaws in software, hardware, and firmware.[1] The system assigns identifiers in the format CVE-YYYY-NNNN to avoid duplicate naming and facilitate interoperability among vulnerability management tools and databases.[2] Initiated in 1999 under the auspices of the U.S. Department of Defense and later sponsored by the Department of Homeland Security, the CVE program is administered by the MITRE Corporation as the CVE Numbering Authority (CNA) and secretariat, overseeing a network of partner organizations that nominate and validate entries.[3][4] By providing a common nomenclature, CVE has become foundational to global vulnerability disclosure and response efforts, integrated into frameworks like the National Vulnerability Database (NVD) maintained by NIST for enriched analysis including severity scores.[5] Over its 25-year history, the program has processed hundreds of thousands of records, significantly enhancing cybersecurity by promoting timely identification and patching of exploitable weaknesses.[6] Despite its successes, the CVE program faces ongoing challenges such as scaling to handle surging vulnerability reports, ensuring equitable participation from CNAs, and addressing funding dependencies that have periodically strained operations.[7] These issues underscore the need for sustained public-private collaboration to maintain the program's reliability amid evolving threats like supply chain attacks and zero-day exploits.[8]History
Origins in the Late 1990s
In the late 1990s, the rapid expansion of internet connectivity and software deployment led to a surge in publicly disclosed cybersecurity vulnerabilities, complicating efforts by security professionals to track and mitigate them consistently. Vendor-specific vulnerability databases proliferated, resulting in fragmented nomenclature and duplicated identifiers that hindered interoperability among scanning tools and threat intelligence sharing.[9][10] To address this, the MITRE Corporation, a nonprofit research organization, initiated the Common Vulnerabilities and Exposures (CVE) program as a standardized reference system for vulnerability identification. The concept was developed by MITRE researchers David E. Mann and Steven M. Christey, who proposed a unique, sequential numbering scheme to provide a common lexicon independent of vendor or tool-specific terminology.[3][7] The CVE List was officially launched to the public on September 7, 1999, during a MITRE press conference, featuring an initial set of 321 curated vulnerability records retroactively assigned identifiers from CVE-1999-0001 onward. This inaugural release drew from existing public disclosures to establish a foundational dictionary, enabling cross-referencing in security products and reports.[3][9][6]Establishment and Early Development
The CVE program was formally established in 1999 through the efforts of the MITRE Corporation, which convened a working group and formed an initial 19-member CVE Editorial Board to standardize vulnerability naming.[3] This board curated the original 321 CVE records, selected after reviewing thousands of vulnerability reports to eliminate duplicates and ensure comprehensive coverage of known issues in software and systems.[3] The list was officially launched for public access in September 1999, marking the transition from conceptual planning to operational deployment under MITRE's management.[3] [6] Early development emphasized collaboration and integration into security practices, with sponsorship from U.S. government entities including the National Institute of Standards and Technology (NIST) and the Defense Information Systems Agency (DISA).[3] By December 2000, 29 organizations had declared compatibility with the CVE list across 43 products, facilitating its adoption in vulnerability scanning tools and databases.[3] In 2002, NIST's Special Publication 800-51 explicitly recommended CVE usage for vulnerability management, providing federal guidance that accelerated institutional uptake.[3] Further solidification occurred in 2004 when DISA issued a task order mandating CVE identifiers in information assurance applications, embedding the system into military and government workflows.[3] During this period, MITRE handled all CVE assignments as the sole editor, processing submissions manually while refining criteria for entry inclusion, such as requiring public disclosure and verifiable impact.[6] This phase laid the groundwork for scalable operations, though growth was gradual, with the list expanding incrementally as awareness spread among cybersecurity vendors and researchers.[3]Key Milestones and Expansion
In the early 2000s, the CVE program gained institutional traction through endorsements by U.S. government bodies. The National Institute of Standards and Technology (NIST) recommended CVE identifiers in Special Publication 800-51, Guidelines on Security Certification and Accreditation of Information Technology Systems, published in 2002 (updated in 2011).[3] In June 2004, the Defense Information Systems Agency (DISA) required their use in information assurance vulnerability management applications.[3] International recognition followed, with the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) incorporating CVE into Recommendation X.1520, Guideline for evaluation and authorization of ICT security products, in 2011.[3] To address the impending exhaustion of four-digit sequence numbers (limiting assignments to 9,999 per year), the CVE program introduced a variable-length ID syntax in 2014, allowing up to 20 digits in the sequence field for scalability; this change took effect for new assignments as needed beyond CVE-2014-9999.[11] A pivotal expansion began in 2016, when the program actively scaled its network of CVE Numbering Authorities (CNAs)—organizations authorized to assign CVE IDs—from 24 participants to over 400 by 2024, distributed across 40 countries, decentralizing vulnerability identification and accelerating cataloging.[3][6] This growth paralleled a surge in the CVE record count, from the initial 321 entries in 1999 to over 240,000 by October 2024, reflecting broader adoption in vulnerability databases, tools, incident response, and policy frameworks worldwide.[6] In September 2025, under Cybersecurity and Infrastructure Security Agency (CISA) sponsorship, the program shifted toward a "Quality Era," emphasizing enhanced data accuracy, governance, collaboration, and responsiveness to sustain trust amid rising vulnerability volumes.[12]Technical Specifications
CVE Identifier Format and Syntax
The CVE identifier, commonly referred to as a CVE ID, follows a fixed syntax of "CVE-" prefixed to a four-digit year, followed by a hyphen and a variable-length sequence of decimal digits. The year component (YYYY) indicates the calendar year in which the ID was allocated or reserved by a CVE Numbering Authority (CNA), rather than the year of vulnerability discovery or public disclosure.[13] This allocation occurs during the initial coordination phase, prior to publication, ensuring timely referencing for vulnerability management.[14] The sequence number (N) begins as a four-digit value starting from "0001" in each year but expands dynamically with additional digits as the volume of assignments increases, without fixed padding or truncation. For instance, early identifiers such as CVE-1999-0001 employed four digits, whereas in years with over 10,000 assignments, like 2021–2024, serials commonly reach six or seven digits, as in CVE-2023-123456.[13] CNAs assign these sequentially within their scope while coordinating through the CVE Program to maintain global uniqueness per year, preventing overlaps or reallocation.[14] The prefix "CVE" is always uppercase, with hyphens as the only separators; no letters, special characters, or spaces are included, enforcing a strictly alphanumeric-numeric structure for machine readability and standardization.[13] This format ensures each ID denotes precisely one independently fixable vulnerability or exposure, prohibiting reuse or retroactive changes once published.[14] Test or example IDs may use prefixes like "CVE-1900-" for documentation purposes, but production IDs adhere strictly to the post-1998 schema.[14] The design supports interoperability in tools like vulnerability scanners and databases, where IDs serve as canonical references without ambiguity.[13]Core Data Fields
The core data fields in CVE records provide the essential structure for identifying, describing, and referencing publicly disclosed cybersecurity vulnerabilities and exposures, as defined in the official CVE JSON record format (version 5.1.1 as of 2024).[15] These fields ensure interoperability and machine-readability while mandating minimal required data for publication, including a unique identifier, descriptive text, supporting references, and temporal metadata.[16] Optional fields, such as affected products or severity assessments, build upon this core but are not required for initial record creation.[17] The following table outlines the primary required core data fields, their formats, and purposes:| Field | Description | Requirement and Format Notes |
|---|---|---|
| cveId | Unique alphanumeric identifier for the vulnerability, assigned sequentially within the year of publication. | Required; format: CVE-YYYY-NNNNN (YYYY = 4-digit year; NNNNN = 4-7 digits).[15] |
| descriptions | Array of textual summaries explaining the vulnerability's nature, impact, and context; must include at least one English-language entry. | Required (min. 1 item); each entry is an object with lang (e.g., "en") and value (string, up to 3999 characters).[15][18] |
| references | Array of external sources, such as advisories or exploit details, linking to verifiable public documentation. | Required (min. 1 item); each is an object with url (string), refsource (source name), and optional tags (e.g., "Vendor Advisory").[15] |
| datePublished | Timestamp when the vulnerability details were first publicly disclosed. | Required (within providerMetadata); ISO 8601 format (e.g., "2023-10-10T00:00:00.000Z").[15] |
| dateUpdated | Timestamp of the most recent modification to the record. | Required; ISO 8601 format, increments with updates via serial number.[15] |
| state | Current status of the CVE record, indicating its validity for use. | Required; enum values: "PUBLISHED" (active) or "REJECTED" (invalidated).[15] |
dataType: "CVE_RECORD" and dataVersion (e.g., "5.1.1"), ensuring records from CVE Numbering Authorities (CNAs) adhere to a consistent schema for automated processing and integration into vulnerability databases.[19] Assigners must provide accurate, verifiable data in these fields to maintain the program's integrity, with rejected states used for duplicates or insufficient evidence.[13] As of CVE JSON 5.0 (introduced March 2023), enhancements allow for richer optional extensions without altering core requirements, supporting better automation in vulnerability management.[16]
Handling Obsolete Fields and Updates
CVE records published after October 31, 2016, may be updated by the owning CVE Numbering Authority (CNA) to incorporate new information, such as refined vulnerability descriptions, additional affected configurations, or updated references, thereby maintaining the record's relevance and accuracy.[18] These modifications are facilitated through CVE Services, which support updating published records alongside publishing new ones or marking them as rejected.[20] Requests for updates from external parties, including vulnerability discoverers or affected vendors, must be directed to the responsible CNA, who evaluates and implements changes as deemed appropriate; for National Vulnerability Database (NVD) enrichments, such requests go to NIST.[21] The CVE JSON schema employs versioning via thedataVersion field (e.g., "5.1.0") to manage structural evolution, ensuring that records from prior versions remain valid while newer submissions adhere to updated requirements.[15] Legacy formats, such as CVE JSON 4.0 and older download structures, have been deprecated, with support ending by December 31, 2023, to streamline data handling and reduce maintenance burdens on consumers; transitional periods allowed dual support before full migration to version 5.x.[22] Although no individual fields are explicitly flagged as deprecated in current schema documentation, updates to records often involve serial number increments to track revisions, and obsolete or erroneous data—such as in rejected entries—is handled by ignoring the CVE ID or redirecting via the replacedBy array for duplicates or splits.[23]
In cases of schema changes rendering certain fields obsolete, backward compatibility is preserved through validation against the specified dataVersion, preventing disruption to existing tools and databases that parse older records.[15] CNAs are guided to avoid substantive alterations to core elements like the vulnerability description post-publication unless justified by new evidence, prioritizing stability while addressing inaccuracies.[18] This approach balances the need for timely corrections with the CVE List's role as a stable reference, though it relies on CNA diligence, as there is no centralized enforcement for post-publication consistency.[13]