Skip to content

CVE Basics and the Publication Process

Published: August 23, 2026

Overview

Software vulnerabilities are reported with identifiers such as CVE-2026-12345. This article explains who assigns these identifiers, where they are managed, and how a vulnerability moves from discovery to publication.

It also introduces the CVE Program and the roles of CISA, MITRE, and CVE Numbering Authorities (CNAs).

What is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It is a system of common identifiers for publicly disclosed vulnerabilities.

These globally recognized identifiers allow vendors, researchers, and security tools to refer to the same vulnerability consistently. A CVE ID has the following format:

CVE-2026-12345
  • CVE: the identifier prefix
  • 2026: the year in which the CVE ID was assigned
  • 12345: the sequence number that identifies the CVE

A CVE is neither the vulnerability itself nor a severity rating. It is best understood as a common tracking identifier assigned to a vulnerability.

Published CVEs are available on CVE.org and in the official CVE List on GitHub.

The CVE Program

The CVE Program is an international framework for identifying, defining, and cataloging publicly disclosed vulnerabilities. It includes:

  • rules for assigning CVE IDs
  • the CVE Record data format
  • the authorization framework for organizations that assign CVE IDs
  • CVE Services, which handles the reservation and publication of CVE IDs
  • the CVE List, which contains published CVE Records
  • processes for correcting duplicate or incorrect records

The program does not determine vulnerability severity. It ensures that different organizations and tools can refer to the same vulnerability by the same identifier.

Organizations involved in the CVE Program

CISA, MITRE, and CNAs have distinct roles in the operation of the CVE Program.

CISA

CISA, the Cybersecurity and Infrastructure Security Agency, is part of the U.S. Department of Homeland Security. It supports the CVE Program on behalf of the U.S. government and has a leading role in the program's long-term sustainability and development.

CISA also publishes the Known Exploited Vulnerabilities (KEV) Catalog, which lists vulnerabilities known to have been exploited in real-world attacks.

MITRE

MITRE is a U.S. nonprofit organization that has operated the CVE Program for many years. It supports the program's operations and infrastructure and continues to serve as a higher-level CNA.

MITRE also acts as a CNA of Last Resort for vulnerabilities that do not fall within the scope of another appropriate CNA.

CNA

A CVE Numbering Authority (CNA) is an organization authorized by the CVE Program to assign CVE IDs and publish CVE Records.

CNAs include vendors such as Microsoft, Google, and Red Hat, as well as vulnerability coordination centers, security research organizations, and open-source communities. Each CNA has a defined scope and generally handles only vulnerabilities within that scope.

In short, CISA provides government support and leadership, MITRE and other higher-level CNAs perform administrative and coordination roles, and CNAs assign CVE IDs and publish vulnerability information.

Name Organization Role
CISA U.S. government cybersecurity agency Supports and leads the CVE Program's sustainability and development, and publishes the KEV Catalog
MITRE Nonprofit organization and higher-level CNA Supports CVE operations and infrastructure and acts as a CNA of Last Resort
CNA Organization authorized by the CVE Program Assigns CVE IDs and publishes CVE Records for vulnerabilities within its scope

How CVE IDs are managed

Organizations such as Microsoft and Red Hat do not generate CVE sequence numbers independently. An authorized CNA reserves a CVE ID through CVE Services, the program's central management system.

Central reservation prevents different CNAs from issuing the same identifier. CNAs also check existing records to avoid assigning multiple CVE IDs to the same vulnerability.

A CVE Record can have several states, including:

  • RESERVED: the CVE ID has been reserved, but details are not yet public
  • PUBLISHED: the CVE Record, including its description and references, is public
  • REJECTED: the CVE ID will not be used because of duplication, an error, withdrawal, or another reason

A rejected identifier is not reassigned to another vulnerability. Its record remains available to show that the identifier is invalid.

Where researchers should report vulnerabilities

CVE Services is primarily used by authorized CNAs. Individual researchers and users cannot use it directly to issue a CVE ID.

When you discover a vulnerability, look for a reporting contact in this order:

  1. The product vendor or developer
  2. A CNA whose scope covers the product
  3. A coordination center or an appropriate CNA of Last Resort

You can find the CNA responsible for a product in the CNA directory. For example, Microsoft and Red Hat are likely contacts for vulnerabilities in their respective products. In Japan, JPCERT/CC may also coordinate vulnerability disclosures, depending on the case.

Vulnerabilities are generally reported privately through a vendor's security contact before public disclosure. Publishing technical details before a fix is available could expose users to attacks without giving them a way to protect themselves.

The CVE publication process

The process from vulnerability discovery to CVE publication typically follows these steps. Reserving a CVE ID and publishing a CVE Record are separate actions: an ID may be reserved while a fix is being prepared, with details published later alongside the fix.

  1. Report the vulnerability to the vendor or a CNA
    • Privately provide reproduction steps, affected products and versions, potential impact, and test results.
  2. Validate and assess the report
    • The vendor or CNA reproduces the issue and determines whether it is a security vulnerability, which products and versions are affected, whether it duplicates an existing CVE, whether it falls within the CNA's scope, and whether it meets the criteria for a CVE ID.
  3. Reserve a CVE ID
    • The CNA reserves an identifier through CVE Services. At this stage, its status is RESERVED, and the identifier may exist without public details.
  4. Prepare the fix and disclosure
    • The vendor prepares a patch, an updated release, mitigations, and a security advisory. The reporter and vendor may coordinate a disclosure date.
  5. Announce the vulnerability and remediation
    • The vendor publishes the fixed release or advisory. Publishing a CVE Record normally requires a reference to public information that describes the vulnerability.
  6. Publish the CVE Record
    • The CNA submits affected products and versions, a vulnerability description, and reference URLs. The record then becomes PUBLISHED.

Deciding remediation priority

A CVE is a common identifier, not a measure of severity or remediation priority. In practice, vulnerability management combines it with other data:

  • CVSS: the technical severity of the vulnerability
  • CISA KEV: whether exploitation in real-world attacks has been confirmed
  • EPSS: the estimated probability of exploitation in the near future
  • Fix availability: whether an update is available
  • Usage: whether the vulnerable feature or package is actually in use
  • Exposure: whether the vulnerable system is reachable from the internet
  • Environment-specific impact: whether configuration and permissions meet the attack conditions

Ratings may differ between a CNA, the NVD, and an operating system vendor. A Linux distribution may also backport a security fix, so a simple version comparison can produce incorrect results.

Summary

CVE provides globally recognized identifiers for publicly disclosed vulnerabilities. Product vendors do not issue arbitrary identifiers; authorized CNAs reserve CVE IDs through CVE Services and publish CVE Records.

Neither the existence of a CVE nor its CVSS score determines remediation priority on its own. You must also consider active exploitation, fix availability, actual use of the affected component, external exposure, and the conditions in your environment.

Identifying relevant CVEs is the starting point of vulnerability management. The next step is to determine whether each vulnerability affects your environment and how urgently it needs attention.

References