What Is CWE? Common Weakness Enumeration Explained

CWE (Common Weakness Enumeration) is a community-developed, categorized list of software and hardware weakness types, the underlying flaws that lead to vulnerabilities. Maintained by MITRE with sponsorship from CISA, each entry has a stable identifier like CWE-79 (cross-site scripting) or CWE-89 (SQL injection). Where a CVE names one specific vulnerability in one product, a CWE names the class of mistake behind it, so CWE is the vocabulary for talking about the root cause rather than the incident.

Understanding what CWE is matters because it is the connective tissue of vulnerability data. Almost every enriched vulnerability record pairs a CVE identifier with a CWE type, and the National Vulnerability Database (NVD) assigns a CWE to most CVEs it analyzes. CWE is published openly by MITRE at cwe.mitre.org, and its best-known artifact, the CWE Top 25 Most Dangerous Software Weaknesses, is the industry's annual shortlist of the flaw classes doing the most real-world damage.

What is the difference between CWE and CVE?

This is the single most common confusion, and the distinction is simple once stated: a CWE is a weakness type, a CVE is a specific instance. CWE-787 is "out-of-bounds write," a category of coding mistake that can appear in any program. CVE-2026-53266 is one particular out-of-bounds write, in the Linux kernel's ebtables code, in specific versions. The CWE describes the kind of bug; the CVE describes the individual bug in a named product. One CWE maps to thousands of CVEs, and every well-analyzed CVE points back to at least one CWE.

If you have read our explainer on what a CVE is, the clean way to hold it is: CVE answers "which bug," CWE answers "what kind of bug," and CVSS answers "how severe."

How does CWE work and how is it structured?

CWE is a hierarchy, not a flat list. Weaknesses are organized from broad Pillars down through Classes to specific Base and Variant weaknesses, so you can talk about a problem at the level that fits. For example, CWE-119 (improper restriction of operations within the bounds of a memory buffer) is a broad class that contains more specific children like CWE-787 (out-of-bounds write) and CWE-125 (out-of-bounds read). Each entry carries a description, common consequences, likely mitigations, and real CVE examples, which is what makes CWE useful for developers, not just analysts: it explains how the mistake happens and how to avoid it.

MITRE also publishes "views" that slice the catalog for different audiences, including the Top 25 view, a software-development view, and mappings to other standards. As of the current corpus, CWE spans roughly 940 weakness entries across hardware and software.

What is the CWE Top 25?

The CWE Top 25 Most Dangerous Software Weaknesses is an annual ranking, produced by MITRE and CISA, of the weakness types responsible for the most serious, most frequently exploited vulnerabilities. It is calculated from real data: analysts score CWEs by how often they appear across reported CVEs and how severe those CVEs tend to be, including which ones show up in CISA's Known Exploited Vulnerabilities catalog. Perennial entries include out-of-bounds write (CWE-787), cross-site scripting (CWE-79), SQL injection (CWE-89), and use-after-free (CWE-416). For a security team, the Top 25 is a prioritization aid for prevention: it tells you which classes of mistake are worth hardening your code and tests against first.

Why does CWE matter for prioritization and prevention?

Because CVE and CVSS tell you about individual fires, while CWE tells you where the fires keep starting. A patch queue organized only by CVE is reactive by nature: you fix each vulnerability as it appears. Tracking the CWE distribution of your findings turns that into a prevention program, if the same weakness type keeps producing CVEs in your code, that is a signal to fix the pattern, add a lint rule or test, or change a library, not just the individual instances. CWE is also how modern code-security tooling classifies what it finds, so a scanner that reports "CWE-79 in this template" is speaking the standard language that maps to known mitigations.

CWE has a real limit worth stating plainly: like CVSS, it describes a category, not your exposure. Knowing a flaw is CWE-306 (missing authentication for a critical function) tells you the shape of the risk, as in the recent CVSS 10.0 Azure AI Foundry flaw, but not whether that specific function is reachable in your deployment. CWE informs prevention and triage; it does not replace verifying what is actually exploitable in your environment.

Frequently asked questions

What does CWE stand for?
CWE stands for Common Weakness Enumeration, a categorized list of software and hardware weakness types maintained by MITRE.

What is the difference between CWE and CVE?
A CWE is a type of weakness (for example, CWE-89, SQL injection), while a CVE is a specific vulnerability in a specific product (for example, a particular SQL injection flaw in one application). One CWE maps to many CVEs.

Who maintains CWE?
The CWE Program is run by MITRE with sponsorship from CISA. The catalog is published openly at cwe.mitre.org and updated with community input.

What is a CWE ID?
A CWE ID is a stable identifier for a weakness type, written as CWE followed by a number, such as CWE-416 (use-after-free) or CWE-22 (path traversal). It links a vulnerability to its root-cause category.

What is the CWE Top 25?
It is an annual, data-driven ranking by MITRE and CISA of the 25 most dangerous software weakness types, based on how often they appear in real CVEs and how severe and exploited those vulnerabilities are.

Is CWE the same as OWASP Top 10?
No, but they are related. The OWASP Top 10 is a curated awareness list for web application risks, while CWE is a comprehensive enumeration of weakness types across all software and hardware. OWASP categories map to underlying CWEs.

Our read

CWE is the layer most vulnerability conversations skip, and skipping it keeps teams stuck in reaction. CVE and CVSS point at individual flaws and their severity; CWE points at the recurring mistake, which is where prevention actually lives. The verifiable-by-design habit is to read the CWE on every finding as a question about your own codebase and controls: if a weakness class keeps recurring, the fix is the pattern, not the patch, and if a CWE like missing authentication or path traversal shows up, the next step is to prove whether that weakness is reachable in your deployment rather than assuming a category label is the whole story. Root cause first, then verify exposure, is how a stream of CVEs becomes a shorter list of problems worth solving once.

Structure, entries, and the Top 25 methodology per MITRE (cwe.mitre.org) and CISA; CWE-to-CVE mapping per the NIST National Vulnerability Database. Sources linked above.

Related: What is a CVE?, What is CVSS?, and What is path traversal (CWE-22)?.