Common Weakness Enumeration

What is CWE?

Targeted at both the product development community and the community of security practitioners, Common Weakness Enumeration (CWE™) is a list of software and hardware weaknesses that can occur in architecture, design, code, or implementation that can lead to exploitable vulnerabilities. CWE serves as a common language for describing security weaknesses; serves as a standard reference mechanism for security tools targeting these weaknesses; and provides a common baseline standard for weakness identification, mitigation, and prevention efforts.

What is a weakness in the context of CWE?

A “weakness” is a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities.

What is the difference between a weakness and a vulnerability?

A weakness is an underlying condition that can lead to vulnerabilities in a variety of products. A vulnerability, such as those enumerated on the Common Vulnerabilities and Exposures (CVE™) List, is a specific instance of one or more weaknesses in a specific product that can be exploited, causing a negative impact to confidentiality, integrity, or availability.

Why CWE?

The main goal of the CWE initiative is to stop the proliferation of vulnerabilities at the source by educating software and hardware architects, designers, developers, programmers, and consumers on how to eliminate them by avoiding weaknesses earlier in the development lifecycle, where it is easier and cheaper to do so. CWE serves as a resource for a variety of use cases, including:

• Programmers as they write code
• Architects as they design new software
• Hardware Engineers as they create physical components
• Educators in teaching security as part of curriculum for software and hardware engineering, computer science, and information system management

CWE is industry-supported by the cybersecurity community, which includes representatives from major operating systems vendors, commercial information security tool vendors, academia, government agencies, and research institutions. Community members participate in the development of CWE in various working groups and through the Content Development Repository (CDR). This means the CWE List reflects the insights and combined expertise of the broadest possible collection of information technology and cybersecurity professionals.

CWE continues to evolve as a collaborative community effort to identify and define cybersecurity weaknesses in a publicly available information corpus.

Can’t hackers use this to break into my network, system, or product?

Any public discussion about cybersecurity weaknesses and/or potential resulting vulnerabilities may help an attacker. However, there are several reasons why the benefits of CWE outweigh its risks:

• CWE allows developers to minimize weaknesses as early in the lifecycle as possible, improving its overall security.
• For product developers and project maintainers, accurate root cause mapping between vulnerabilities (e.g., CVE Records) and weaknesses (e.g., CWEs) is valuable because it directly illuminates where investments, policy, and practices can address the root causes responsible for vulnerabilities so that they can be eliminated.
• CWE helps reduce cybersecurity risk industry-wide by enabling more effective community discussion about finding and mitigating these weaknesses in existing software and hardware, and reducing them in future updates and releases.
• CWE enables more effective description, selection, and use of security tools and services that organizations can use to find these weaknesses and reduce their risk now.
• There is a shift in community opinion towards sharing information, as reflected in the success of the collaborative nature of similar programs such as Common Vulnerabilities and Exposures (CVE™), MITRE ATT&CK, FIRST, the “CWE Top 25” and “Most Important HW Weaknesses List”, and the vibrant CWE Program working group activities that include subject matter experts from across industry, government, and academia.

How can CWE help me?

Knowing the weaknesses that result in vulnerabilities means they can be eliminated before deployment, when it is much easier and cheaper to do so.

Software and hardware product developers and security practitioners are using CWE today as a common language for discussing how to eliminate and/or mitigate software security weaknesses in software and hardware architecture, design, code, and implementation before they become exploitable vulnerabilities. Organizations also use CWE to help evaluate security tools targeting these weaknesses, and as a common baseline standard for their weakness identification, mitigation, and prevention efforts.

Is CWE free for public use?

CWE is free to use by any organization or individual for any research, development, and/or commercial purposes, per the CWE Terms of Use. The MITRE Corporation has copyrighted the CWE List, Top 25 list, and Most Important Hardware Weaknesses list for the benefit of the community in order to ensure each remains a free and open standard, as well as to legally protect the ongoing use of it and any resulting content by government, vendors, and/or users. MITRE has trademarked ™ the CWE acronym, and related acronyms, and the CWE logo, and related logos, to protect their sole and ongoing use by the CWE effort within the information security arena. Please contact us if you require further clarification on this issue.

