What is a Common Vulnerabilities and Exposures list?
CVE, short for Common Vulnerabilities and Exposures, is a list of publicly disclosed computer security flaws. When someone refers to a CVE, they mean a security flaw that's been assigned a CVE ID number.
Security advisories issued by vendors and researchers almost always mention at least 1 CVE ID. CVEs help IT professionals coordinate their efforts to prioritize and address these vulnerabilities to make computer systems as secure as possible.
What is the difference between a vulnerability and an exposure?
Understanding the technical distinction between a vulnerability and an exposure is crucial to grasping why the Common Vulnerabilities and Exposures system was named to cover both categories of security risk.
- A vulnerability is a defect or bug in code (e.g., buffer overflow, SQL injection) that an attacker directly exploits to bypass security controls or run unauthorized commands.
- An exposure is an insecure system configuration or state (e.g., default passwords, exposed management ports, sensitive info leakage) that gives attackers unauthorized access or intelligence, even without a software bug.
Both vulnerabilities and exposures matter to CVE because security breaches occur through software bugs and misconfigurations alike. Including both in the CVE system provides a single, standardized framework to identify, track, and fix all security risks—whether they require code patches or configuration changes.
How does the CVE system work?
The CVE system works by assigning unique, standardized identification numbers to publicly disclosed software vulnerabilities so organizations can track and share security information across different tools and databases.
In 1999, MITRE Corporation, a U.S. Government-funded research and development company, developed the CVE system, a uniform standard for reporting and tracking software security bugs.
CVE entries are brief. They don’t include technical data or information about risks, impacts, and fixes. Those details appear in other databases, including the U.S. National Vulnerability Database (NVD), the CERT/CC Vulnerability Notes Database, and various lists maintained by vendors and other organizations.
Across these different systems, CVE IDs give users a reliable way to recognize unique vulnerabilities and coordinate the development of security tools and solutions. The MITRE Corporation maintains the CVE list, but a security flaw that becomes a CVE entry is often submitted by organizations and members of the open source community.
What are CVE identifiers?
CVE identifiers (also called CVE IDs) are unique, standardized alphanumeric tracking codes assigned to publicly known cybersecurity vulnerabilities and exposures. They serve as a universal catalog number, allowing security professionals, software vendors, and tools to reference the exact same security flaw.
CVE IDs are assigned by a CVE Numbering Authority (CNA). Approximately 100 CNAs exist, including security companies, research organizations, and major IT vendors such as Red Hat, IBM, Cisco, Oracle, and Microsoft. MITRE can also issue CVEs directly.
CNAs are issued blocks of CVE IDs, which the CNAs hold in reserve to attach to new issues as they're discovered. Thousands of CVE IDs are issued every year. A single complex product, like an operating system (OS), can accumulate hundreds of CVEs.
This means a product is particularly vulnerable once it enters its end-of-maintenance phase (when bug fixes and security patches stop being issued) and end-of-life phase (when all first-party support ends). For example, when CentOS Linux 7 entered its end-of-life period on July 1, 2024, a new CVE was announced within a day. This underscores the importance of migrating to a stable OS that receives regular security patches and updates.
Anyone—a vendor, a researcher, or just an astute user—can discover a security flaw and bring it to someone's attention. Many vendors offer bug bounties to encourage responsible disclosure of security issues. If you find a vulnerability in open source software you should submit it to the relevant community.
One way or another, information about the flaw makes its way to a CNA. The CNA then assigns the information a CVE ID. Finally, the new CVE is posted on the CVE website.
A CNA often assigns a CVE ID before making the security advisory public. Vendors commonly keep security flaws secret until they've developed and tested fixes to help prevent attackers from exploiting unpatched flaws.
Once made public, a CVE entry includes the CVE ID (in the format "CVE-2019-1234567"), a brief description of the security vulnerability or exposure, and references, which can include links to vulnerability reports and advisories.
Optimize Linux security with Red Hat
What qualifies as a CVE?
According to the CVE Numbering Authority operational rules, CVE IDs are assigned to flaws that meet specific criteria. Flaws must:
- Be independently fixable. The flaw can be fixed independently of any other bugs.
- Be acknowledged by the affected vendor or documented. The software or hardware vendor acknowledges the bug's existence and confirms that it negatively impacts security. Alternatively, the reporter must have shared a vulnerability report that demonstrates both the negative impact of the bug and that it violates the security policy of the affected system.
- Affect only 1 codebase. If a flaw impacts more than 1 product, it gets a separate CVE for each product. In cases of shared libraries, protocols or standards, the flaw gets a single CVE only if there’s no way to use the shared code without being vulnerable. Otherwise each affected codebase or product gets a unique CVE.
How are vulnerabilities added to CVE?
Adding a vulnerability to the CVE list follows a structured, step-by-step disclosure workflow managed by authorized organizations:
- Discovery and reporting: A security researcher, vendor employee, or user discovers a potential flaw in a software or hardware product. The finder reports the vulnerability details directly to an authorized CNA, usually the product vendor, or to a general coordinator like MITRE.
- Verification and validation: The CNA reviews the technical report to verify that the flaw meets established CVE guidelines. They confirm that the defect is a genuine security risk, impacts a publicly released product, and has not already been assigned a previous identifier.
- ID reservation: Once validated, the CNA assigns a unique identifier (such as CVE-2026-12345) to the flaw. The record is held in a "RESERVED" state to keep the details confidential while the vendor works on developing a solution, preventing malicious actors from exploiting the unpatched vulnerability.
- Fix development and coordinated disclosure: The software vendor develops, tests, and prepares a security patch or mitigation. On an agreed-upon disclosure date, the vendor publicly releases the fix along with a security advisory that prominently cites the assigned CVE ID.
- Publication: The CNA submits the detailed vulnerability record to the central CVE Program, which updates its status to "PUBLISHED" on the public list. Security databases, such as the National Vulnerability Database (NVD), ingest this entry to analyze its impact, calculate CVSS severity scores, and publish technical mitigations for security operations teams.
What is the Common Vulnerability Scoring System?
There are multiple ways to evaluate the severity of a vulnerability. One is the Common Vulnerability Scoring System (CVSS), a set of open standards for assigning a number to a vulnerability to assess its severity. The NVD, CERT, and others use CVSS scores to assess the impact of vulnerabilities. Scores range from 0.0 to 10.0, with higher numbers representing a higher degree of severity. Many security vendors have created their own scoring systems as well.
3 key takeaways
Know your deployments. Just because a CVE exists doesn’t mean the risk applies to your specific environment and deployment. Be sure to read each CVE to validate that it's relevant (wholly or partially) to your environment's operating system, application, modules, and configurations.
Practice vulnerability management. Vulnerability management is a repeatable process to identify, classify, prioritize, remediate, and mitigate vulnerabilities. This means understanding how a risk would apply to your organization so you can properly prioritize any outstanding vulnerabilities that need to be addressed.
Be ready to communicate. CVEs will impact your organization’s systems because of both the vulnerabilities themselves and any potential downtime required to address them. Communicate and coordinate with your internal customers, and share the vulnerabilities with any central risk-management function in your organization.
What are the benefits to the CVE system?
The Common Vulnerabilities and Exposures (CVE) system provides a standardized language that allows security teams, software vendors, and researchers to discuss and track specific threats without confusion. By assigning a single, unique identifier to each flaw, organizations can easily cross-reference vulnerabilities across different security tools, databases, and vendor advisory feeds.
This uniform approach enhances threat detection and accelerates incident response by enabling automated tools to share threat intelligence and indicators of compromise seamlessly. Ultimately, CVE compatibility improves interoperability between security products, helping teams prioritize patch management and eliminate critical security gaps before attackers can exploit them.
How is CVE governed?
The Common Vulnerabilities and Exposures (CVE) system operates under a federated, public-private governance model designed to balance centralized oversight with decentralized operation. Overall direction and strategy are set by the CVE Board, a diverse body composed of security vendors, researchers, academic institutions, and government officials. Administrative operations and daily management are handled by the MITRE Corporation, acting as the primary program secretariat. Financial support comes from the U.S. government, specifically sponsored by the Cybersecurity and Infrastructure Security Agency (CISA) within the Department of Homeland Security.
To manage the massive scale of modern software flaws, the system delegates the power to assign identifiers to hundreds of authorized organizations known as CVE Numbering Authorities (CNAs). These entities, which include major software vendors, IT service providers, and security research firms, issue CVE IDs directly for vulnerabilities within their own products or domain expertise. Top-Level Root Authorities, including MITRE and CISA, oversee these CNAs to ensure policy compliance and manage broad assignment scopes.
Despite its critical role in global security, the CVE system faces structural challenges. Its reliance on U.S. federal funding creates long-term vulnerability to budget shifts and policy changes, while raising international concerns regarding political neutrality. Furthermore, the sheer volume of newly discovered software defects frequently strains downstream infrastructure—such as the National Vulnerability Database—leading to analysis backlogs and variable data quality across different CNA submissions.
How does Red Hat work with CVEs?
Red Hat is a CNA and uses CVE IDs to track security vulnerabilities. Red Hat Product Security maintains an open and frequently updated database of security updates, which you can view by CVE number. Red Hat also continues to address CVEs rated Critical or Important for products in end of maintenance (EOM), like Red Hat Enterprise Linux 7, through our Extended Lifecycle Support (ELS) program.
As a major contributor to open source software, Red Hat is continuously engaged in the security community. Red Hat Enterprise Linux is the foundation of our products, and it incorporates security from the start to rapidly identify, mitigate, and reduce the impact of CVEs with trusted software supply chains, automation, and built-in protections. With the rapid changes to the cybersecurity landscape in reaction to AI-accelerated vulnerability discovery tools, having security baked in from the start is crucial.
What is the Red Hat Security Data API?
Red Hat Product Security provides access to raw security data on the Red Hat Customer Portal and in a machine-consumable format with the Security Data API (application programming interface).
In addition to the security reports and metrics Red Hat produces, customers can use this raw data to produce their own metrics for their unique situations.
The data provided by the Security Data API includes OVAL (Open Vulnerability and Assessment Language) definitions, Common Vulnerability Reporting Framework (CVRF) documents, and CVE data. Data is available in XML or JSON format.
The official Red Hat blog
Get the latest information about our ecosystem of customers, partners, and communities.
