CWE Lookup Tool

Free CWE lookup. Search MITRE's Common Weakness Enumeration by ID, name or description — CWE-20, CWE-200, CWE-79 and the CWE Top 25, with mitigations.

Advertisement

CWE Lookup: Search Every Common Weakness Enumeration Entry

This CWE lookup tool searches the full MITRE Common Weakness Enumeration catalogue by ID, name or description and returns a structured page for each weakness — description and extended description, abstraction level, likelihood of exploit, consequences, mitigations, detection methods, code examples, and where the entry sits in the CWE Top 25. Type CWE-79, type 79, or type “path traversal”; all three get you to the same place. Every entry has its own permanent URL, so /tools/security/cwe-lookup/cwe-20 goes straight to Improper Input Validation.

The catalogue matters because vulnerability reports name weaknesses constantly and rarely explain them. A scanner flags CWE-209, a pen-test report cites CWE-863, a compliance questionnaire asks about the Top 25 — and each of those identifiers is a compressed reference to a specific, well-defined class of software defect. Looking it up is the difference between triaging a finding and guessing at it.

How to Use the CWE Lookup

  1. Search. Enter a CWE ID in any form (732, CWE-732, cwe732) for a direct jump, or type words from a weakness name or description for live search results.
  2. Or browse with filters. Narrow the catalogue by abstraction level (Pillar, Class, Base, Variant, Compound), by likelihood of exploit (High, Medium, Low), and by status (Stable, Draft, Incomplete, Deprecated) to find the right entry when you know the shape of the weakness but not its number.
  3. Use the quick links for the weaknesses that come up most: CWE-79, CWE-89, CWE-787, CWE-22 and CWE-352.
  4. Check the Top 25. The CWE Top 25 dashboard shows the current list with a year selector, so you can see how a weakness has moved across list years rather than reading one snapshot.
  5. Pivot to the CVE side. Once you know the weakness class, the CVE lookup tool covers the specific published vulnerabilities that instantiate it.

Weaknesses People Look Up Most

A handful of entries account for a large share of lookups, usually because a scanner or a report emitted the number without context. Here is what each of them actually means.

IDNameWhat it covers
CWE-20Improper Input ValidationThe product receives input but fails to validate that it has the properties required for safe processing. Extremely broad — a Class-level entry sitting above dozens of specific weaknesses.
CWE-200Exposure of Sensitive Information to an Unauthorized ActorInformation that should be restricted is exposed to someone not explicitly authorised to have it. Also Class-level, and often over-applied.
CWE-73External Control of File Name or PathUser input reaches a filesystem operation, letting an attacker steer reads or writes to files the application never intended to touch.
CWE-209Generation of Error Message Containing Sensitive InformationA stack trace, SQL fragment or internal path reaches the user. Individually low severity; valuable to an attacker as reconnaissance.
CWE-1236Improper Neutralization of Formula Elements in a CSV FileCSV injection. Stored input beginning with =, +, - or @ is interpreted as a formula when the export is opened in a spreadsheet, turning a data field into code execution on someone else’s desktop.
CWE-353Missing Support for Integrity CheckA protocol or format transmits data with no checksum or signature, so modification in transit cannot be detected.
CWE-863Incorrect AuthorizationAn authorization check exists but is performed incorrectly — distinct from CWE-862, Missing Authorization, where no check happens at all.
CWE-79Improper Neutralization of Input During Web Page GenerationCross-site scripting, in its reflected, stored and DOM-based forms.
CWE-89Improper Neutralization of Special Elements in an SQL CommandSQL injection.
CWE-787Out-of-bounds WriteMemory written past the end or before the beginning of a buffer — the memory-safety defect behind a large share of critical CVEs.

Abstraction Levels, and Why CWE-20 Is Discouraged for Mapping

CWE is a hierarchy, not a flat list, and the abstraction level of an entry determines whether it is an appropriate label for a specific bug. Pillars are the broadest groupings. Classes describe a weakness independent of language or technology. Base entries are specific enough to suggest both detection and mitigation. Variants are tied to a particular language, technology or platform. Compound entries describe weaknesses that arise from two or more others acting together.