What is the relationship between CWE and CVE?

CWE and Common Vulnerabilities and Exposures (CVE™) are sister programs with separate but complimentary missions. As CWE provides a common language for software and hardware weaknesses, CVE provides the de facto global standard for identifying vulnerabilities. Since one kind of weakness can be the root cause of many specific vulnerabilities in a variety of specific products, one CWE entry can often be the root cause of many different CVE Records.

For more information about the history of CWE and its relationship with CVE, see the CWE History page.

What is the relationship between CWE and NVD?

CWE and the U.S. National Vulnerability Database (NVD) are two separate programs. As a downstream consumer of CVE Program information, the NVD is a government repository of standards-based vulnerability management data that is based on CVE. NVD has historically added CWE mappings to CVE Records using the CWE-1003 view, as well as CVSS and CPE information.

What is the relationship between CWE and CAPEC?

While CWE is a list of software and hardware weakness types, Common Attack Pattern Enumeration and Classification (CAPEC™) is a list of the most common methods attackers use to exploit these weaknesses. Used together, CWE and CAPEC provide security information and guidance to equip the software development, hardware design, and broader cybersecurity community with the information they need to help them build more secure software and hardware.

Who pays for CWE? Who is the sponsor?

CWE is sponsored by the office of the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). This CWE website is sponsored and managed by MITRE to enable stakeholder collaboration.

What is MITRE’s role in CWE?

The MITRE Corporation (MITRE) maintains the CWE List and its follow-on efforts (i.e., the CWE Top 25 and CWE Most Important Hardware Weaknesses lists); moderates the CWE Board, community email lists, and working groups; and provides neutral guidance throughout the process to ensure that CWE serves the public interest.

Who is the CWE Community? How can my organization and I be involved?

An integral component of the CWE effort is broad community participation. The CWE community includes:

• A CWE Board comprised of members from around the world that set and promote the goals and objectives of the CWE Program to ensure the ongoing adoption, coverage, and quality of CWE
• CWE special interest groups (SIGs) and working groups (WGs), each focused on specific areas of the program
• Individual researchers and representatives from numerous organizations from across industry, academia, and government interested in actively reducing and managing weaknesses in software and hardware who:
  
  • Participate in content development and other conversations on the CWE Research Discussion List
  • Submit software and hardware weaknesses and related content for the CWE List
  • Engage with us and the community to help promote CWE on social media
  • Advocate for the expansion and active use of CWE and the CWE Top-N lists by the community

To participate, join a CWE working group or special interest group, subscribe to the CWE Research Discussion List, submit software and hardware weaknesses and related content for the CWE List, and/or advocate for the expansion and active use of CWE per above.

What is the role of the CWE Research Email Discussion List and how can I join?

The CWE Research Email Discussion List is a lightly moderated public forum to discuss CWE definitions, suggest potential definition expansion(s), and/or submit new definitions. General discussion of the weaknesses themselves is also welcome.

Active participation is an important part of the CWE effort. Members of the information security community are all invited to participate. A confirmation will be sent to you verifying your addition to the list(s). View our Privacy Policy.

Is someone from CWE available to speak or participate on panel discussions at industry-related events, meetings, etc.?

Yes, contact us at cwe@mitre.org to provide additional information.

What types of software and hardware weaknesses are included on the CWE List?

See What is a weakness in the context of CWE? above. Visit the CWE List page for the most current list.

What is a CWE-ID? How is it used?

CWE Identifiers, also known as CWE-IDs or CWEs, are organized into four main types: Category, Compound Element, View, and Weakness.

