CWE (Common Weakness Enumeration) is a community-developed catalog of software and hardware weakness types, maintained by MITRE, that gives each kind of flaw a stable identifier such as CWE-79 or CWE-787. In cybersecurity vulnerability management, CWE describes the root cause of a vulnerability, the type of mistake in design or code, rather than any single occurrence of it in a particular product.
CWE provides a shared vocabulary for developers, testers, tool vendors and security teams. A static analysis finding, a penetration test report and a published vulnerability record can all point to the same CWE entry, which makes it possible to count, compare and prevent recurring classes of mistakes rather than fixing bugs one by one.
How CWE entries are structured
Each CWE entry describes one weakness with a name, description, extended explanation, applicable platforms, common consequences, demonstrative examples, detection methods and potential mitigations. Entries also record relationships to other weaknesses, so the catalog forms a navigable graph rather than a flat list.
Weaknesses are organized by level of abstraction. The level determines how specific an entry is and whether it should be used to classify a concrete vulnerability.
| Level | Specificity | Example |
|---|---|---|
| Pillar | Highest-level theme | CWE-664 Improper control of a resource through its lifetime |
| Class | Abstract, language-independent | CWE-20 Improper input validation |
| Base | Specific enough to detect and fix | CWE-89 SQL injection |
| Variant | Tied to a language or technology | CWE-564 SQL injection through Hibernate |
| Compound | Chain or composite of weaknesses | A chain leading from integer overflow to buffer overflow |
Besides weaknesses, CWE contains categories, which group entries by a shared attribute, and views, which present the catalog from a particular perspective, such as research concepts, software development or hardware design.
CWE compared with CVE, CVSS and CAPEC
CWE is one of several complementary standards in vulnerability management, and confusing them is common. The key difference is that CWE names a type of weakness, while CVE names one specific vulnerability in one product.
| Standard | What it identifies | Example |
|---|---|---|
| CWE | Type of weakness, the root cause | CWE-416 Use after free |
| CVE | One specific vulnerability instance | A use-after-free flaw in one browser version |
| CVSS | Severity score of a vulnerability | Base score from 0.0 to 10.0 |
| CAPEC | Attack pattern exploiting weaknesses | SQL injection as an attack technique |
| OWASP Top 10 | Awareness list of web risk categories | Injection, broken access control |
A typical CVE record references one or more CWE identifiers to explain why the vulnerability exists, and a CVSS score expresses how severe it is. Related vulnerability types such as buffer overflow, privilege escalation and remote code execution appear in CWE in different roles: buffer overflow is a weakness, whereas remote code execution and privilege escalation describe consequences of exploiting weaknesses.
Frequently referenced CWE entries
MITRE publishes an annual CWE Top 25 Most Dangerous Software Weaknesses list, ranked using real vulnerability data weighted by frequency and severity. The ranking changes from year to year, but a stable core of entries recurs. The table lists weaknesses that appear consistently near the top.
| Identifier | Weakness | Typical consequence |
|---|---|---|
| CWE-79 | Cross-site scripting | Session theft, actions in the victim’s browser |
| CWE-787 | Out-of-bounds write | Memory corruption, code execution |
| CWE-89 | SQL injection | Data theft or modification |
| CWE-416 | Use after free | Code execution in native software |
| CWE-78 | OS command injection | Arbitrary command execution on the server |
| CWE-22 | Path traversal | Reading or writing files outside the intended directory |
| CWE-862 | Missing authorization | Access to functions without permission |
| CWE-352 | Cross-site request forgery | Unwanted actions on behalf of a user |
The list is a prioritization aid, not a complete security standard. An application free of the Top 25 can still contain serious weaknesses from the hundreds of other entries in the catalog.
Using CWE in development and vulnerability management
CWE delivers most value when it connects findings across the software lifecycle. Different roles use it for different purposes, as the table shows.
| Role | Use of CWE | Benefit |
|---|---|---|
| Developers | Secure coding guidance per weakness | Fixing the cause, not only the symptom |
| Security testers | Classifying findings consistently | Comparable reports across tools |
| Tool vendors | Mapping rules to CWE identifiers | Transparent detection coverage |
| Vulnerability analysts | Assigning root causes to CVE records | Trend analysis by weakness type |
| Product security leaders | Tracking weakness counts over time | Targeted training and design changes |
Correct mapping requires the right abstraction level. MITRE guidance favors Base or Variant entries for classifying real vulnerabilities and marks many categories and views as discouraged or prohibited for mapping, because a label such as “input validation” is too vague to drive a fix.
Limitations and common mistakes
CWE is a classification system and inherits the ambiguity of real software flaws. The following problems appear repeatedly in practice.
- Mapping too high: using CWE-20 for every injection hides the specific weakness and its fix.
- Confusing consequence with cause: remote code execution is an outcome, not a CWE root cause.
- Single-label thinking: many vulnerabilities involve a chain of weaknesses that deserves several identifiers.
- Treating CWE as a severity rating: the same CWE can produce trivial or critical vulnerabilities depending on context.
- Assuming tool labels are correct: scanners often map findings loosely and need human review.
In plain words
Doctors use standard names for diseases so that everyone means the same thing. CWE does the same for mistakes in software and hardware design. Each type of mistake has a number and a description, such as CWE-89 for a database query that trusts user input.
When a security problem is found, CWE says what kind of mistake caused it. That helps teams learn from patterns, train developers and stop making the same mistake again in other products.
A real-world example
A software company that sells a web-based customer portal reviews its security findings from the past two years. The 140 findings came from penetration tests, a static analysis tool and customer reports, each described in different terms, so management cannot see where the real problems lie.
The product security team maps every finding to a Base-level CWE entry. The analysis shows that more than a third of the findings fall under just two entries: CWE-862 missing authorization and CWE-79 cross-site scripting. Most authorization flaws trace back to individual endpoints that each implemented their own permission checks.
The company introduces a central authorization layer and a templating engine with automatic output encoding, and adds both CWE entries to its developer training. Within the next year, new findings in these two categories drop sharply, and CWE-based reporting becomes part of each release review.