This is where a lot of real-world confusion originates. MITRE now attaches vulnerability mapping guidance to each entry, and both CWE-20 and CWE-200 are marked Discouraged — they are Class-level entries so broad that labelling a bug with them conveys almost nothing actionable. If input validation failed, the useful mapping is the specific consequence: CWE-89 for SQL injection, CWE-79 for XSS, CWE-22 for path traversal, CWE-1236 for CSV injection. A finding tagged CWE-20 usually means the tool that produced it could not determine the specific weakness, which is itself a useful piece of triage information. The filters in this tool make that concrete: restrict a browse to Base-level entries and you are looking at exactly the population that makes for good mappings.

A Worked Example: CWE-209 in Practice

Suppose a scan reports CWE-209 on a login endpoint. The entry tells you the weakness is an error message carrying sensitive information, but the triage question is what information and to whom. Consider a form that returns “No account exists for that email address” on one path and “Incorrect password” on another. No stack trace, no internal path — and yet the pair of messages is a username enumeration oracle: an attacker learns which addresses are registered, which turns a credential-stuffing list from speculative to targeted. The mitigation is not to sanitise a stack trace but to collapse both cases into one generic message and log the detail server-side. That is why reading the entry’s consequences and mitigations matters more than reading its title; the title alone would have sent you looking for exception handling.

The CWE Top 25

The annual CWE Top 25 Most Dangerous Software Weaknesses is derived from the previous year’s published CVEs, scoring each weakness by how often it appears and how severe the resulting vulnerabilities are. It is a measurement of the CVE corpus rather than an expert opinion poll, which is what makes year-on-year movement meaningful: CWE-787 out-of-bounds write topped the 2023 list, while cross-site scripting (CWE-79) took the top position in 2024, with injection, out-of-bounds access, CSRF and path traversal persistently in the upper ranks.

Treat the list as a prioritisation aid, not a checklist. It reflects what gets reported and scored, which skews toward weakness classes that are easy to detect and easy to attribute. Memory-safety defects dominate because C and C++ codebases are heavily audited; a class of logic flaw that scanners cannot find will not appear regardless of how damaging it is. The year selector on the Top 25 dashboard exists precisely so you can see which entries are structurally persistent and which are artefacts of a single year’s reporting.

CWE, CVE and CAPEC

Three MITRE catalogues are routinely confused. CWE describes weakness types — the category of mistake, such as “SQL injection”. CVE identifies specific vulnerabilities in specific products — one occurrence of a weakness in one version of one piece of software. CAPEC catalogues attack patterns — the techniques an adversary uses against those weaknesses. A single CWE maps to thousands of CVEs; a single CVE maps to one or a few CWEs. When a report says “CWE-89” it is telling you what kind of defect exists; when it says “CVE-2024-XXXXX” it is telling you which product and version is affected, which is the one you patch.

Frequently Asked Questions

What is CWE-20?

Improper Input Validation: the product receives input but does not validate, or incorrectly validates, that it has the properties needed for safe processing. It is a Class-level entry that MITRE marks as discouraged for vulnerability mapping, because a more specific Base-level weakness almost always describes the actual bug better.

What is CWE-200?

Exposure of Sensitive Information to an Unauthorized Actor — information the product should restrict is made available to someone without authorisation. Like CWE-20 it is broad and discouraged for mapping; look for the specific mechanism, such as CWE-209 for error messages or CWE-532 for log files.

How do I search the CWE database?

Enter an ID in any format for a direct lookup, or type words from a weakness name or description for live search. You can also browse with filters for abstraction level, likelihood of exploit and status.

What is the difference between CWE and CVE?

CWE names a type of weakness; CVE identifies a specific vulnerability in a specific product and version. Many CVEs share one CWE.

Is this CWE lookup free?

Yes — free, with no registration and no query limits.

What is the CWE Top 25?

