Common Vulnerabilities and Exposures


The Common Vulnerabilities and Exposures system provides a reference-method for publicly known information-security vulnerabilities and exposures. The National Cybersecurity FFRDC, operated by the Mitre Corporation, maintains the system, with funding from the National Cyber Security Division of the United States Department of Homeland Security. The system was officially launched for the public in September 1999.
The Security Content Automation Protocol uses CVE, and CVE IDs are listed on MITRE's system as well as in the US National Vulnerability Database.

CVE identifiers

MITRE Corporation's documentation defines CVE Identifiers as unique, common identifiers for publicly known information-security vulnerabilities in publicly released software packages. Historically, CVE identifiers had a status of "candidate" and could then be promoted to entries, however this practice was ended some time ago and all identifiers are now assigned as CVEs. The assignment of a CVE number is not a guarantee that it will become an official CVE entry.
CVEs are assigned by a CVE Numbering Authority ; there are three primary types of CVE number assignments:
  1. The Mitre Corporation functions as Editor and Primary CNA
  2. Various CNAs assign CVE numbers for their own products
  3. A third-party coordinator such as CERT Coordination Center may assign CVE numbers for products not covered by other CNAs
When investigating a vulnerability or potential vulnerability it helps to acquire a CVE number early on. CVE numbers may not appear in the MITRE or NVD CVE databases for some time due to issues that are embargoed, or in cases where the entry is not researched and written up by MITRE due to resource issues. The benefit of early CVE candidacy is that all future correspondence can refer to the CVE number. Information on getting CVE identifiers for issues with open source projects is available from Red Hat.
CVEs are for software that has been publicly released; this can include betas and other pre-release versions if they are widely used. Commercial software is included in the "publicly released" category, however custom-built software that is not distributed would generally not be given a CVE. Additionally services are not assigned CVEs for vulnerabilities found in the service unless the issue exists in an underlying software product that is publicly distributed.

CVE data fields

The CVE database contains several fields:

Description

This is a standardized text description of the issue. One common entry is:
** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.
This means that the entry number has been reserved by Mitre for an issue or a CNA has reserved the number. So in the case where a CNA requests a block of CVE numbers in advance, the CVE number will be marked as reserved even though the CVE itself may not be assigned by the CNA for some time. Until the CVE is assigned, Mitre is made aware of it, and Mitre has researched the issue and written a description of it, entries will show up as "**RESERVED **".

Obsolete fields

The following fields were previously used in older CVE records, but are no longer used.
In order to support CVE ID's beyond CVE-YEAR-9999 a change was made to the CVE syntax in 2014 and took effect on Jan 13, 2015.
The new CVE-ID syntax is variable length and includes:
CVE prefix + Year + Arbitrary Digits
NOTE: The variable length arbitrary digits will begin at four fixed digits and expand with arbitrary digits only when needed in a calendar year, for example, CVE-YYYY-NNNN and if needed CVE-YYYY-NNNNN, CVE-YYYY-NNNNNN, and so on. This also means there will be no changes needed to previously assigned CVE-IDs, which all include a minimum of 4 digits.

CVE SPLIT and MERGE

CVE attempts to assign one CVE per security issue, however in many cases this would lead to an extremely large number of CVEs. To deal with this there are guidelines that cover the splitting and merging of issues into distinct CVE numbers. As a general guideline one should first consider issues to be merged, then issues should be split by the type of vulnerability, then by the software version affected and then by the reporter of the issue. Another example is Alice reports a /tmp file creation vulnerability in version 1.2.3 and earlier of ExampleSoft web browser, in addition to this issue several other /tmp file creation issues are found, in some cases this may be considered as two reporters. Conversely, issues can be merged, e.g. if Bob finds 145 XSS vulnerabilities in ExamplePlugin for ExampleFrameWork regardless of the versions affected and so on they may be merged into a single CVE.

Search CVE identifiers

The Mitre CVE database can be searched at the , and the NVD CVE database can be searched at .

CVE usage

CVE identifiers are intended for use with respect to identifying vulnerabilities:

Common Vulnerabilities and Exposures is a dictionary of common names for publicly known information security vulnerabilities. CVE’s common identifiers make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization’s security tools. If a report from one of your security tools incorporates CVE Identifiers, you may then quickly and accurately access fix information in one or more separate CVE-compatible databases to remediate the problem.

Users who have been assigned a CVE identifier for a vulnerability are encouraged to ensure that they place the identifier in any related security reports, web pages, emails, and so on.