CWE stands for Common Weakness Enumeration — a community-developed, categorized list of common software and hardware weakness types maintained by MITRE. Where a CVE identifies one specific vulnerability in one specific product, a CWE names the underlying class of mistake that caused it. "SQL Injection" is a CWE. "The SQL injection flaw in version 2.3 of AcmeShop" is a CVE. Understanding that distinction is the first step to using either one well, and it is why security tools, advisories, and compliance frameworks lean on CWE to talk about root causes rather than individual incidents.
Breaking down the acronym
- Common — these are recurring weaknesses seen across many products and languages, not one-off quirks.
- Weakness — a flaw, bug, or design error in code, architecture, or implementation that could lead to a vulnerability. A weakness is the root cause; a vulnerability is what happens when that weakness becomes exploitable.
- Enumeration — a structured, numbered catalog. Each entry gets a stable identifier like
CWE-79orCWE-89.
MITRE runs the CWE project (with backing from CISA), and the catalog is free and public at cwe.mitre.org. It currently contains over 900 weakness entries organized into a hierarchy.
CWE vs. CVE: the difference that trips everyone up
These two acronyms look almost identical and are constantly confused, so here is the clean mental model:
- CWE = the type of weakness. Abstract, reusable, describes a category of mistake. Example:
CWE-79, Improper Neutralization of Input During Web Page Generation (Cross-site Scripting). - CVE = a specific instance in a specific product. Concrete, tied to a version, gets a CVSS severity. Example: a particular XSS bug in a named CMS at a named version.
A single CVE is almost always mapped to one or more CWEs that describe its root cause. Think of CWE as the diagnosis category ("bacterial infection") and CVE as the individual patient's case. When a vulnerability report says a flaw "is a CWE-89 (SQL Injection)," it is telling you the class of bug so you know how to prevent it everywhere, not just patch this one instance.
How CWE is organized
The catalog is a hierarchy, which is what makes it useful for both broad reporting and precise engineering:
- Pillars and classes are the abstract top levels — for example, "Improper Input Validation" (
CWE-20). - Base weaknesses are more specific and actionable, like
CWE-89(SQL Injection) orCWE-22(Path Traversal). - Variants describe a weakness in a particular technology or context.
MITRE also publishes views — curated slices of the catalog for a purpose. The best known is the CWE Top 25 Most Dangerous Software Weaknesses, an annually updated ranking of the weaknesses causing the most real-world impact, derived from CVE and exploit data. It is a practical starting point if you want to know which classes of bug to defend against first.
Some CWEs you'll meet constantly
A handful show up in nearly every appsec conversation:
CWE-79— Cross-site Scripting (XSS)CWE-89— SQL InjectionCWE-22— Path TraversalCWE-78— OS Command InjectionCWE-352— Cross-Site Request Forgery (CSRF)CWE-287— Improper AuthenticationCWE-502— Deserialization of Untrusted Data
Learning to recognize these by number pays off fast, because scanners, advisories, and pentest reports all speak in CWE IDs.
Why CWE matters in practice
Naming the class of a bug rather than just the instance changes how you fix it. If a scanner tells you "you have three CVEs," you patch three things. If it tells you "all three map to CWE-89," you have learned something structural: your codebase has a pattern of unparameterized queries, and the durable fix is a coding standard plus a lint rule, not three isolated patches.
That is exactly how CWE feeds the rest of the security toolchain:
- SAST tools report findings by CWE, so you can see which weakness classes your code repeatedly produces.
- SCA and vulnerability data tag each CVE with its CWE, letting a software composition analysis platform group and trend your exposure by root cause.
- Compliance frameworks (PCI DSS, and standards referencing the OWASP Top 10, which itself maps to CWE categories) use these classifications to define what "secure" means.
Tracking your findings by CWE over time tells you whether your secure-coding investments are working: if CWE-79 findings drop after you adopt a framework with autoescaping, that's measurable progress. The Safeguard Academy has hands-on guides for the most common CWE classes if you want to build that muscle.
FAQ
What does CWE stand for?
CWE stands for Common Weakness Enumeration. It is a free, community-developed catalog maintained by MITRE that lists and categorizes common types of software and hardware weaknesses, each with a stable identifier such as CWE-79.
What is the difference between CWE and CVE?
CWE describes a category of weakness (for example, SQL injection as CWE-89), while CVE identifies a specific vulnerability in a specific product and version. A CVE is typically mapped to one or more CWEs that explain its root cause.
What is the CWE Top 25?
The CWE Top 25 Most Dangerous Software Weaknesses is an annually updated ranking published by MITRE of the weakness types causing the most real-world impact, based on CVE and exploitation data. It's a practical prioritization list for defenders.
How many CWEs are there?
The CWE catalog contains over 900 entries, organized into a hierarchy of pillars, classes, base weaknesses, and variants. Most day-to-day security work centers on a few dozen common base weaknesses.