What Is a CVE? (Common Vulnerabilities and Exposures)

TL;DR: CVE stands for Common Vulnerabilities and Exposures — a standardized system for identifying and cataloging publicly known security vulnerabilities in software and hardware. Each vulnerability gets a unique CVE ID (like CVE-2021-44228) that serves as a universal reference across security tools, vendor advisories, patch notes, and vulnerability databases. CVE is the common language of vulnerability management.

How CVE IDs Work

Every CVE entry follows the same format: CVE-[year]-[number]. The year reflects when the CVE was assigned (not necessarily when the vulnerability was discovered or publicly disclosed), and the number is a sequential identifier. CVE-2021-44228, for example, was assigned in 2021 and is the 44,228th entry assigned that year — better known as Log4Shell.

CVE IDs are assigned by CVE Numbering Authorities (CNAs) — a network of organizations authorized to assign identifiers within their area of scope. CNAs include major software vendors (Microsoft, Google, Apple), security research organizations, and bug bounty platforms. When a researcher discovers a new vulnerability, they typically report it to the affected vendor or a CNA, which assigns a CVE ID as part of the responsible disclosure process.

The CVE program is maintained by MITRE Corporation under sponsorship from the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Once assigned, CVE entries are published in the National Vulnerability Database (NVD) maintained by NIST, where they receive additional enrichment — CVSS severity scores, affected product lists, and remediation references.

Not all vulnerabilities receive a CVE. Undisclosed or privately fixed issues, vulnerabilities below a certain severity threshold, and findings that haven't been formally reported through a disclosure process may never be assigned an ID, which is why CVE coverage, while extensive, isn't exhaustive.

How CVE Severity Is Rated

Every CVE entry published in the NVD receives a CVSS (Common Vulnerability Scoring System) score — a numerical rating from 0.0 to 10.0 that reflects the severity of the vulnerability based on a standardized set of metrics.

The current version, CVSS v3.1, evaluates vulnerabilities across several dimensions:

• Attack Vector — how the vulnerability is exploited: remotely over a network, from an adjacent network, locally, or through physical access
• Attack Complexity — whether specific conditions need to be in place for exploitation
• Privileges Required — whether the attacker needs any existing access or credentials
• User Interaction — whether exploitation requires action from a victim
• Scope — whether a successful exploit affects resources beyond the vulnerable component
• Impact — the effect on Confidentiality, Integrity, and Availability of the affected system

These scores map to severity tiers used across the industry:

CVSS scores are what security teams use to prioritize remediation — a Critical CVE on an internet-facing system gets patched before a Medium CVE on an internal one, regardless of when each was discovered. Understanding how scores are calculated helps organizations push back on inflated severity claims and calibrate their own patching cadence against real risk rather than raw numbers.

CVE in Vulnerability Management

CVE is the backbone of vulnerability management programs. When an organization runs a vulnerability scanner — against its infrastructure, applications, or dependencies — the scanner's output is a list of CVE IDs mapped to the systems where they were detected, along with CVSS scores and remediation guidance.

The CVE lifecycle inside an organization typically looks like this:

1. Detection. Scanning tools identify CVEs present in software versions, dependencies, or configurations across the environment.
2. Prioritization. Not every detected CVE gets patched immediately — there are always more vulnerabilities than capacity to fix them. Teams prioritize by CVSS score, exploitability (whether a public exploit exists), exposure (internet-facing vs. internal), and business criticality of the affected system.
3. Remediation. Applying the vendor's patch is the primary fix. Where patching isn't immediately possible, due to compatibility constraints, testing requirements, or operational continuity, compensating controls (network segmentation, WAF rules, access restriction) can reduce exposure while a permanent fix is scheduled.
4. Verification. After remediation, scanning confirms the CVE is no longer present on the affected system.
5. Ongoing monitoring. New CVEs are published daily. A vulnerability management program treats this as a continuous cycle, not a project with an end date.

One important limitation: CVE-based scanning only detects known, documented vulnerabilities. Zero-days — vulnerabilities that have been discovered but not yet disclosed or assigned a CVE are invisible to scanners by definition. This is the gap that penetration testing and bug bounty programs are built to address.

Notable CVE Examples

CVE-2021-44228 (Log4Shell) is arguably the most significant CVE in recent history. A critical remote code execution vulnerability in the widely used Apache Log4j logging library, it scored a perfect 10.0 CVSS and affected an enormous portion of the internet's software infrastructure — from enterprise applications to cloud services to embedded systems. The vulnerability allowed unauthenticated remote code execution with a single crafted log message, and exploitation began within hours of public disclosure.

CVE-2017-0144 (EternalBlue) is the vulnerability behind the WannaCry ransomware outbreak. A flaw in Windows' SMB protocol allowed unauthenticated remote code execution across unpatched machines on the same network. Originally developed by the NSA and leaked by the Shadow Brokers, EternalBlue was weaponized in 2017 to spread WannaCry across 150 countries — hitting hospitals, telecoms, and government agencies before a kill switch was discovered.

CVE-2014-0160 (Heartbleed) was a critical vulnerability in the OpenSSL cryptographic library that allowed attackers to read memory from servers running vulnerable versions — including private keys, passwords, and session tokens — without leaving any trace. At the time of disclosure, an estimated two-thirds of active HTTPS servers on the internet were affected.

These incidents share a pattern: widely deployed software, a long window between vulnerability introduction and discovery, and massive collateral damage once exploitation began. They're also all now indexed CVE entries meaning organizations that were still running unpatched versions after disclosure had no excuse not to know the risk they were carrying.

Conclusion

A CVE ID is the starting point for everything that follows in vulnerability management — detection, prioritization, patching, and verification. The system works well for the vulnerabilities it covers: known, publicly disclosed, and catalogued in a database that security tooling can reference. What CVE doesn't cover is the unknown — the zero-days, logic flaws, and chained vulnerabilities that haven't been discovered yet, or that have been found by an attacker before a researcher could report them. Closing that gap is what continuous security testing, bug bounty programs, and adversarial research are built for.