What is a CVE? Common Vulnerabilities & Exposures

Common Vulnerabilities and Exposures (CVE) is a public, standardized catalog of known security vulnerabilities, where each flaw receives a unique identifier so that everyone refers to the same issue in the same way. A single CVE is one entry in that catalog: a specific, publicly disclosed weakness in software or hardware.

The scale is now enormous. The CVE Program published a record of more than 40,000 vulnerabilities in 2024, and NIST reports that CVE submissions rose 263% between 2020 and 2025. A shared naming system is what keeps that volume manageable across tools, teams, and vendors.

What is a CVE?

Common Vulnerabilities and Exposures refers to two related things. The first is the CVE List, the public catalog of known vulnerabilities run by the MITRE Corporation and sponsored by the United States Cybersecurity and Infrastructure Security Agency (CISA). The second is an individual CVE record: a single entry that names and briefly describes one vulnerability.

The purpose is a common language. Before CVE, every vendor and tool tracked vulnerabilities differently, which made it hard to tell whether two products described the same flaw. The CVE Program solved that by assigning one identifier and one description to each vulnerability. 

That identifier lets a security team, a researcher, and a software vendor discuss the same issue without confusion, and it lets scanners, advisories, and databases exchange data reliably. The CVE List feeds the United States National Vulnerability Database (NVD), which adds severity scores and further details.

A Brief History of CVE

The CVE system began in 1999, when the MITRE Corporation introduced it to solve a practical problem. Security tools and vendors each maintained their own vulnerability databases with their own naming, so the same flaw carried different names in different products, and comparing coverage or sharing information was slow and error-prone. CVE replaced that fragmentation with a single reference list and one identifier per flaw. The United States government has backed the effort since its early years, and the program has grown from a few hundred entries to tens of thousands of new records each year. That growth reflects both the expansion of software and a far larger community of researchers and vendors reporting flaws.

Vulnerability vs Exposure

The two words in the name describe different things. A vulnerability is a weakness in software or hardware that an attacker can exploit to compromise the confidentiality, integrity, or availability of a system, such as a coding error that allows remote code execution. An exposure is a mistake or misconfiguration that grants access or reveals information without itself being a coding flaw, such as a setting that leaves data reachable.

A simple way to picture it: a vulnerability is a window with a weak lock that a burglar can force, while an exposure is a window someone left unlocked. Both give an attacker a way in. In everyday use, security teams often say "vulnerability" to mean any catalogued CVE, and the distinction matters most when scoping what a CVE does and does not cover.

Although the name CVE includes "Exposures," modern CVE records overwhelmingly describe software and hardware vulnerabilities. Misconfigurations, exposed services, or insecure deployments generally do not receive CVE IDs unless they originate from an underlying product vulnerability.

What a CVE ID Looks Like

Every CVE carries a unique identifier in a fixed format. A CVE ID has three parts: the prefix CVE, the year the ID was assigned, and a sequential number. A full ID reads CVE-2021-44228. The sequential number has no fixed length, which lets the system scale as the volume of vulnerabilities grows.

Each record sits in one of three states:

• Reserved. An ID has been allocated while a CVE Numbering Authority (CNA) examines the vulnerability, before public disclosure.
• Published. The CNA has added the details and made the record public on the CVE List.
• Rejected. The ID is not valid, and the record stays on the list to mark it as such.

What a CVE Record Contains

A published CVE record is deliberately concise, yet it carries the core facts a defender needs to identify and triage a flaw. A typical record includes:

• CVE ID. The unique identifier in the CVE-YYYY-NNNNN format.
• Description. A short summary of the flaw, the affected component, and the impact.
• Affected products and versions. The software or hardware the flaw applies to.
• References. Links to vendor advisories, patches, and technical write-ups.
• Assigning CNA. The authority that reserved and published the record.
• Enriched data. Once the NVD processes the record, a CVSS severity score and a Common Weakness Enumeration (CWE) mapping.

For deeper analysis, defenders follow the references to vendor advisories, which carry the remediation steps a CVE entry itself does not include.

What Qualifies as a CVE?

Not every bug becomes a CVE. A flaw meets three criteria before it receives a CVE ID.

Independently Fixable

The flaw can be resolved on its own, separate from other bugs.

Represents a Single Vulnerability

A CVE generally represents one distinct vulnerability. If multiple products share the same underlying vulnerable code, they may all reference the same CVE. Separate vulnerabilities receive separate CVE IDs.

Vendor-Acknowledged or Documented

The vendor confirms the security impact, or a report documents that the flaw violates the affected system's security policy.

A flaw that fails these tests, or that stays private, never enters the public list.

