Skip to main content

CVE Record User Guide

Below are details on selected fields shown on the CVE Record Detail page.

CVE Records on this CVE.ORG website are displayed in the official CVE Record Format. Downloads in this format are available on the Downloads page. Learn more about the CVE Record Format here.

CVE Records may now provide data from three different sources to enrich vulnerability information available to the public:

  • CVE Numbering Authority (CNA): Selected enriched information provided by the CNA is found under the “CNA” container.
  • CVE Program Container: Additional references that are added by the CVE Program are found in the CVE Program Container. Refer to this blog for a full explanation of this enriched data.
  • Authorized Data Publisher (ADP): Selected enriched information provided by one or more ADPs is provided under the “ADP” container. If there is no ADP-enriched information, no ADP container will be present.

Note: CVE Record detail pages may not display all data for a record. Select the “View JSON” link to view all available required, optional, and enriched information for the record.

CVSS

The Common Vulnerability Scoring System (CVSS) produces a numerical score to represent the severity of a vulnerability. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes. Learn more about the latest CVSS version 4.0 on the FIRST CVSS User Guide page

external site

.

CWE

Common Weakness Enumeration (CWEℱ) is a community-developed list of weaknesses. A weakness is a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities. CWEs represent the root causes of CVE Records. Learn more on the CWE website

external site

.

KEV

Known Exploited Vulnerabilities (KEV) refers to a security flaw in software that CISA has identified as being actively exploited by attackers. These vulnerabilities are considered high-risk because they can be used by malicious actors to gain unauthorized access, execute arbitrary code, or cause other security breaches. Organizations are urged to address KEVs promptly to mitigate potential threats. The KEV information displayed in the CVE Record includes the reference link to the KEV catalog and the date that the vulnerability was added to the KEV catalog. Learn more about the CISA KEV catalog

external site

.

SSVC

Stakeholder-Specific Vulnerability Categorization (SSVC) is a vulnerability analysis methodology that accounts for a vulnerability’s exploitation status, impacts to safety, and prevalence of the affected product in a singular system. Learn more about SSVC on the CISA SSVC page

external site

.

Product Status

The Versions section may contain a Default Status field and one or more of these version status categories:

  • Affected Versions List
  • Unaffected Versions List
  • Unknown Versions List

Each category contains a list with the following format:

Purple text denotes the version provided by the user inputting the CVE JSON data.

In the following section you will find the descriptions, format information and examples for the following fields: default status, top-level version/version range and version changes.

Default Status

This status applies to all versions not explicitly mentioned elsewhere. Learn more .

Top-level Version/Version Range

The single version being described, or the version range. By convention, 0 typically denotes the earliest possible version.

Formats:

  • <status: affected, unaffected, unknown> at
  • <status: affected, unaffected, unknown> from <at, before, through>

Examples:

  • unknown at 5.0 (unknown version is 5.0)
  • affected from 5.0 before 6.0 (affected version doesn’t include 6.0)
  • unaffected from 5.0 through 6.0 (unaffected version range includes 5.0 and 6.0)

Version changes

A list of status changes that take place during a range. The list should be sorted in (linearly or topologically) increasing order by the ‘at’ field, according to the versionType, but the user must not assume this. Instead, users must re-sort the list themselves before using it.

Format:

<status: affected, unaffected, unknown> from

Examples:

  • affected from 1.0 before 4.0 (affected version doesn’t include 4.0)
    • unaffected from 1.0 (version affected changed and it is unaffected from 1.0 to 2.0 — the next range right below)
    • affected from 2.0 (version remain affected from 2.0 to before 4.0, not including 4.0)
  • For another linear version example view the Version Status Changes section
  • For a non-linear version example view the Source Control Versions section