What Are CVE and CWE? Naming Vulnerabilities and the Weaknesses Behind Them

A dependency scanner fails your build with “CVE-2021-44228, critical”. A static analysis tool flags a line of code as “CWE-89”. A vendor’s release notes list a dozen CVE numbers fixed in the latest patch, and a security questionnaire asks how you prevent “the CWE Top 25”. The two acronyms look alike, both are run by the same organisation and both turn up in the same tools, but they answer different questions. CVE answers which vulnerability is this?: it gives one specific, publicly known flaw in one product a name everyone can use. CWE answers what kind of mistake is this?: it names a type of weakness that can occur in any product, and that may cause many vulnerabilities over the years.

This article explains what each one is and how their records are put together, where both came from, how they relate to each other and to CVSS, the National Vulnerability Database and CISA’s catalogue of exploited vulnerabilities, and how a developer can use them. The lookups shown were run against the public CVE and NVD APIs on 20 October 2026, with Python 3.14.6, and their output is shown as printed.

What a CVE is

CVE, Common Vulnerabilities and Exposures, is a public list of identifiers for publicly disclosed cybersecurity vulnerabilities. Each identifier, such as CVE-2021-44228, belongs to one vulnerability and comes with a CVE Record: a short description, the affected product and versions, and references to advisories, patches and reports.

The CVE Program defines a vulnerability as “an instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability”.¹ The word that matters is instance: a CVE is about one flaw in one product, such as a particular bug in particular versions of Apache Log4j, not about a type of flaw in general.

The identifier

A CVE ID has three parts:

CVE-2021-44228
 │    │    └── sequence number: four or more digits
 │    └─────── year the ID was assigned, or the flaw made public if earlier
 └──────────── prefix

The year is the year the ID was assigned, or the year the vulnerability was made public if that came first; it does not say when the flaw was discovered.² An ID reserved in 2024 can be published in 2025 and keep its 2024 number. Until 2014 the sequence number had exactly four digits, which capped the list at 9,999 IDs a year; since 1 January 2014 it can have four or more.³ The number carries no meaning: CVE-2021-44228 is not more serious than CVE-2021-44227, and nothing about severity or product can be read from the ID itself.

The record and its states

A CVE Record goes through three states:¹

Records are published as JSON, in the CVE Record Format; the program moved to version 5 of that format in 2023 and stopped offering the old CSV, HTML and XML downloads in 2024.⁴ A record can carry more than the minimum: the CNA that publishes it may add a CWE, a CVSS score and lists of affected product versions, and other organisations can attach their own data to it later.

Who assigns them

No single office writes every record. IDs are assigned and records published by CVE Numbering Authorities (CNAs): “an authorized entity with specific scope and responsibility to regularly assign CVE IDs and publish corresponding CVE Records”.¹ Most CNAs are vendors that cover their own products, such as Microsoft, Google, Red Hat and the Apache Software Foundation, but the program’s partner list also includes open-source projects, independent researchers, national CERTs and bug bounty platforms.⁵ As of 31 March 2026 there were 502 organisations from 42 countries taking part: 499 CNAs and 3 CNAs of Last Resort, which assign IDs for vulnerabilities no other CNA’s scope covers.⁶ CNAs are organised under Roots, which recruit, train and govern them; the two Top-Level Roots are MITRE and CISA.¹⁷

The program is sponsored by the US Cybersecurity and Infrastructure Security Agency (CISA) and operated by the MITRE Corporation through a federally funded research and development centre; MITRE also runs the program’s Secretariat and owns the CVE trademark.⁷ A CVE Board, whose members come from security tool vendors, academia, research institutions and government agencies, oversees it.⁷

What a CVE is not

A CVE is a name and a short description, not a full analysis. It is not a severity rating, which comes from CVSS, not a list of every affected product in machine-readable detail, which is what databases such as the NVD add, and not a judgement on whether the flaw is being exploited, which is what CISA’s KEV catalogue records. Nor does every vulnerability get one: a bug fixed quietly before release, a flaw in a company’s own website or a problem nobody discloses usually never receives a CVE.

What a CWE is

CWE, Common Weakness Enumeration, is a community-developed list of the types of software and hardware weaknesses: the mistakes in design, code or configuration that can lead to vulnerabilities. Each entry, such as CWE-89 SQL Injection, describes one type of mistake, how it arises, what it can lead to, how to detect it and how to prevent it.

CWE defines a weakness as “a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities”, and a vulnerability as “a flaw … resulting from a weakness that can be exploited”.⁸ So a weakness is a cause that may or may not be exploitable in a given product; a vulnerability is a weakness that turned out to be exploitable in one.