How a CVE is Assigned: The CVE Lifecycle

A vulnerability moves through a defined sequence, from discovery to a published, scored record. The stages run in order.

1. Discovery

A researcher, vendor, open-source maintainer, or user finds the flaw, often through security testing or a bug bounty program.

2. Report to a CNA

The finder submits the flaw to a CVE Numbering Authority, an organization that the CVE Program authorizes to assign IDs within a defined scope.

3. Reservation

The CNA reserves a CVE ID for the vulnerability, which is the initial state of the record.

4. Analysis and Detail

The CNA confirms the affected products and versions, the root cause and impact, and at least one public reference.

5. Publication

The CNA publishes the record to the CVE List, making it publicly available.

6. Enrichment

The NVD adds a CVSS severity score and affected-product data, and security tools begin tracking the CVE.

More than 400 CNAs operate worldwide, including major vendors such as Microsoft and Oracle, security firms, and research groups. Roots recruit and govern CNAs, and two top-level roots sit at the top of the structure: the MITRE Corporation and CISA. Anyone can report a vulnerability, and many vendors run bug bounty programs that reward responsible disclosure.

Who Manages CVEs? The CVE Ecosystem

Several organizations share responsibility for the CVE system, and each plays a distinct role.

Together, these bodies turn a raw report into a scored, referenced record that defenders worldwide can act on.

CVE vs CVSS vs CWE vs KEV

Four acronyms appear together so often that they blur. Each answers a different question.

In short, CVE names the flaw, CVSS rates it, CWE explains the underlying weakness, and KEV flags the flaws attackers are exploiting right now.

What is a CVSS Score?

The Common Vulnerability Scoring System (CVSS), maintained by the Forum of Incident Response and Security Teams (FIRST), expresses the severity of a vulnerability as a number from 0.0 to 10.0. A higher score signals a more serious flaw, and the NVD and most advisories attach a CVSS score to each CVE.

The score draws on three metric groups: base metrics (the intrinsic qualities of the flaw, such as how it is exploited and its impact), threat metrics (how the situation changes over time, including whether exploit code exists), and environmental metrics (how the flaw applies to a specific organization). Public databases usually publish the base score. Two CVEs can share a base score yet pose very different real-world risk once an organization's environment and active exploitation are considered, which is why severity is a starting point rather than a verdict. CVSS maps to five severity bands:

• None: 0.0
• Low: 0.1 to 3.9
• Medium: 4.0 to 6.9
• High: 7.0 to 8.9
• Critical: 9.0 to 10.0

Famous CVE Examples

A handful of CVEs have shaped how the industry thinks about vulnerability response, and high-profile flaws often pick up informal nicknames.

Log4Shell (CVE-2021-44228)

A critical 2021 flaw in the widely used Log4j logging library allowed remote code execution from a single crafted string. It affected millions of Java applications and triggered a global patching scramble, and its reach made it a turning point in how organizations track vulnerabilities in open-source dependencies. 

CloudSEK threat research documented active exploitation of Log4Shell in the wild, including its use to deploy cryptocurrency miners and Mirai botnet payloads.

EternalBlue (CVE-2017-0144)

A flaw in the Windows SMB protocol that powered the 2017 WannaCry ransomware outbreak, which spread across hundreds of thousands of machines in a few days. It showed how a single unpatched flaw can enable self-propagating malware across an entire network.

Heartbleed (CVE-2014-0160)

A 2014 flaw in the OpenSSL cryptographic library allowed attackers to read server memory, exposing private keys, passwords, and other sensitive data. The flaw prompted widespread certificate reissuance and renewed scrutiny of critical open-source libraries.

BlueKeep (CVE-2019-0708)

A wormable Remote Desktop Protocol flaw in Windows, serious enough that authorities issued emergency advisories urging patching before exploitation spread. Its wormable nature drew comparisons to the conditions that enabled earlier mass-malware outbreaks.

The Importance of CVEs

The CVE system underpins much of modern vulnerability management.

• Common language. One identifier lets teams, vendors, and tools discuss the same flaw without ambiguity, which removes the guesswork of matching one vendor's name for a flaw to another's.
• Interoperability. Scanners, advisories, and databases exchange data by CVE ID.
• Prioritization. Teams track which CVEs affect their systems and rank remediation accordingly, since the CVE ID ties a flaw to its severity score and exploitation status across sources.
• Compliance. Frameworks such as NIST CSF, PCI DSS, ISO 27001, CIS Controls, and many regulatory regimes expect organizations to identify and remediate known vulnerabilities, with CVEs serving as the common reference.

Limitations of CVEs