• Weakness IDs – assigned to the actual weaknesses themselves, such as CWE-311: Missing Encryption of Sensitive Data or CWE-326: Inadequate Encryption Strength. Within Weakness IDs, there are four sub-classifications: “Pillar”, which are the more abstract representations; “Class”, typically independent of any specific language or technology such as CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'); “Base”, which is a more specific type of weakness that is still mostly independent of a specific resource or technology such as CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'); and “Variant”, which is a weakness specific to a particular resource, technology, or context such as CWE-83: Improper Neutralization of Script in Attributes in a Web Page.
• Category IDs – assigned to collections of weaknesses sharing a common attribute(s). For example, Category-557: Concurrency Issues or Category-355: User Interface Security Issues, where the shared attributes may be any number of things including, but not limited to, functional area (e.g., authentication, cryptography) and the relevant resource (e.g., credentials management, certificate issues).
• View IDs – assigned to predefined perspectives with which one might look at the weaknesses in CWE. For example, Category-699: Software Development is geared towards architects, designers, coders, and testers whose goal is to eliminate mistakes from a software application, while Category-1000: Research Concepts is oriented towards academic research, creating a new framework for classifying weaknesses.
• Compound Element IDs – assigned to meaningful aggregations of several weaknesses, as in a composite or chain. For example, in a chain such as CWE-252: Unchecked Return Value that can result in CWE-476: NULL Pointer Dereference, or in a composite such as CWE-352 Cross-Site Request Forgery.

CWE is searchable by individual CWE-ID number on the CWE website homepage, and from the search field in the upper right corner of the CWE website masthead. In addition, links to specific CWE-IDs for the predefined Views, Graphs, Explicit Slices, Implicit Slices, Composites, and Named Chains perspectives are available on the CWE List page.

What information is included in a CWE weakness entry?

Each CWE entry includes a variety of information types elements to define and describe an individual weakness such as a description, common consequences, and potential mitigations. Refer to the CWE Schema and Schema Documentation for more information.

Is there a glossary or key available to help me understand CWE terminology?

Yes, see CWE Glossary for a list of basic terminology and Schema Documentation for the schema elements key.

Why is there a printable version of the CWE List? What information is included in it?

The Printable Version of CWE was created for those wishing to view and use the CWE List in PDF or printed format. The printable version includes a complete list of all CWE entries from the most current release in numerical order along with a table of contents, an index, and the CWE-ID in the facing margins for easy searching through a printed copy. Many organizations use printed copies of CWE for design review meetings and training.

How can I get a complete copy of the CWE List?

CWE is provided in multiple formats on the CWE List, Downloads, and Archive pages.

CWE is also available via a REST API. For more information, see the CWE REST API Quick Start Instructions.

What is included in the CWE List ZIP download file?

The ZIP download file in the Downloads section of the CWE List page contains the selected view in XML format. Additionally, every View across CWE has ZIP download files, in different formats.

Are Change Logs available for the different release versions of the CWE List?

Yes, see Reports. Change information for a CWE entry can also be obtained from the Content_History element.

How can I use the CWE schema?

The CWE Schema is provided for validating the various XML downloads files of individual CWE entries provided on the CWE List page. See the Schema Documentation for additional information.

Does CWE have a REST API?

Yes, for more information, see the CWE REST API Quick Start Guide.

Can I explore large sets of CWEs that are grouped according to a particular use case?

Yes, the following are available:

• Development Concepts — This view organizes weaknesses around concepts that are frequently used or encountered in software development. Accordingly, this view can align closely with the perspectives of developers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and mapping.
• Research Concepts (All Weaknesses) — This view is intended to facilitate research into weaknesses, including their inter-dependencies, and can be leveraged to systematically identify theoretical gaps within CWE. It classifies weaknesses in a way that largely ignores how they can be detected, where they appear in code, and when they are introduced in the software development life cycle. Instead, it is mainly organized according to abstractions of software behaviors.
• Hardware Design — This view organizes weaknesses around concepts that are frequently used or encountered in hardware design. Accordingly, this view can align closely with the perspectives of designers, manufacturers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and vulnerability root cause mapping.
• Comprehensive Categorization for Software Assurance Trends — This view organizes weaknesses around categories that are of interest to large-scale software assurance research to support the elimination of weaknesses using tactics such as secure language development. It is also intended to help tracking weakness trends in publicly disclosed vulnerability data. This view is comprehensive in that every weakness must be contained in it, unlike most other views that only use a subset of weaknesses. This view is structured with categories at the top level, with a second level of only weaknesses. Each weakness is added to only one category. All categories are mutually exclusive; that is, no weakness can be a member of more than one category. While weaknesses defy strict categorization along only one characteristic, the forced bucketing into a single category can simplify certain kinds of analysis.
• Comprehensive CWE Dictionary — This view lists all elements on the CWE List by CWE-ID. This view can be useful to any researcher, educator, software developer, or other organization interested in locating specific weakness types.
• PDFs with Graphical Depictions of CWE — This view repository provides graphical representations of various CWE views as PDF files. It can be used to quickly see the structure implied by the parent relationships in those views. Also, some files provide “coverage graphs” in which the members of a smaller view are highlighted within the context of a larger view, illustrating how the entries of the smaller view are organized by the larger view.

What are the Composites and how can they help me?

“Composite” entries are those instances in which two or more distinct weaknesses must be present at the same time in order for a potential vulnerability to arise, and where removing any of the weaknesses eliminates or sharply reduces the risk.

For example:

• CWE-690: Unchecked Return Value to NULL Pointer Dereference — Requires CWE-252: Unchecked Return Value through CWE-476: NULL Pointer Dereference to be present
• CWE-352: Cross-Site Request Forgery (CSRF) — Requires four CWEs, CWE-346: Origin Validation Error, CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'), CWE-613: Insufficient Session Expiration, and CWE-642: External Control of Critical State Data, to be present

By eliminating any single component, a developer can prevent the composite from becoming exploitable. Often the various components of a composite are found in different aspects of a software system, either in the architecture, design, code, or implementation, which means that multiple assessment methods may be needed to find them or that one type of assessment method — like a static analysis tool can find issues in code but not in design, architecture, or implementation.

A report of Composites is provided here.

What are Named Chains and how can they help me?

A “Chain” is a sequence of two or more separate weaknesses that can be closely linked together within software, where one weakness can directly or indirectly create the conditions that are necessary to cause another weakness. The “Named Chains” are those chains that appear so frequently in software that a CWE-ID has been assigned to it, such as CWE-680: Integer Overflow to Buffer Overflow.

By understanding how one weakness can chain to another weakness and result in another type of weakness, assessment results that show the presence of one of the weaknesses in a chain can now be viewed in light of the possibility that the one weakness discovered could be indicating the presence of the entire chain.

A report of Named Chains is provided here.

Is there a key to the small icons used on the definition and view pages?

A key to the image icons is included below:

	View – A subset of CWE entries that provides a way of examining CWE content. The two main View Structures are Slices (flat lists) and Graphs (containing relationships between entries).
	Category – A CWE entry that contains a set of other entries that share a common characteristic.
	Pillar Weakness – Highest-level weakness that cannot be made any more abstract.
	Class Weakness – A weakness that is described in a very abstract fashion, typically independent of any specific language or technology. It is more general than a Base weakness.
	Base Weakness – A weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. It is more general than a Variant weakness, but more specific than a Class weakness.
	Variant Weakness - A weakness that is described at a very low level of detail, typically limited to a specific language or technology. It is more specific than a Base weakness.
	Compound Element Composite – An entry that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk.

Refer to the CWE Glossary and Schema Documentation for additional definitions of CWE terminology.

What is vulnerability RCM, and why is it important?

“Root Cause Mapping (RCM)” is the identification of the underlying cause(s) of a vulnerability. This is best done by correlating CVE Records and/or bug or vulnerability tickets with CWE entries.

Accurate root cause mapping is valuable because it directly illuminates where investments, policy, and practices can address the root causes responsible for vulnerabilities so that they can be eliminated. This applies to both industry and government decision makers. Additionally, it enables:

• Driving the removal of classes of vulnerabilities: Root cause mapping encourages a valuable feedback loop into a vendor’s SDLC or architecture design planning
• Saving money: the more weaknesses avoided in your product development, the less vulnerabilities to manage after deployment
• Trend analysis (e.g., how big of a problem is memory safety compared to other problems like injection)
• Further insight to potential “exploitability” based on root cause (e.g., command injection vulnerabilities tend to see increased adversary attention, be targeted by certain actors)
• Organizations demonstrating transparency to customers how they are targeting and tackling problems in their products

Learn more here.

Is how-to guidance available for RCM?

See “CVE -> CWE Root Cause Mapping Guidance.”

How can I submit content for the CWE List?

See Content Submissions.

Is there guidance available for submitting content?

Yes, see Guidelines for Content Submissions.

What is the CWE Content Development Repository (CDR)?

The “CWE Content Development Repository” is a public GitHub repository aimed at enhancing transparency and fostering collaborative input from third parties in the CWE content development process. All CWE content submissions must adhere to the CWE Terms of Use. Learn more about the CDR here.

What is the CWE Top 25 List?

The CWE “Top 25 Most Dangerous Software Weaknesses (CWE Top 25)” highlights the most severe and prevalent weaknesses behind an annual dataset of CVE Records. Uncovering the root causes of these vulnerabilities serves as a powerful guide for investments, policies, and practices to prevent these vulnerabilities from occurring in the first place. These weaknesses lead to serious vulnerabilities in software, and an attacker can often exploit them to take control of an affected system, steal data, or prevent applications from working.

The current release of the CWE Top 25 uses real-world vulnerability data, combining frequency and an average Common Vulnerability Scoring System (CVSS) score to determine a rank order. For more information, visit the CWE Top 25 page.

What should I do to address these errors?

The CWE Top 25 list is a tool for education and awareness that can help the community as a whole reduce the perpetuation of weaknesses in software code that could lead to dangerous vulnerabilities.

• Software Developers – Use the Top 25 to help prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped
• Software Users – Use the Top 25 to help achieve a better awareness of your organization’s current risk posture, and to ask your vendors for more secure software
• Software Security Researchers – Use the Top 25 to focus on a narrow but important subset of all known security weaknesses
• Software Managers and CIOs – Use the Top 25 list as a measuring stick of progress in your efforts to secure your organization’s software and thus improve your security posture

How is this different from the OWASP Top Ten?

The OWASP Top Ten covers more general concepts and is focused on applications, primarily web applications. It is published approximately once every three years, while the CWE Top 25 is published annually. Also, one goal of the Top 25 was to be at a level that is directly actionable to programmers, so it contains more detailed issues than the categories being used in the Top Ten. There is some overlap however, since web applications are so prevalent, and some issues in the Top Ten have general applications to all classes of software. Lastly, OWASP uses CWE information by mapping its categories to specific CWE IDs.

How are the weaknesses prioritized on the CWE Top 25?

See “Methodology” on the CWE Top 25 page.

What is the CWE Top 25 “On the Cusp” list?

The “On the Cusp” Weaknesses List is an annual list of 15 additional weaknesses that were “on the cusp” of being included in the CWE Top 25.

What is the CWE Top 25 “Top 10 KEV” list?

The CWE Top 10 KEV Weaknesses list is an annual list ranking actively exploited weaknesses by the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) Catalog.

What is the CWE Top HW List?

The “CWE Most Important Hardware Weaknesses (MIHW)” combines comprehensive weakness data with expert opinion from across the hardware security community, equipping organizations with actionable insights to tackle today’s most critical hardware risks. The MIHW aims to drive awareness of critical hardware weaknesses and provide the cybersecurity community with practical guidance to prevent security issues at the source. By combining advanced data analysis with expert consensus, the list helps organizations prioritize mitigations, strengthen design practices, and make informed decisions throughout the hardware lifecycle.

What are the stakeholder use cases for the CWE Top HW List?

See “Use Cases” on the MIHW page.

How are the weaknesses prioritized on the CWE Top HW List?

See “Methodology” on the MIHW page.