What an entry contains

A CWE entry is far longer than a CVE record. CWE-79, “Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)”, has a description, an extended description, the languages and technologies it affects, its common consequences, demonstrative examples of vulnerable code, detection methods, potential mitigations for each phase of development, observed examples that link to real CVE records, related attack patterns in CAPEC, and a note on whether vulnerabilities may be mapped to it.⁹

The list is much smaller and changes much more slowly than the CVE List. Version 4.20, released on 30 April 2026, has 944 weaknesses among 1,450 entries in total; the others are categories and views, described below.¹⁰

Abstraction levels

Weaknesses are organised from the general to the specific. CWE’s glossary gives four levels:⁸

Following one branch shows why the levels matter. CWE-664, “Improper Control of a Resource Through its Lifetime”, is one of the ten pillars at the top of the Research Concepts view. Below it sit the classes CWE-118, “Incorrect Access of Indexable Resource”, and CWE-119, “Improper Restriction of Operations within the Bounds of a Memory Buffer”. Below those is the base weakness CWE-125, “Out-of-bounds Read”, and below that the variant CWE-126, “Buffer Over-read”.¹¹ Saying a bug is CWE-664 tells you almost nothing; saying it is CWE-125 tells you the program read past the end of a buffer.

Besides weaknesses, the list has three other kinds of entry:⁸

• Compound elements link weaknesses that go together: a chain, where one weakness “can directly create the conditions” for the next, and a composite, where several weaknesses “must be present at the same time”.
• Categories group entries by a shared trait, such as the weaknesses in a coding standard. A category is “not a weakness, but rather a structural item”. (In CWE 5.0, due on 28 October 2026, categories are renamed groupings.)¹⁰
• Views are subsets of the list for a purpose. The main ones are CWE-1000 Research Concepts, which arranges every weakness by abstraction; CWE-699 Software Development, arranged by concepts developers know; CWE-1194 Hardware Design; and CWE-1003, “Weaknesses for Simplified Mapping of Published Vulnerabilities”, about 130 entries commonly seen in published vulnerabilities.¹²¹³

Mapping a vulnerability to a weakness

Attaching a CWE to a CVE record is called root cause mapping, and MITRE’s guidance is specific: “CWEs at the Base and Variant level should be used whenever possible”; a class may be used if no accurate base or variant exists; and a vulnerability should never be mapped to a category or a view.¹³ Each entry carries a usage label, from Allowed through Allowed-with-Review and Discouraged to Prohibited, so a tool can warn when a mapping is too vague.¹³ CWE-20, “Improper Input Validation”, is a class marked Discouraged: almost any bug could be blamed on input validation, so mapping to it says little.¹¹

The difference

The shortest way to put it: a CVE is an instance, a CWE is a type. A CVE record is like a report of one accident at one junction on one day; a CWE entry is like the category “failure to give way”, which explains many accidents and tells planners what to change. CWE’s own FAQ calls them “sister programs with separate but complimentary missions” and notes that one CWE can be the root cause of many CVE records.¹⁴

The direction of the relationship matters in practice. A CVE is tied to a product version, so it tells you whether you must act: if you run an affected version, upgrade. A CWE is tied to no product, so it tells you what to change in how you work: if your bug reports keep mapping to CWE-79, the fix is not one patch but output encoding in every template.

A history of CVE

The naming problem

By the late 1990s there were several commercial vulnerability scanners, intrusion detection systems and advisory services, and each named vulnerabilities its own way. In a paper dated 8 January 1999, David E. Mann and Steven M. Christey of MITRE described the problem from their own security work: to tell whether two tools had found the same flaw, analysts had to correlate them by reading descriptions by hand. Their example was a 1991 flaw that allowed unauthorised access to NFS file systems through guessable file handles, which each database labelled in its own words; one scanner alone had 13 separate probes for NFS problems, all pointing to the same six CERT advisories. Mapping between every pair of databases was, they wrote, “labor intensive and error prone”.¹⁵

Their proposal was a list that would assign “a standard, unique name to each vulnerability”, deliberately independent of any one tool’s perspective, and public “without distribution restrictions”.¹⁵ They called it a Common Vulnerability Enumeration. They presented it at the 2nd Workshop on Research with Security Vulnerability Databases at Purdue University, on 21–22 January 1999.¹⁶

Launch, candidates and the Board

