What Is Common Weakness Enumeration (CWE)?

TL;DR: Common Weakness Enumeration (CWE) is a community-developed list of software and hardware weakness types, maintained by MITRE Corporation. Where a CVE identifies a specific vulnerability in a specific product, a CWE identifies the underlying class of weakness that caused it — the category of flaw, not the individual instance. CWE gives security teams, developers, and auditors a shared vocabulary for discussing, classifying, and addressing the root causes of vulnerabilities.

CWE vs. CVE

CWE and CVE are both maintained by MITRE and both central to security practice, but they operate at different levels of abstraction:

The relationship between the two is directional: a CVE entry typically references the CWE that describes its root cause. Log4Shell (CVE-2021-44228) is classified under CWE-917 (Improper Neutralization of Special Elements used in an Expression Language Statement) because the underlying weakness type is expression language injection. Many different CVEs can share the same CWE — the CWE is the category, each CVE is a specific instance of it.

How CWE Is Used in Security

In vulnerability reporting and bug bounty programs. Security researchers reference CWE IDs in vulnerability reports to provide precise classification of what they found. A report that says "I found CWE-79 (Cross-Site Scripting) in the search parameter" communicates the weakness type unambiguously to a triage analyst, without requiring a full description of the vulnerability class. Bug bounty platforms and security assessment reports commonly include CWE references alongside CVSS scores.

In static application security testing (SAST). Code analysis tools map their findings to CWE IDs. A SAST tool that flags an unsanitized database query references CWE-89 (SQL Injection); one flagging missing output encoding references CWE-79 (XSS). CWE-based output makes tool findings directly comparable and easier to track across codebases and time.

In secure coding standards. Organizations like CERT, OWASP, and NIST reference CWE IDs in their secure coding guidelines, tying code-level recommendations to the weakness classifications they prevent. A developer following CERT C Secure Coding guidelines finds CWE references mapping each rule to the weakness types it addresses.

In procurement and compliance. Some security frameworks and government standards (including NIST guidelines and certain Common Criteria requirements) specify CWE-based requirements for software supply chain security, mandating that products demonstrate controls against specific weakness classes.

In threat intelligence and root cause analysis. When an incident occurs, post-mortem analysis often maps the exploited vulnerability to a CWE to identify patterns, whether a team is repeatedly introducing the same weakness classes, which CWEs appear most often in their codebase, and where secure development training should focus.

CWE Top 25 Most Dangerous Software Weaknesses

Each year, MITRE publishes the CWE Top 25 — a ranked list of the most dangerous software weakness types based on frequency and severity of vulnerabilities in the National Vulnerability Database. It functions similarly to the OWASP Top 10 but is drawn from empirical CVE data rather than survey-based expert opinion, and it's more granular — 25 specific weakness types rather than 10 broader categories.

The CWE Top 25 consistently includes:

• CWE-79: Cross-Site Scripting (XSS) — Improper neutralization of user input in web page generation
• CWE-89: SQL Injection — Improper neutralization of special elements in SQL commands
• CWE-787: Out-of-Bounds Write — Writing data outside the intended buffer boundary
• CWE-20: Improper Input Validation — Failure to validate or incorrectly validating input
• CWE-125: Out-of-Bounds Read — Reading data outside the intended buffer boundary
• CWE-416: Use After Free — Using memory after it has been freed
• CWE-22: Path Traversal — Improper limitation of a pathname to a restricted directory
• CWE-78: OS Command Injection — Improper neutralization of special elements in OS commands
• CWE-190: Integer Overflow — Arithmetic operation producing a value outside expected bounds
• CWE-502: Deserialization of Untrusted Data — Deserializing data from an untrusted source without validation
• CWE-77: Command Injection — Improper neutralization of special elements in command construction
• CWE-119: Buffer Errors — Improper restriction of operations within a memory buffer
• CWE-276: Incorrect Default Permissions — Overly permissive default access controls

The specific rankings shift year to year as new CVE data is incorporated, but the core weakness types remain consistent — these are the categories that developers and security teams most reliably introduce and attackers most reliably exploit.

The CWE Top 25 is most useful as a prioritization tool: if a secure code review or SAST scan identifies weaknesses across many CWE categories, the Top 25 provides a defensible starting point for remediation order.

Conclusion

CWE provides the taxonomy that makes security communication precise. Without it, "I found an injection vulnerability" could mean a dozen different things. With CWE-89, it means one specific thing — SQL Injection — with a known attack pattern, a known set of defenses, and a searchable reference library of prior incidents. For security researchers writing reports, developers remediating findings, and teams tracking weakness trends across their codebase, CWE IDs are the shared vocabulary that makes that communication efficient and actionable.