The CVE system is foundational, yet it has clear limits.

• Public flaws only. A CVE exists once a vulnerability is disclosed, so undisclosed and zero-day flaws are absent from the list.
• Brief entries. A CVE record gives a short description and references, and full details come from the NVD or vendor advisories.
• Volume and backlog. With tens of thousands of new CVEs a year, the NVD has built an enrichment backlog, so some records lack scores for a time, and teams that depend solely on enriched data can be left waiting during that gap.
• Not every weakness qualifies. Misconfigurations, end-of-life systems, and flaws that fail the criteria fall outside the list.
• Score alone misleads. A high CVSS score does not always mean a flaw is being exploited, and a lower score can still be dangerous in context.

How to Prioritize and Track CVEs

With more than 40,000 CVEs published in a single year, no team patches everything, so effective programs prioritize. The goal is to spend limited remediation effort on the small share of flaws that pose real risk.

Three signals guide prioritization. CVSS severity indicates how damaging a flaw could be. The CISA Known Exploited Vulnerabilities (KEV) catalog lists CVEs confirmed to be exploited in real attacks, which makes them urgent regardless of score. The Exploit Prediction Scoring System (EPSS) estimates the likelihood that a flaw is exploited in practice. To act on any of this, a team first finds which CVEs affect its own systems, which is the role of vulnerability scanning across the asset inventory.

Speed is the reason this matters. In a CloudSEK honeypot study of a vulnerable Oracle WebLogic server, automated exploitation attempts against the critical flaw CVE-2026-21962 began the same day public exploit code was released, which shows how little time defenders have once a CVE is weaponized.

The decisive signal is whether attackers are using a flaw now. CloudSEK Threat Intelligence tracks actively exploited CVEs, exploitation timelines, and dark web discussion of vulnerabilities, so security teams know which of the thousands of open CVEs to address first. Intelligence of this kind complements vulnerability scanning and patching by adding the attacker's perspective, rather than replacing them.

How CloudSEK Helps Organizations Prioritize CVEs

Security teams don't struggle because they lack CVE data — they struggle because there are too many CVEs to investigate. With more than 40,000 new CVEs published annually, knowing which vulnerabilities matter to your organization is more important than simply knowing they exist.

CloudSEK combines external attack surface intelligence, threat intelligence, and AI-driven attack path analysis to identify the vulnerabilities that present the highest real-world risk. Rather than prioritizing solely by CVSS, CloudSEK correlates multiple risk signals, including:

• Active exploitation observed in the wild
• CISA Known Exploited Vulnerabilities (KEV)
• Dark web discussions and exploit trading
• Public proof-of-concept exploits
• Whether vulnerable assets are exposed on your internet-facing attack surface
• Attack path analysis showing how multiple weaknesses can be chained together

For organizations using BeVigil, CloudSEK continuously discovers internet-facing assets and identifies exposed software affected by known CVEs. Findings are prioritized based on exploitability and business risk rather than severity score alone.

CloudSEK Threat Intelligence continuously tracks emerging exploits, ransomware activity, exploit kits, and attacker discussions across the deep and dark web, helping defenders understand which newly disclosed CVEs are already being weaponized.

Together, these capabilities help security teams focus remediation efforts on the vulnerabilities attackers are most likely to exploit first.

Frequently Asked Questions

Can attackers use CVEs?

Yes. CVE records are public, so attackers read the same entries defenders do and target organizations that have not yet patched affected systems. This creates a race: defenders need to patch a disclosed flaw before attackers build and deploy a working exploit for it.

Is a CVE the same as a vulnerability?

No. A vulnerability is the actual weakness in software or hardware. A CVE is the public identifier and record that names that weakness. A vulnerability can exist long before it receives a CVE, and some never receive one at all.

How many CVEs are there?

More than 260,000 CVEs have been published since the program began in 1999, and the pace is accelerating. The CVE Program published over 40,000 in 2024 alone, an average of roughly 108 per day.

What is the difference between a CVE and a zero-day?

A zero-day is a vulnerability attackers exploit before a patch exists, often before public disclosure. A CVE is a published, identified vulnerability. A zero-day can later receive a CVE once it is disclosed and meets the qualifying criteria.

Where can you look up CVE details?

The National Vulnerability Database at nvd.nist.gov and the official CVE List at cve.org hold full CVE records, including descriptions, references, and CVSS scores. The CISA KEV catalog shows which CVEs are known to be exploited.

Is there such a thing as CVE certification?

No. There is no CVE certification for products or individuals. Organizations can apply to become a CVE Numbering Authority, which authorizes them to assign CVE IDs within a defined scope, but that is a role, not a certification.