A working group formed from that meeting, later the first 19-member CVE Editorial Board, and created the first entries. The CVE List was launched publicly in September 1999 with 321 entries, under the name Common Vulnerabilities and Exposures.¹⁶¹⁷ The idea caught on quickly: by December 2000, 29 organisations had declared 43 products “CVE-compatible”.¹⁶

In the early years a new identifier was first issued as a candidate, with the prefix CAN-, meaning it was under review for the list, and became a CVE- entry once it was formally accepted. Every promotion changed the identifier, and every tool and database that used it had to follow, a burden that grew with the number of vulnerabilities.⁷ At the community’s request, on 19 October 2005 every candidate was renamed in one go: CAN-2005-0386, for example, became CVE-2005-0386 with “candidate” status, keeping its number.¹⁸

Growth: the ID syntax and the CNA program

The four-digit sequence number became a constraint as disclosures grew. After public discussion the program changed the syntax to allow four or more digits, effective 1 January 2014; IDs in the new form were first issued in January 2015, and the first seven-digit IDs in May 2016.³

Assignment also spread out. In 2016, when it had only 23 CNAs, the program adopted a strategy of federating the publication of records, so that the organisation that knows a product best, usually its vendor, assigns and writes them. By March 2026 more than 500 organisations took part,⁶ and in 2026 the list of new CNAs included AI companies such as OpenAI and Anthropic, alongside a pilot for researchers who find vulnerabilities with frontier AI models.⁴

The volume of records grew with them. Published CVE Records per year, from the program’s own metrics:¹⁹

The NVD backlog

Since 2005, when NIST relaunched its older ICAT database under the new name,²⁰ the National Vulnerability Database (NVD) has taken every CVE record and enriched it with its own CVSS score, CWE mapping and list of affected products in CPE form, which is the data most scanners consume. In February 2024 NIST announced delays in analysis “during this transition”, and by the end of March only 199 of 3,370 new CVEs published that month had been analysed.²¹ The backlog lasted. In April 2026 NIST said CVE submissions had grown 263% from 2020 to 2025 and changed the NVD’s operations: enrichment now goes first to CVEs in CISA’s KEV catalogue, to software used by the federal government and to critical software as defined under Executive Order 14028; other records are labelled lowest priority, and backlogged records published before 1 March 2026 were moved to “Not Scheduled”.²² The data the NVD no longer adds has to come from elsewhere, above all from the CNAs themselves, in their own records.

The 2025 funding scare

On 15 April 2025 MITRE wrote to the CVE Board that the US government did not intend to renew its contract to run the program, which expired the next day. CISA exercised an option period on the contract that night, extending it by 11 months to March 2026, and said there would be “no lapse in critical CVE services”.²³ The same day a group of CVE Board members announced the CVE Foundation, a non-profit meant to continue the program’s work and, in their words, to eliminate “a single point of failure” in vulnerability management.²⁴ Other efforts started at about the same time: the European Union Agency for Cybersecurity (ENISA) launched the European Vulnerability Database (EUVD) on 13 May 2025,²⁵ and Luxembourg’s CIRCL started GCVE, a decentralised scheme in which CVE IDs form one numbering space among several.²⁶

The episode showed how much depended on one contract. In September 2025 CISA set out a vision for the program’s move “from the CVE Program’s Growth Era to its Quality Era”, with “vendor-neutral stewardship” and data that remains a public good,²⁷ and in September 2026 it published a framework for that era covering governance, ecosystem participation, data infrastructure and record content.²⁸ Before the extension ran out, the contract was renegotiated with no fixed expiry; CISA’s acting director said in March 2026 that “the CVE program is fully funded”, and the CVE Foundation began reassessing its role.²⁹ Meanwhile the legacy cve.mitre.org website was retired on 26 August 2025, and every old link now redirects to cve.org.³⁰

A history of CWE

From CVE categories to PLOVER

CWE grew out of CVE. While building the CVE List, MITRE’s CVE team sorted vulnerabilities into rough categories, which were good enough for CVE but not for the code analysis tools that were appearing, which needed to say precisely what kind of flaw they detected.³¹ In 2005, as part of the NIST Software Assurance Metrics and Tool Evaluation (SAMATE) project, which DHS sponsored, Steve Christey took the CVE categories further in a working document called PLOVER, the Preliminary List Of Vulnerability Examples for Researchers. It grouped well over a thousand real CVE examples under about 290 types of weakness: in MITRE’s words, “the first attempt at a truly bottom-up effort” to abstract observed flaws into types.³¹³²

Drafts, version 1.0 and the Top 25

