What is a CVE? Common Vulnerabilities and Exposures, explained
A CVE — Common Vulnerabilities and Exposures — is a unique public identifier for one specific, publicly disclosed security flaw. This page explains, accurately and in plain English, what a CVE is, who runs the program (MITRE, sponsored by CISA), what the CVE-YYYY-NNNNN format means, how a CVE moves through its lifecycle, and the distinctions people most often search for — CVE vs CVSS vs CWE vs CISA KEV.
CVE in plain words
- A CVE (Common Vulnerabilities and Exposures) is a unique public identifier for one specific, publicly disclosed security flaw in software or hardware — for example CVE-2021-44228, the Log4Shell vulnerability. The point of a CVE is a common reference number everyone can use for the same flaw.
- The program is run by MITRE, a US nonprofit, and sponsored by CISA (the US Cybersecurity and Infrastructure Security Agency). MITRE does not find most flaws itself — it authorises CVE Numbering Authorities (CNAs), such as major vendors and research organisations, to assign CVE IDs within their own scope.
- A CVE ID is just an identifier, not a severity score. The identifier is CVE; the severity is usually given by a separate CVSS score; the underlying type of weakness is described by CWE; and whether attackers are actively exploiting it is tracked by CISA in the KEV (Known Exploited Vulnerabilities) catalog.
- The usual lifecycle is: a flaw is discovered and reported, a CNA assigns a CVE ID and publishes a description, and the US National Vulnerability Database (NVD) then enriches the record with a CVSS score and references. Vendor advisories carry the fix details.
- To act on a CVE, look it up (NVD, the official CVE record, or the vendor advisory), check whether it affects the versions you run, prioritise by CVSS plus real-world signals like KEV and exploit availability, and apply the vendor fix or mitigation.
What a CVE actually is
CVE stands for Common Vulnerabilities and Exposures. A CVE is a single entry in a public list, and each entry is a unique identifier for one specific, publicly disclosed vulnerability in software or hardware. The whole reason the system exists is to remove ambiguity: before CVEs, two tools or two advisories might describe the same flaw in different words and no one could be sure they meant the same thing. A CVE ID — such as CVE-2021-44228, the widely known Log4Shell flaw — gives everyone a common reference so an advisory, a scanner result and a patch note can all point to exactly the same issue.
A CVE record itself is deliberately minimal: the identifier, a short description of the flaw, and references to further information. Crucially, a CVE is an identifier, not a severity rating and not a fix. The score that tells you how serious it is, the classification of the underlying weakness, and the patch all come from other sources layered on top of the CVE — which is exactly the distinction the next sections draw out.
Who runs it: MITRE, CISA and the CNAs
The CVE Program is operated by MITRE, a US nonprofit, and is sponsored by CISA, the US Cybersecurity and Infrastructure Security Agency. MITRE's role is coordination and standards — it does not personally discover most of the flaws that get CVEs. Instead, the program authorises a global network of CVE Numbering Authorities (CNAs): large software vendors, open-source projects, research organisations and national coordination centres. Each CNA is given a defined scope — usually its own products — within which it can reserve and assign CVE IDs.
This distributed model is why the party closest to a vulnerability, often the vendor that is also shipping the fix, is typically the one that assigns the identifier and publishes the initial record, while MITRE maintains the overall list and the rules everyone follows.
The CVE-YYYY-NNNNN identifier format
Every CVE ID follows the same shape: CVE-YYYY-NNNNN — three parts joined by hyphens.
- CVE — a fixed literal prefix, the same on every ID.
- YYYY — the four-digit year the ID was reserved or assigned. Note this is the assignment year, which is not necessarily the year the flaw was discovered or publicly disclosed.
- NNNNN — a sequence number. It is variable-length: originally at least four digits, it was expanded so IDs can carry five or more digits once a year's assignments pass 9,999.
So in CVE-2021-44228, the ID was assigned in 2021 and carries sequence number 44228. The number is just a unique label — it says nothing about how severe, how exploitable or what type of flaw it is.
CVE vs CVSS vs CWE vs CISA KEV
These four acronyms turn up together constantly, which is why they get muddled. They are not competing — they are complementary, and each answers a different question about a vulnerability:
CVE — Common Vulnerabilities and Exposures
Which flaw?The identity. A unique ID (e.g. CVE-2021-44228) for one specific, publicly disclosed vulnerability, so everyone can refer to the same flaw unambiguously. It is a label and a short description — not a score and not a fix.
CVSS — Common Vulnerability Scoring System
How bad?The severity. A numeric score (typically 0–10) estimating how serious a vulnerability is, based on how it can be exploited and its potential impact. A single CVE is usually paired with a CVSS score to help with prioritisation.
CWE — Common Weakness Enumeration
What kind?The category of weakness. The underlying type of mistake behind the flaw — such as SQL injection, cross-site scripting or a buffer overflow. Many different CVEs map to the same CWE, because the same class of bug recurs across products.
CISA KEV — Known Exploited Vulnerabilities catalog
Exploited now?The real-world signal. A list CISA maintains of CVEs confirmed to be actively exploited in the wild. A CVE appearing in KEV is a strong reason to patch urgently, independent of its CVSS number.
The one-line way to keep them straight: CVE says which, CVSS says how bad, CWE says what kind, and KEV says whether attackers are actually using it.
How a CVE moves through its lifecycle
A CVE does not appear fully formed. It is created and then enriched by different parties over time. The typical path is:
- 1
Discovery & report · Researcher, vendor or user
Someone finds a flaw and reports it, ideally through coordinated disclosure to the vendor so a fix can be prepared before details are public.
- 2
ID assignment · A CNA (CVE Numbering Authority)
A CNA within whose scope the product falls reserves and assigns a CVE ID and publishes a CVE record with a short description and references.
- 3
Enrichment · NVD (National Vulnerability Database)
The NVD ingests the published CVE and adds analysis — typically a CVSS severity score, affected-product data (CPE) and CWE weakness classification.
- 4
Advisory & fix · The affected vendor
The vendor publishes a security advisory with precise affected versions and a patch or mitigation. This is usually the most actionable source for defenders.
- 5
Exploitation tracking · CISA and the community
If attackers are seen using the flaw, CISA may add it to the KEV catalog, and exploit code may become public — both signals that raise the urgency to remediate.
How to read and act on a CVE
When a CVE lands on your desk, a practical sequence is: look it up, confirm it applies to you, prioritise it honestly, then remediate.
- Look it up. Authoritative sources are the US National Vulnerability Database (NVD), which adds a CVSS score and references; the official CVE record from the CVE Program; and the affected vendor's own security advisory, which usually has the most precise affected-version and fix detail.
- Confirm it affects you. Check whether you actually run the affected product, and the affected versions. A CVE in software you do not use — or a version you are not on — may simply not apply.
- Prioritise with more than CVSS. Use the CVSS score as a baseline, but weight it with real-world signals: is the CVE in the CISA KEV catalog, and does a public exploit exist? Active exploitation is a reason to move fast regardless of the headline score.
- Remediate and track. Apply the vendor's patch or recommended mitigation, and follow it through to closure rather than assuming the ticket resolved itself.
Where PlayCISO's free tools fit
Tracking CVEs is only one slice of reducing risk — many of the issues that lead to a breach are configuration and exposure problems that never get a CVE at all. PlayCISO offers free, no-signup tools for those adjacent problems: the secret scanner finds leaked credentials and keys in code, the CSPM readiness scorecard gauges your cloud posture maturity, and the IAM policy analyzer surfaces over-permissioned access. Browse them all in the PlayCISO tools directory.
Attribution: the CVE Program is run by MITRE and sponsored by CISA; CVSS is maintained by FIRST; CWE is a MITRE project; and the KEV catalog is published by CISA. Enriched records live in the NVD. This page is a neutral, plain-language explainer; always confirm specifics against the authoritative CVE record, NVD entry and vendor advisory for any CVE you are acting on.
Frequently asked questions
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures. A CVE is a unique, public identifier assigned to one specific, publicly disclosed cybersecurity vulnerability in a piece of software or hardware. Its purpose is to give everyone — vendors, researchers, defenders and tools — a single common reference number for the same flaw, so that a security advisory, a scanner finding and a patch note can all point to the exact same issue without ambiguity. The CVE record itself is a short, standardised entry: the identifier, a brief description of the flaw, and references. A CVE is an identifier, not a severity rating or a fix; severity, technical detail and remediation come from other sources layered on top of it.
Who runs the CVE program and assigns the IDs?
The CVE Program is operated by MITRE, a US nonprofit, and is sponsored by the US Cybersecurity and Infrastructure Security Agency (CISA). MITRE does not personally discover most vulnerabilities. Instead, it acts as the central coordinator and authorises a worldwide network of CVE Numbering Authorities (CNAs) — these include large software vendors, open-source projects, research organisations and national coordination centres. Each CNA can assign CVE IDs for vulnerabilities within its own defined scope, usually its own products. This distributed model lets the party closest to a flaw (often the vendor) reserve and publish the identifier, while MITRE maintains the overall list and standards.
What does the CVE-YYYY-NNNNN format mean?
A CVE identifier has three parts separated by hyphens: the literal prefix "CVE", a four-digit year, and a sequence number. For example, CVE-2021-44228 is a CVE from 2021 with sequence number 44228. The year is the year the ID was reserved or assigned, which is not necessarily the year the flaw was discovered or publicly disclosed. The numeric portion is simply a sequence and originally had at least four digits, but it is variable-length and can be longer — it was expanded beyond four digits once annual assignments exceeded 9,999, so you will see IDs with five or more digits. The number carries no meaning about severity or type; it is just a unique label.
What is the difference between CVE, CVSS, CWE and CISA KEV?
These four are often confused because they appear together, but each answers a different question. CVE is the identity of a specific flaw — which exact vulnerability are we talking about. CVSS (Common Vulnerability Scoring System) is the severity — a numeric score, typically from 0 to 10, estimating how serious a vulnerability is. CWE (Common Weakness Enumeration) is the category of weakness — the underlying type of mistake, such as SQL injection or a buffer overflow — and many different CVEs can share the same CWE. CISA KEV (the Known Exploited Vulnerabilities catalog) is the real-world exploitation signal — a list CISA maintains of CVEs that are being actively exploited in the wild, which is a strong reason to patch urgently regardless of the CVSS number. In short: CVE says which, CVSS says how bad, CWE says what kind, and KEV says whether attackers are actually using it.
How do I look up and act on a CVE?
Start by looking the CVE up by its ID. Authoritative sources include the US National Vulnerability Database (NVD), which enriches CVE records with a CVSS score and references; the official CVE record published by the CVE Program; and the affected vendor’s own security advisory, which usually has the most precise detail on affected versions and fixes. Once you have the record, confirm whether it actually affects the product and versions you run — a CVE in software you do not use, or in a version you are not on, may not apply to you. Then prioritise: use the CVSS score as a baseline, but weight it with real-world signals such as whether the CVE is in the CISA KEV catalog and whether a public exploit exists. Finally, apply the vendor’s patch or recommended mitigation, and track it to closure.