An annual ranking of the most dangerous software weaknesses, calculated from the frequency and severity of the previous year’s CVEs. The dashboard here includes a year selector so you can compare list years.

What do the abstraction levels mean?

Pillar is the broadest grouping, Class is technology-independent, Base is specific enough to guide detection and mitigation, Variant is tied to a specific language or platform, and Compound describes weaknesses formed from several others.

What is the difference between CWE-862 and CWE-863?

CWE-862 is Missing Authorization — no check is performed. CWE-863 is Incorrect Authorization — a check runs but reaches the wrong conclusion, for example comparing the wrong identifier or failing open on error.

Which CWE should I use in a vulnerability report?

The most specific entry that accurately describes the defect, preferring Base-level entries and avoiding those marked discouraged or prohibited for mapping. Each entry page shows its mapping guidance.

Where does this data come from?

MITRE’s official CWE catalogue, cached for fast lookups and refreshed against the upstream source, with the CWE version and release date shown so you know which catalogue revision you are reading.

What Is CWE (Common Weakness Enumeration)

CWE (Common Weakness Enumeration) is a community-developed catalog of software and hardware security weakness types maintained by MITRE Corporation. Each CWE entry describes a specific class of vulnerability—such as buffer overflow, SQL injection, or improper authentication—with a unique identifier (e.g., CWE-79 for Cross-Site Scripting), technical description, examples, mitigations, and relationships to other weaknesses.

While CVE (Common Vulnerabilities and Exposures) identifies specific vulnerabilities in specific products, CWE classifies the underlying weakness patterns that cause vulnerabilities. A single CWE can be the root cause of thousands of CVEs. Understanding CWEs helps developers write more secure code, security teams prioritize remediation efforts, and organizations build systematic defenses against entire categories of vulnerabilities.

How CWE Is Organized

CWE uses a hierarchical structure with multiple abstraction levels:

LevelDescriptionExample
PillarHighest abstraction (broad categories)CWE-664: Improper Control of a Resource
ClassA general weakness categoryCWE-20: Improper Input Validation
BaseA specific weakness typeCWE-89: SQL Injection
VariantA detailed sub-typeCWE-564: SQL Injection: Hibernate

MITRE CWE Top 25 Most Dangerous Software Weaknesses (2024 selection):

RankCWENameImpact
1CWE-79Cross-Site Scripting (XSS)Code execution in browsers
2CWE-787Out-of-Bounds WriteMemory corruption, code execution
3CWE-89SQL InjectionData breach, data manipulation
4CWE-352Cross-Site Request ForgeryUnauthorized actions
5CWE-22Path TraversalUnauthorized file access
6CWE-125Out-of-Bounds ReadInformation disclosure
7CWE-78OS Command InjectionSystem compromise
8CWE-416Use After FreeMemory corruption
9CWE-862Missing AuthorizationUnauthorized access
10CWE-434Unrestricted File UploadCode execution

Common Use Cases

  • Secure development: Reference CWE entries during code review to identify and prevent common weakness patterns
  • Vulnerability classification: Map CVEs to their underlying CWEs to understand root causes and prioritize systemic fixes
  • Security training: Use CWE descriptions and examples to educate developers about specific vulnerability categories
  • Tool evaluation: Assess SAST/DAST tools by which CWEs they can detect (CWE coverage)
  • Compliance: CWE is referenced by PCI-DSS, NIST SSDF, and OWASP standards for vulnerability classification

Best Practices

  1. Focus on the CWE Top 25 — These weaknesses cause the most real-world vulnerabilities; prioritize defenses against them
  2. Map your vulnerabilities to CWEs — Understanding root cause categories reveals systemic issues that point fixes miss
  3. Use CWE to guide SAST tool selection — Evaluate static analysis tools by their CWE detection coverage for your technology stack
  4. Integrate CWE into developer training — Train developers on the specific CWEs most relevant to your application's technology stack
  5. Track CWE trends over time — If your team consistently introduces CWE-79 (XSS) bugs, invest in framework-level protections and targeted training
This tool is provided for informational and educational purposes only. All processing happens in your browser — no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results.