When a serious vulnerability hits the news, it comes with a code like CVE-2021-44228. That identifier is how vendors, scanners, patch notes and security teams all make sure they're talking about the same flaw. Understanding what a CVE is, and what it isn't, is the foundation of vulnerability management.
What a CVE is
A CVE record describes one vulnerability in one product (or a defined range of versions). It contains:
- The ID: CVE, the year the ID was reserved or published, and a sequence number of four or more digits, for example CVE-2024-3094 (the xz-utils backdoor).
- A description of the flaw and its effect.
- Affected products and versions.
- References: vendor advisories, patches, write-ups.
- Often, a weakness type (CWE) and a severity score (CVSS), added by the assigning organisation or by enrichment services such as the US National Vulnerability Database (NVD).
Who runs the CVE system
The CVE Program was launched by MITRE in 1999 and has long been funded by the US government through CISA. IDs are assigned by CVE Numbering Authorities (CNAs): hundreds of organisations, mostly vendors (Microsoft, Google, Red Hat), open-source foundations, security research firms and national CERTs, each authorised to assign IDs for their own products or area.
The system has had growing pains. In 2024 the NVD fell far behind on enriching new CVEs with scores and product data. In April 2025 the MITRE contract came within a day of lapsing before CISA extended it, which prompted the creation of the CVE Foundation, a non-profit set up to reduce dependence on a single government sponsor, and accelerated alternatives such as ENISA's European Vulnerability Database (EUVD). The identifiers themselves remain the common language everyone uses.
CVE, CVSS, CWE, KEV: how they fit
| Term | Answers | Example |
|---|---|---|
| CVE | Which specific vulnerability? | CVE-2021-44228 in Apache Log4j 2 |
| CWE | What type of weakness? | CWE-917, expression language injection |
| CVSS | How severe, in general? | 10.0 Critical |
| EPSS | How likely to be exploited in the next 30 days? | A probability from 0 to 1, published daily by FIRST |
| KEV | Is it being exploited right now? | Listed in CISA's Known Exploited Vulnerabilities catalog |
A sensible patching priority uses all of them: start with anything in KEV that you run and that's reachable, then high-EPSS items, then by CVSS. And none of them knows your architecture, which is why a vulnerability is not the same as a risk.
Where CVEs fit in threat modeling
CVEs describe flaws in software you use. Threat modeling mostly finds flaws in what you build: missing authorization checks, shared credentials, trust placed in the wrong input. Those flaws will never have a CVE. The two meet in three places:
- Dependencies: an SBOM tells you which components you ship; CVE feeds tell you which of them are vulnerable. The threat model tells you which of those are reachable and what they'd expose.
- Attack tree leaves: "exploit a known CVE in the image library" is a legitimate leaf, scored on how fast you patch.
- The patching gap: the window between a CVE's publication and your patch is when most exploitation happens. See zero-day vulnerabilities on why the n-day window matters more.
Worked example: Invoicely
Invoicely's PDF worker uses an open-source rendering library. Suppose a CVE is published for it, rated CVSS 9.8, allowing code execution through a crafted document. Is it critical for Invoicely?
- Reachable? Yes: customers control invoice content that the worker renders.
- Impact? The worker can read file storage, so code execution there means reading every customer's invoice PDFs.
- Exploited? If it appears in KEV, the likelihood goes to the top of the scale.
Here the CVE becomes a new leaf under the "read another customer's invoices" attack tree, and the threat model shows a second fix: limiting the worker to write-only access on storage would contain the damage even before the patch ships.
Common mistakes
- Treating CVE count as a security metric. A product with many CVEs may simply have a vendor that discloses responsibly.
- Patching by CVSS alone. Thousands of high-severity CVEs are published every year, and only a small fraction are ever exploited.
- Assuming no CVE means no vulnerability. Your own code, configuration and design have no CVE feed.
Key takeaways
- A CVE is an identifier for one known vulnerability in a specific product, not a severity score and not a weakness category.
- CVE IDs are assigned by CVE Numbering Authorities, mostly vendors, and published through the CVE Program.
- Severity comes from CVSS; real-world exploitation from sources like CISA's KEV catalog and EPSS. Use all three to prioritise.
- CVEs cover products you use. Flaws in your own design won't have one, which is what threat modeling is for.
Frequently asked questions
What does CVE stand for?
Common Vulnerabilities and Exposures. It is a programme, launched by MITRE in 1999, that gives each publicly disclosed vulnerability a unique identifier so that vendors, scanners and security teams refer to it consistently.
What is the difference between a CVE and a CWE?
A CVE is a specific vulnerability in a specific product, such as CVE-2021-44228 in Apache Log4j. A CWE is the type of weakness behind it, such as CWE-502 Deserialization of Untrusted Data or CWE-917 Expression Language Injection. Many CVEs share the same CWE.
Who assigns CVE numbers?
CVE Numbering Authorities (CNAs): hundreds of organisations, mostly software vendors, open-source foundations, security companies and national CERTs, each authorised to assign IDs within their scope. MITRE acts as the root CNA.
Does every vulnerability get a CVE?
No. Only publicly disclosed vulnerabilities in distributed products or services that someone requests an ID for. Bugs in your own internal code, misconfigurations and design flaws usually never get one.