CVE Assignment Information Format

The information on this page is excerpted from “Appendix B: CVE Information Format” of the “CVE Numbering Authorities (CNA) Rules” document, and provides the required Format, a Correctly Formatted Example, and information about the JSON Submission and Storage Format.


CVE Numbering Authorities (CNAs) must provide CVE assignment information to the CNA level above them using the following format. The use of this format facilitates the automation of CVE assignment.

  1. The preferred format for submitting CVE assignment information is using the JSON schema.
  2. In a flat file, use this format:
  3. In a Comma Separated Values (CSV) file, each row should include each of these columns with CVE ID as a primary key.

There are no format limitations on the actual data, which allows for flexibility across products that may have unusual versioning or differing definitions, such as what a “problem type” means. The only exception to this is that references must be URLs. With or without this technical standard, the information referenced by each field is required for assigning a CVE ID. In all cases, the content included in CVE Entry submission must be germane to the vulnerability. The Primary CNA reserves the right to modify or reject content included in CVE assignment if it is deemed inappropriate by the Primary CNA. Any information submitted as part of a CVE Entry must be submitted in English, though CVE Entries may reference content in any language.

Where applicable, make use of industry standards when describing vulnerabilities.


As a general guideline, [PRODUCT] should include the vendor, developer, or project name as well as the name of the actual software or hardware in which the vulnerability exists.


[VERSION] should include the version, date of release, or whatever indicator that is used by vendors, developers, or projects to differentiate between releases. [VERSION] can be described with specific version numbers, ranges of versions, or “all versions before/after” a version number or date.


As mentioned above, [PROBLEMTYPE] can include an arbitrary summary of the problem, though Common Weakness Enumerations (CWEs) are an excellent standard to use in this field.


[REFERENCES] should be URLs pointing to a world-wide-web-based resource. For CSV and flat-file formats, they should be separated by a space. References should point to content that is relevant to the vulnerability and include at least all the details included in the CVE entry. Ideally, references should point to content that includes the CVE ID itself whenever possible. References must also be publicly available, as described in Section 2.1.1 of the CVE Numbering Authorities (CNA) Rules.


The [DESCRIPTION] field is a plain language field that should describe the vulnerability with sufficient detail as to demonstrate that the vulnerability is unique. The required information listed above should be included in the [DESCRIPTION], as well as other details the author feels are relevant or necessary to show uniqueness.

Specifically, the [DESCRIPTION] field could also include:

Descriptions often follow this template:


where impact and attack are arbitrary terms that should be relevant to the nature of the vulnerability.


The [ASSIGNINGCNA] field should include the name of the assigning CNA. CNAs should use a consistent name to facilitate searches for CVE IDs that originate from them.

Correctly Formatted Example

Following is an example of the reporting format in use. In this case, the Sub-CNA “BigCompanySoft” is assigning a CVE ID to versions of their product.

[CVEID]: CVE-2016-123455
[VERSION]: All versions prior to version 2.5
[PROBLEMTYPE]: Arbitrary Code Execution
[DESCRIPTION]: CoreGraphics in BIGCOMPANYSOFT SOFTWARE PRODUCT before 2.5 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted BMP image.
[ASSIGNINGCNA]: BigCompanySoft

JSON Submission and Storage Format

The JSON schema will be reviewed periodically. The review cycle will follow a schedule similar to this example:

First 30 days (September)

Next 30 days (October)

Next 60 days (November and December)

New JSON Format in Effect (January)

Page Last Updated or Reviewed: January 23, 2018