Common Weakness Enumeration (CWE)

What is CWE?

CWE is a dictionary of weakness types. In MITRE's framing, a weakness is a condition in software, firmware, hardware or a service that can, in the right circumstances, give rise to vulnerabilities. Each entry has a stable ID, a description, examples, detection methods and mitigations, and relationships to broader and narrower entries. The list is maintained by MITRE alongside the CVE Program; the current release at the time of writing is version 4.20.

CWE IDs show up everywhere a finding is classified: the problemTypes field of a CVE record, SAST and DAST output, pentest reports, bug bounty triage, and the category definitions of the OWASP Top 10.

Weakness vs vulnerability

A weakness is the kind of mistake. A vulnerability is one instance of it, in one product, that someone can exploit. The CVE Program's glossary puts it the same way: a vulnerability is "an instance of one or more weaknesses in a Product".

• CWE-89 (SQL injection) is a weakness. It exists in thousands of products.
• CVE-2023-34362 is a vulnerability: one SQL injection in MOVEit Transfer, which CISA lists as exploited in the wild.

How is CWE organized?

Weakness entries sit at four levels of abstraction, and picking the right level is most of the skill in using CWE.

Two other entry types are not weaknesses. Categories group entries by a shared attribute (for example CWE-1018 Manage User Sessions). Views are curated slices of the whole list: CWE-1000 (Research Concepts) is the full hierarchy, CWE-699 (Software Development) organizes roughly 400 entries in developer terms, and CWE-1003 is a smaller set used for mapping NVD data.

What do "Allowed" and "Discouraged" mean?

Every entry carries a vulnerability mapping usage label telling you whether it is appropriate for classifying a real vulnerability:

• Allowed: fine for mapping. This is the usual label on Base and Variant entries, such as CWE-639 and CWE-918.
• Allowed-with-Review: usable in limited cases after reading the entry's mapping notes. CWE-862 Missing Authorization and CWE-863 Incorrect Authorization are both labeled this way.
• Discouraged: should not be used for real-world vulnerabilities. Many Pillars and Classes, including CWE-284, CWE-285, CWE-20 Improper Input Validation, CWE-119 and CWE-200.
• Prohibited: must never be used. All Categories, such as CWE-1018.

MITRE's root cause mapping guidance says to prefer Base and Variant entries, use a Class only when nothing more specific fits, and never map to a Category. The reasoning is practical: "Improper Input Validation" says nothing a developer can act on, while "SQL injection in the search endpoint" tells them which fix to apply.

In practice, discouraged mappings are common. The real CVE record for Citrix Bleed (CVE-2023-4966) maps to CWE-119, a Discouraged Class. When you inherit a mapping from a CVE, a scanner or a report, check its label before you aggregate on it.

Worked example: mapping one bug

A tester reports this on a multi-tenant app. user_a owns project_1043; project_2210 belongs to another tenant.

GET /api/v1/projects/2210 HTTP/1.1
Host: app.example
Authorization: Bearer <user_a token>

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 2210, "name": "demo-project", "plan": "free", "tenant": "tenant_b"}

Mapping it:

1. Describe the root cause, not the symptom. The symptom is that another tenant's data came back. The cause is that the server looked up a record by an ID the client supplied and never checked the record belonged to the caller.
2. Resist the symptom entry. CWE-200 Exposure of Sensitive Information fits the outcome, but it is Discouraged and describes almost every data-leak bug ever reported.
3. Search at the Base level. Searching "authorization user-controlled key" finds CWE-639 Authorization Bypass Through User-Controlled Key, a Base entry labeled Allowed whose description matches: the system's authorization check fails to stop one user reaching another's data by changing a key value.
4. Check the parents and children. CWE-639's parent is CWE-863 (Class, Allowed-with-Review), whose parent is CWE-285 (Class, Discouraged), under the Pillar CWE-284 (Discouraged). None is more precise. Its child, CWE-566, applies only if the ID is a SQL primary key used directly in a query. If the tester confirmed that from source code, CWE-566 is the tighter mapping; from black-box evidence alone, CWE-639 is the defensible choice.
5. Rule out the sibling. If the endpoint had no authorization check of any kind, CWE-862 Missing Authorization would compete. Here the endpoint does check that the token is valid; it fails only on object ownership, so CWE-639 stands.

Result: CWE-639. The same bug is what the web world calls IDOR and the API world calls BOLA, which is why a stable CWE ID is useful when tools and teams use different names.

What is the CWE Top 25?

The CWE Top 25 ranks the weaknesses behind the most common and severe recent CVEs. The current edition, released December 15, 2025, analyzed 39,080 CVE records published between June 1, 2024 and June 1, 2025, scoring each CWE by how often it was mapped times the average CVSS score of those CVEs. The top ten:

Further down, CWE-20, CWE-284 and CWE-200 sit at 18, 19 and 20: the ranking reflects how CNAs actually mapped CVEs, so Discouraged entries still appear. CWE-639, the entry from the worked example, is 24th. The KEV column tells a different story from the rank: XSS is first by score, while OS command injection, use-after-free and out-of-bounds write account for more known exploited vulnerabilities.

Common mistakes

• Mapping to the symptom. "Information exposure" and "input validation" describe outcomes. Map to what the developer did wrong.
• Stopping at a Pillar or Class. It feels safe and tells nobody what to fix.
• Treating the Top 25 as your list. It describes CVEs in shipped products. Your own application's findings, especially authorization and business logic flaws, will have a different distribution.

Written by Parameter · Last reviewed September 27, 2026