MITRE posted the first draft of the Common Weakness Enumeration on 15 March 2006, and drafts followed every few months; the second, in May 2006, merged in other taxonomies: PLOVER, the Seven Pernicious Kingdoms taxonomy from McGraw and Fortify, and Secure Software’s CLASP.³³³¹ After nine drafts, CWE version 1.0 was released in September 2008.³⁴ The program celebrated 20 years in September 2026.¹⁰

In January 2009 MITRE and the SANS Institute published the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors, built on CWE entries. Its stated goal was to “stop vulnerabilities at the source by educating programmers”, and to give software managers a measuring stick for their progress.³⁵³⁴ The 2011 edition was still drawn up from surveys and personal interviews with developers, security analysts, researchers and vendors. In 2019 the method changed: the Top 25 became data-driven, computed from real CVE records in the NVD for 2017 and 2018, about 25,000 of them.³⁶

Hardware, attack patterns and what comes next

In 2007 MITRE launched CAPEC, the Common Attack Pattern Enumeration and Classification, a catalogue of the methods attackers use to exploit weaknesses; CWE entries link to the attack patterns that target them, and CAPEC entries back to the weaknesses they exploit.³⁷ CWE 4.0, released on 24 February 2020, added hardware design weaknesses and the Hardware Design view.³⁸ Version 4.20 in April 2026 added a view of weaknesses related to AI and machine learning products, and CWE 5.0, due on 28 October 2026, brings a new schema with breaking changes for tools that read the list.¹⁰

A timeline at a glance

How they fit together

CVE and CWE are two pieces of a larger set of public standards, each answering one question about a vulnerability:

CVSS, the Common Vulnerability Scoring System, gives a vulnerability a score from 0 to 10 based on how it can be exploited and what it affects. It began in the US National Infrastructure Advisory Council, which in April 2005 chose FIRST, the Forum of Incident Response and Security Teams, as its custodian;³⁹ the current version, CVSS v4.0, was published on 1 November 2023.⁴⁰ A CVSS score measures how bad a flaw could be, not how likely anyone is to exploit it.

That second question is what CISA’s Known Exploited Vulnerabilities (KEV) catalogue answers. Created by Binding Operational Directive 22-01 on 3 November 2021,⁴¹ and now governed by its successor, BOD 26-04, it lists vulnerabilities that meet three criteria: the vulnerability “has an assigned Common Vulnerabilities and Exposures (CVE) ID”, there is “reliable evidence” of exploitation in the wild, and there is a clear remediation such as a vendor update.⁴² A vulnerability without a CVE cannot enter the catalogue, which is one more reason the IDs matter.

Other databases sit on top of the CVE List too. The OSV format, from the Open Source Security Foundation, describes vulnerabilities in open-source packages; GitHub’s advisory database stores its advisories in it, and the OSV.dev service aggregates databases that use it.⁴³⁴⁴ An OSV entry lists the same vulnerability’s IDs in other databases as aliases, so that a GitHub advisory such as GHSA-r9p9-mrjm-926w and CVE-2020-28498 are recognised as one vulnerability.⁴⁵ That cross-referencing, nearly three decades on, is exactly the problem Mann and Christey set out to solve.

Reading the records

The CVE Program and the NVD both offer free JSON APIs. This script looks up a CVE in each, and prints who assigned it, its dates, the CWEs that the CNA and the NVD each mapped it to, the NVD’s CVSS 3.1 score and the date it entered KEV:

import json
import sys
from urllib.request import urlopen

CVE_API = "https://cveawg.mitre.org/api/cve/"
NVD_API = "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId="


def fetch(url):
    with urlopen(url, timeout=30) as response:
        return json.load(response)


def describe(cve_id):
    record = fetch(CVE_API + cve_id)
    meta = record["cveMetadata"]
    cna = record["containers"]["cna"]
    print(cve_id, meta["state"], "assigned by", meta["assignerShortName"])
    print("  reserved ", meta["dateReserved"][:10])
    print("  published", meta["datePublished"][:10])
    for problem in cna.get("problemTypes", []):
        for d in problem["descriptions"]:
            print("  CNA says ", d["description"])

    nvd = fetch(NVD_API + cve_id)["vulnerabilities"][0]["cve"]
    for weakness in nvd.get("weaknesses", []):
        if weakness["source"] == "nvd@nist.gov":
            for d in weakness["description"]:
                print("  NVD says ", d["value"])
    for metric in nvd["metrics"].get("cvssMetricV31", []):
        if metric["type"] == "Primary":
            print("  CVSS 3.1 ", metric["cvssData"]["baseScore"])
    if "cisaExploitAdd" in nvd:
        print("  in KEV   ", nvd["cisaExploitAdd"])


