A CVE tells you that a particular version of a particular product has a particular flaw. CWE answers the next question: what kind of mistake caused it? That shift from instance to root cause is what makes CWE useful to people who build software, and to threat modelers looking for design-level problems before any CVE could exist.
What CWE contains
The Common Weakness Enumeration is maintained by MITRE, with community input, and covers both software and hardware weaknesses. Each entry includes:
- An ID and name, such as CWE-89 Improper Neutralization of Special Elements used in an SQL Command ("SQL injection").
- A description of the weakness and how it arises.
- Consequences, expressed in terms close to the CIA triad: read data, modify data, denial of service.
- Demonstrative examples in code.
- Potential mitigations and the development phase where they apply.
- Relationships to other CWEs and to CAPEC attack patterns.
Abstraction levels
CWE entries sit at different levels of detail, which matters when you choose one to cite:
| Level | What it describes | Example |
|---|---|---|
| Pillar | The most abstract theme | CWE-284 Improper Access Control |
| Class | A general weakness, independent of language or technology | CWE-285 Improper Authorization |
| Base | A specific weakness, detailed enough to detect and prevent | CWE-639 Authorization Bypass Through User-Controlled Key |
| Variant | A base weakness tied to a specific language or technology | CWE-564 SQL Injection: Hibernate |
Base-level entries are usually the right choice for findings: specific enough to act on, general enough to apply across your codebase.
The CWE Top 25
Each year MITRE and CISA publish the CWE Top 25 Most Dangerous Software Weaknesses, ranked by how often each weakness appears behind recent CVEs and how severe those CVEs are. The 2025 list was calculated from the weaknesses behind about 39,000 CVE records published between June 2024 and June 2025. Its top three:
- CWE-79 Cross-site Scripting
- CWE-89 SQL Injection
- CWE-352 Cross-Site Request Forgery
Authorization weaknesses such as CWE-862 Missing Authorization and CWE-863 Incorrect Authorization are also consistently near the top. The Top 25 is a good shortlist for secure coding training and for deciding what your static analysis must catch.
CWE, CVE and CAPEC together
The three MITRE catalogues describe the same event from three angles:
- CWE, the weakness: authorization bypass through a user-controlled key (CWE-639).
- CAPEC, the attack pattern: an attacker manipulates an identifier to reach another user's data.
- CVE, the instance: that weakness, exploited in that way, in a specific version of a specific product.
Worked example: Invoicely
Mapping the top Invoicely threats to CWE turns each one into a precise root cause with known fixes:
| Threat | CWE |
|---|---|
| T2 IDOR on invoice endpoints | CWE-639 Authorization Bypass Through User-Controlled Key |
| T1 Credential stuffing | CWE-307 Improper Restriction of Excessive Authentication Attempts |
| T4 Forged payment webhook | CWE-347 Improper Verification of Cryptographic Signature |
| T7 Stored XSS in invoice notes | CWE-79 Cross-site Scripting |
| T6 No audit log in admin console | CWE-778 Insufficient Logging |
None of these would ever get a CVE, because Invoicely's code isn't distributed. The CWE ID still gives developers the right page to read and gives auditors a standard reference.
Using CWE in a threat model
- Name the root cause. Add a CWE ID to each threat once you've identified the weakness. It makes duplicates obvious: three threats with CWE-639 are one missing pattern, not three bugs.
- Feed it into testing. Static analysis and scanner results are labelled with CWE IDs, so findings can be matched against your threat model.
- Watch for design weaknesses. Some CWEs, such as CWE-653 Improper Isolation or Compartmentalization, describe architecture rather than code, and are exactly what a DFD review finds.
Common mistakes
- Citing a pillar. "CWE-284 Improper Access Control" is true of nearly every access bug and tells a developer nothing.
- Confusing CWE with severity. A CWE is a category; how bad it is depends on where it occurs.
- Treating the Top 25 as complete. It's ranked by what gets reported in CVEs, which under-represents design flaws in in-house systems.
Key takeaways
- CWE catalogues types of weakness; CVE identifies specific vulnerabilities; CAPEC catalogues attack patterns. Weakness, instance, technique.
- CWE entries are organised by abstraction: pillar, class, base and variant. Base-level entries are the most useful for developers.
- The 2025 CWE Top 25 is led by cross-site scripting (CWE-79), SQL injection (CWE-89) and CSRF (CWE-352).
- In a threat model, a CWE ID turns a vague finding into a precise, searchable root cause with known mitigations.
Frequently asked questions
What is the difference between CWE and CVE?
CWE describes a type of weakness, such as SQL injection (CWE-89). CVE identifies one specific vulnerability in one product, such as a particular SQL injection in a particular version of a CMS. One CWE can be behind thousands of CVEs.
What is the CWE Top 25?
An annual list, published by MITRE with CISA, of the 25 most dangerous software weaknesses, ranked by how often they appear in recent CVE records and how severe those CVEs are. In the 2025 list, CWE-79 (cross-site scripting) is first, followed by CWE-89 (SQL injection) and CWE-352 (cross-site request forgery).
What is the difference between CWE and CAPEC?
CWE describes the weakness in the system; CAPEC describes the attack pattern that exploits it. CAPEC entries reference the CWEs they target, so the two catalogues can be used together.
How many CWE entries are there?
Over 900 weakness entries, plus categories and views that group them. Most teams only ever use a small subset, such as the Top 25 or the entries mapped to the OWASP Top 10.