for cve_id in sys.argv[1:]:
    describe(cve_id)

Run for Log4Shell and Heartbleed:

$ python lookup.py CVE-2021-44228 CVE-2014-0160
CVE-2021-44228 PUBLISHED assigned by apache
  reserved  2021-11-26
  published 2021-12-10
  CNA says  CWE-502 Deserialization of Untrusted Data
  CNA says  CWE-400 Uncontrolled Resource Consumption
  CNA says  CWE-20 Improper Input Validation
  NVD says  CWE-917
  CVSS 3.1  10.0
  in KEV    2021-12-10
CVE-2014-0160 PUBLISHED assigned by redhat
  reserved  2013-12-03
  published 2014-04-07
  CNA says  n/a
  NVD says  CWE-125
  CVSS 3.1  7.5
  in KEV    2022-05-04

Several things in that output are worth noticing.⁴⁶⁴⁷

• The ID was reserved before anyone knew. Apache reserved CVE-2021-44228 two weeks before the record was published, so the name existed before the flaw was public.
• Different parties map different weaknesses. Apache, the CNA, mapped Log4Shell to deserialization of untrusted data, resource consumption and input validation; the NVD mapped it to CWE-917, expression language injection, which points at the ${jndi:…} lookup expressions an attacker could plant in a log message. Both are defensible: root cause mapping is a judgement, and one vulnerability can involve several weaknesses.
• Records are not always complete. Heartbleed’s CNA record names no CWE at all, only “n/a”; the CWE-125 mapping came from the NVD. Where the CNA leaves a field empty, everyone downstream depends on someone else filling it.
• Severity and exploitation are separate facts. Heartbleed’s CVSS 3.1 score is 7.5, “high” rather than “critical”, yet it was added to KEV in May 2022 because it was being exploited. Log4Shell entered KEV the day it was published. A score alone says neither.

Using them in practice

When you consume software, think in CVEs. Dependency scanners such as npm audit, pip-audit, Dependabot or OSV-Scanner compare the versions in your lockfile against advisories that carry CVE IDs. The ID lets you search a vendor’s release notes, the NVD, KEV and the project’s issue tracker for the same flaw. To decide what to patch first, combine three facts: whether the vulnerable code is actually reachable in your system, whether the CVE is in KEV, and only then its CVSS score.

When you produce software, think in CWEs. Static analysis tools, linters and code review checklists report findings by CWE, because what they detect is a pattern, not a known flaw. If your team’s bugs cluster in a few CWEs, that is where a framework change or a library ends the problem for good: parameterised queries for CWE-89, auto-escaping templates for CWE-79, a memory-safe language for CWE-787 and CWE-125. That is the idea behind CISA’s Secure by Design pledge, whose signatories commit to a “measurable reduction” in the prevalence of one or more vulnerability classes, such as SQL injection, cross-site scripting and memory safety vulnerabilities.⁴⁸

Use the Top 25 as a starting point, not a target. The 2025 CWE Top 25 was computed from 39,080 CVE records published between 1 June 2024 and 1 June 2025, scoring each weakness by how often it was mapped and how severe those CVEs were on average.⁴⁹ Its top three were CWE-79 cross-site scripting, CWE-89 SQL injection and CWE-352 cross-site request forgery; CWE-787 out-of-bounds write, second in 2024, fell to fifth.⁵⁰⁵¹ The ranking reflects what is reported and mapped in CVE records across the whole industry; it says little about which weaknesses are most likely in your own system.

When you report a vulnerability, give both. A good advisory names the CVE, so others can track it, and maps it to the most specific CWE that fits, at the base or variant level, so others can learn from it.

Common misunderstandings

Why it matters

Before CVE, two tools that found the same flaw could not tell each other so, and every security team kept its own translation tables. A shared name turned vulnerability data into something machines can exchange: a scanner, an advisory, a patch and a catalogue of exploited flaws can all refer to CVE-2021-44228 and mean the same thing, which is why a world of tens of thousands of new vulnerabilities a year can be managed at all. CWE does the same for causes. It gives developers, tool makers and teachers a shared vocabulary for the mistakes behind those vulnerabilities, and it turns a stream of individual bugs into patterns that can be designed out. The NVD backlog of 2024 and the funding scare of 2025 showed how much of the industry rests on a few public programs with a single sponsor. Knowing which one answers which question, which flaw is this or what kind of mistake caused it, is what lets you patch the first and stop writing the second.

References