The CWE Schema is maintained by The MITRE Corporation and developed in partnership with the public CWE Community. For more information, including how to get involved in the project and how to submit change requests, please visit the CWE website at https://cwe.mitre.org. Core Definition 8.0 October 28, 2026 Copyright (c) 2006-2026, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CWE License located at https://cwe.mitre.org/about/termsofuse.html. See the CWE License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CWE Schema, this license header must be included. The Weakness_Catalog root element is used to describe a collection of security issues known as weaknesses (e.g., flaws, faults, bugs). Each catalog can be organized by optional Views and Categories. The catalog also contains a list of all External_References that may be shared throughout the individual weaknesses. The required Name and Version attributes are used to uniquely identify the catalog. The required Date attribute identifies the date when this catalog was created or last updated. When present, this element contains a list of one or more Weakness elements. When present, this element contains a list of one or more Category elements. When present, this element contains a list of one or more Grouping elements. A "Grouping" is a collection of weaknesses based on some common characteristic or attribute, but they do not necessrily share the same ancestor weakness. It is the same as a "Category" in schema version 7.x and earlier. The name was changed in Schema 8.0 (CWE 5.0) as an attempt to reduce the frequent community confusion between "categories" and "classes". When present, this element contains a list of one or more View elements. When present, this element contains a list of one or more External_Reference elements that identify reference(s) associated with one or more Weaknesses, Categories, and/or Views. A weakness is a mistake or condition that, if left unaddressed, could under the proper conditions contribute to a cyber-enabled capability being vulnerable to attack, allowing an adversary to make items function in unintended ways. This complexType is used to describe a specific type of weakness and provide a variety of information related to it. The required Description should be short and limited to the key points that define this weakness. The optional Extended_Description element provides a place for additional details important to this weakness, but that are not necessary to convey the fundamental concept behind the weakness. A number of other optional elements are available, each of which is described in more detail within the corresponding complexType that it references. The required ID attribute provides a unique identifier for the entry. It is considered static for the lifetime of the entry. If this entry becomes deprecated, the identifier will not be reused. The required Name attribute is a string that identifies the entry. The name should focus on the weakness being described and should avoid mentioning the attack that exploits the weakness or the consequences of exploiting the weakness. All words in the entry name should be capitalized except for articles and prepositions, unless they begin or end the name. Subsequent words in a hyphenated chain are also not capitalized. The required Abstraction attribute defines the abstraction level for this weakness. The required Structure attribute defines the structural nature of the weakness. The required Status attribute defines the maturity of the information for this weakness. A short description of the weakness, typically one or two sentences. The Description should be short and limited to the key points that define this weakness. Provides a mechanism for users to obtain more technical details or clarifications that provide important nuance to understanding the weakness. Used to identify the dimensions around which this entry is based, such as behavior type, resource property, etc. History of changes to this entry. For more details, see ContentHistoryType. A category is a collection of weaknesses based on some common characteristic or attribute. The shared attribute may be any number of things including, but not limited to, environment (J2EE, .NET), functional area (authentication, cryptography) and the relevant resource (credentials management, certificate issues). A Category is used primarily as an organizational mechanism for CWE and should not be mapped to by external sources. The required Summary element contains the key points that define the category and helps the user understand what the category is attempting to be. The optional Relationships element is used to define relationships (Member_Of and Has_Member) with other weaknesses, categories, and views. The optional Taxonomy_Mappings element is used to relate this category to similar categories in taxonomies outside of CWE. The optional References element is used to provide further reading and insight into this category. This element should be used when the category is based on external sources or projects. The optional Notes element is used to provide additional comments or clarifications that cannot be captured using the other elements of the category. The optional Content_History element is used to keep track of the original author of the category and any subsequent modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, or in merging overlapping contributions. The required ID attribute provides a unique identifier for the category. It is meant to be static for the lifetime of the category. If the category becomes deprecated, the ID should not be reused, and a placeholder for the deprecated category should be left in the catalog. The required Name attribute provides a descriptive title used to give the reader an idea of what characteristics this category represents. All words in the name should be capitalized except for articles and prepositions unless they begin or end the name. The required Status attribute defines the maturity of the information for this category. Please refer to the StatusEnumeration simple type for a list of valid values and their meanings. History of changes to this entry. For more details, see ContentHistoryType. A "Grouping" in CWE schema 8.0 (and CWE 5.0) is the same as a "Category" in all previous versions. The name was changed as a attempt to reduce the frequent community confusion between "categories" and "classes". A grouping is a collection of weaknesses based on some common characteristic or attribute. The shared attribute may be any number of things including, but not limited to, environment (J2EE, .NET), functional area (authentication, cryptography) and the relevant resource (credentials management, certificate issues). A Grouping is used primarily as an organizational mechanism for CWE and should not be mapped to by external sources. The required Summary element contains the key points that define the grouping and helps the user understand what the grouping is attempting to be. The optional Relationships element is used to define relationships (Member_Of and Has_Member) with other weaknesses, groupings, and views. The optional Taxonomy_Mappings element is used to relate this grouping to similar groupings in taxonomies outside of CWE. The optional References element is used to provide further reading and insight into this grouping. This element should be used when the grouping is based on external sources or projects. The optional Notes element is used to provide additional comments or clarifications that cannot be captured using the other elements of the grouping. The optional Content_History element is used to keep track of the original author of the grouping and any subsequent modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, or in merging overlapping contributions. The required ID attribute provides a unique identifier for the grouping. It is meant to be static for the lifetime of the grouping. If the grouping becomes deprecated, the ID should not be reused, and a placeholder for the deprecated grouping should be left in the catalog. The required Name attribute provides a descriptive title used to give the reader an idea of what characteristics this grouping represents. All words in the name should be capitalized except for articles and prepositions unless they begin or end the name. The required Status attribute defines the maturity of the information for this grouping. Please refer to the StatusEnumeration simple type for a list of valid values and their meanings. History of changes to this entry. For more details, see ContentHistoryType. A view represents a perspective with which one might look at the weaknesses in the catalog. There are three different types of views as defined by the type attribute: graphs, explicit slices, and implicit slices. The members of a view are either defined externally through the members element (in the case of a graph or an explicit slice) or by the optional filter element (in the case of an implicit slice). The required Objective element describes the perspective from which the view has been constructed. The optional Audience element provides a reference to the target stakeholders or groups for whom the view is most relevant. The optional Members element is used to define Member_Of relationships with categories. The optional Filter element is only used for implicit slices (see the Type attribute) and holds an XSL query for identifying which entries are members of the view. The optional References element is used to provide further reading and insight into this view. This element should be used when the view is based on external sources or projects. The optional Notes element is used to provide any additional comments that cannot be captured using the other elements of the view. The optional Content_History element is used to keep track of the original author of the view and any subsequent modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, or in merging overlapping contributions. The required ID attribute provides a unique identifier for the view. It is meant to be static for the lifetime of the view. If the view becomes deprecated, the ID should not be reused, and a placeholder for the deprecated view should be left in the catalog. The required Name attribute provides a descriptive title used to give the reader an idea of what perspective this view represents. All words in the name should be capitalized except for articles and prepositions, unless they begin or end the name. The required Type attribute describes how this view is being constructed. Please refer to the ViewTypeEnumeration simple type for a list of valid values and their meanings. The required Status attribute defines the maturity of the information for this view. Please refer to the StatusEnumeration simple type for a list of valid values and their meanings. History of changes to this entry. For more details, see ContentHistoryType. The ExternalReferenceType complex type defines a collection of elements that provide a pointer to where more information and deeper insight can be obtained. Examples would be a research paper or an excerpt from a publication. Not all of the elements need to be used, since some are designed for web references and others are designed for book references. The Author and Title elements should be filled out for all references if possible; Author is optional, but Title is required. The optional Edition element identifies the edition of the material being referenced in the event that multiple editions of the material exist. If the reference is part of a magazine or journal, the Publication element should be used to identify the name. The optional Publication_Year, Publication_Month, Publication_Day, and Publisher elements should be used to more specifically identify the book or publication via its date and publisher. The year must follow the YYYY format while the month must follow the --MM format and the day must follow the ---DD format. The URL and URL_Date elements are used to capture a URL for the material being referenced, if one exists, and the date when the URL was validated to exist. The required Reference_ID attribute exists to provide a globally unique identifier for the reference (e.g., REF-1). The ID is used by other entities to link to this external reference. The AffectedResourcesType complex type is used to identify system resources that can be affected by an exploit of this weakness. If multiple resources could be affected, then each should be defined by its own Affected_Resource element. The AlternateTermsType complex type indicates one or more other names used to describe this weakness. The required Term element contains the actual alternate term. The required Description element provides context for each alternate term by which this weakness may be known. The ApplicablePlatformsType complex type specifies the languages, operating systems, architectures, and technologies in which a given weakness could appear. A technology represents a generally accepted feature of a system and often refers to a high-level functional component within a system. The required Prevalence attribute identifies the regularity with which the weakness is applicable to that platform. When providing an operating system name, an optional Common Platform Enumeration (CPE) identifier can be used to identify a specific OS. The AudienceType complex type provides a reference to the target stakeholders or groups for a view. For each stakeholder, the required Type element specifies the type of members that might be interested in the view. The required Description element provides some text describing what properties of the view this particular stakeholder might find useful. The BackgroundDetailsType complex type contains one or more Background_Detail elements, each of which contains information that is relevant but not related to the nature of the weakness itself. The CommonConsequencesType complex type is used to specify individual consequences associated with a weakness. The required Scope element identifies the security property that is violated. The optional Impact element describes the technical impact that arises if an adversary succeeds in exploiting this weakness. The optional Likelihood element identifies how likely the specific consequence is expected to be seen relative to the other consequences. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact. The optional Note element provides additional commentary about a consequence. The optional Consequence_ID attribute is used by the internal CWE team to uniquely identify examples that are repeated across any number of individual weaknesses. To help make sure that the details of these common examples stay synchronized, the Consequence_ID is used to quickly identify those examples across CWE that should be identical. The identifier is a string and should match the following format: CC-1. The ContentHistoryType complex type provides elements to track the original author of an entry, along with any subsequent modifications or contributions to the content. Identifies the individual submitter of this entry and/or their organization, the date on which the submission was made, the CWE version and release date in which the new CWE entry was added, and any optional comments related to an entry. The individual(s) or group(s) who originally submitted details for this entry. The organization to which the original submitter belongs. The organization to which the original submitter belongs. The original date on which the submission was made. The first CWE version to which this submission was added. The release date of the first CWE version to which this submission was added. Any additional comments or notes related to the original submission. Identifies a modifier's name, organization, the date on which the Modification was made or suggested, the CWE version and release date in which the modification first appeared, and any related comments. A new Modification element should exist for each change made to the content. Modifications that change the meaning of the entry, or how it might be interpreted, should be marked with an importance of critical to bring it to the attention of anyone previously dependent on the weakness. Identifies a contributor's name, organization, the date, the CWE version and release date in which the contribution first appeared, and any related comments. This element has a single Type attribute, which indicates whether the contribution was part of general feedback given or actual content that was donated. Identifies one or more previous names that was used for the entry in earlier CWE versions. This should be filled out whenever a substantive name change occurs. The required Date attribute lists the date on which this name was no longer used, typically the date of the first CWE release that changed the previous name. A Previous_Entry_Name element should align with a corresponding Modification element. The DemonstrativeExamplesType complex type contains one or more Demonstrative_Example elements, each of which contains an example illustrating how a weakness may look in actual code. The optional Title_Text element provides a title for the example. The Intro_Text element describes the context and setting in which this code should be viewed, summarizing what the code is attempting to do. The Body_Text and Example_Code elements are a mixture of code and explanatory text about the example. The References element provides additional information. The optional Demonstrative_Example_ID attribute is used by the internal CWE team to uniquely identify examples that are repeated across any number of individual weaknesses. To help make sure that the details of these common examples stay synchronized, the Demonstrative_Example_ID is used to quickly identify those examples across CWE that should be identical. The identifier is a string and should match the following format: DX-1. The DetectionMethodsType complex type is used to identify methods that may be employed to detect this weakness, including their strengths and limitations. The required Method element identifies the particular detection method being described. The required Description element is intended to provide some context of how this method can be applied to a specific weakness. The optional Effectiveness element says how effective the detection method may be in detecting the associated weakness. This assumes the use of best-of-breed tools, analysts, and methods. There is limited consideration for financial costs, labor, or time. The optional Effectiveness_Notes element provides additional discussion of the strengths and shortcomings of this detection method. The optional Detection_Method_ID attribute is used by the internal CWE team to uniquely identify methods that are repeated across any number of individual weaknesses. To help make sure that the details of these common methods stay synchronized, the Detection_Method_ID is used to quickly identify those Detection_Method elements across CWE that should be identical. The identifier is a string and should match the following format: DM-1. The ExploitationFactorsType complex type points out conditions or factors that could increase the likelihood of exploit for this weakness. The FunctionalAreasType complex type contains one or more functional_area elements, each of which identifies the functional area in which the weakness is most likely to occur. For example, CWE-23: Relative Path Traversal may occur in functional areas of software related to file processing. Each applicable functional area should have a new Functional_Area element, and standard title capitalization should be applied to each area. The MappingNotesType complex type provides guidance for when (and whether) to map an issue to this CWE entry or to suggest alternatives. The Usage element describes whether the CWE should be used for mapping vulnerabilities to their underlying weaknesses as part of root cause analysis. The Rationale element provides context for the Usage. The Comments element provides further clarification to the reader. The Reasons element uses a limited vocabulary to summarize the Usage. The Suggestions element includes suggestions for additional CWEs that might be more appropriate for the mapping task. The MemberType complex type may be used to establish a Has_Member or Member_Of type relationship within the designated View_ID. This type will establish a relationship between the container Category/View ID and the target CWE_ID. Specifies the dimensions that are different between this CWE entry and the related CWE entry. The ModeOfIntroductionType complex type is used to provide information about how and when a given weakness may be introduced. If there are multiple possible introduction points, then a separate Introduction element should be included for each. The required Phase element identifies the point in the product life cycle at which the weakness may be introduced. The optional Note element identifies the typical scenarios under which the weakness may be introduced during the given phase. The NotesType complex type contains one or more Note elements, each of which is used to provide any additional comments about an entry that cannot be captured using other elements. The ObservedExampleType complex type specifies references to a specific observed instance of a weakness in real-world products. Typically this will be a CVE reference. Each Observed_Example element represents a single example. The required Reference element should contain the identifier for the example being cited. For example, if a CVE is being cited, it should be of the standard CVE identifier format, such as CVE-2005-1951 or CVE-1999-0046. The required Description element should contain a brief description of the weakness being cited, without including irrelevant details such as the product name or attack vectors. The description should present an unambiguous correlation between the example being described and the weakness(es) that it is meant to exemplify. It should also be short and easy to understand. The Link element should provide a valid URL where more information regarding this example can be obtained. The PotentialMitigationsType complex type is used to describe potential mitigations associated with a weakness. It contains one or more Mitigation elements, which each represent individual mitigations for the weakness. The Phase element indicates the development life cycle phase during which this particular mitigation may be applied. The Strategy element describes a general strategy for protecting a system to which this mitigation contributes. The Effectiveness element summarizes how effective the mitigation may be in preventing the weakness. The Description element contains a description of this individual mitigation including any strengths and shortcomings of this mitigation for the weakness. The optional Mitigation_ID attribute is used by the internal CWE team to uniquely identify mitigations that are repeated across any number of individual weaknesses. To help make sure that the details of these common mitigations stay synchronized, the Mitigation_ID is used to quickly identify those mitigation elements across CWE that should be identical. The identifier is a string and should match the following format: MIT-1. The ReasonsType complex type is used to identify the different reasons why a CWE should not be considered. The CustomPhaseType complex type is used to identify custom lifecycles for specific domains. The DimensionElementType complex type is used to identify dimensions of CWE entries and/or relationships. The DimensionsType complex type is used to identify dimensions of CWE entries and/or relationships. The ReferencesType complex type contains one or more reference elements, each of which is used to link to an external reference defined within the catalog. The required External_Reference_ID attribute represents the external reference entry being linked to (e.g., REF-1). Text or quotes within the same CWE entity can cite this External_Reference_ID similar to how a footnote is used, and should use the format [REF-1]. The optional Section attribute holds any section title or page number that is specific to this use of the reference. The RelatedAttackPatternsType complex type contains references to attack patterns associated with this weakness. The association implies those attack patterns may be applicable if an instance of this weakness exists. Each related attack pattern is identified by a CAPEC identifier. The RelatedWeaknessesType complex type is used to refer to other weaknesses that differ only in their level of abstraction. It contains one or more Related_Weakness elements. Used to link to the CWE identifier of another Weakness that is related. Used to specify the dimensions that are different between this CWE entry and the related CWE entry. The nature (type) of relationship being recorded. The ID of the CWE entry that is related. The ID of the View in which this relationship exists. The unique ID of a named chain that a CanFollow or CanPrecede relationship pertains to. Used to record the primary relationship to use when there might be more than one related CWE entry for the given View ID, typically to indicate the primary ChildOf relationship for this weakness for a given View_ID. For each unique triple of <Nature, CWE_ID, View_ID>, there should be only one relationship that is given a "Primary" ordinal. The RelationshipsType complex type provides elements to show the associated relationships with a given view or category. The Member_Of element is used to denote the individual categories that are included as part of the target view. The Has_Member element is used to define the weaknesses or other categories that are grouped together by a category. In both cases, the required MemberType's CWE_ID attribute specifies the unique CWE ID that is the target entry of the relationship, while the View_ID specifies which view the given relationship is relevant to. The SuggestionsType complex type is used to suggest other CWE entries that might be more appropriate to use for mapping. The TaxonomyMappingsType complex type is used to provide a mapping from an entry (Weakness or Category) in CWE to an equivalent entry in a different taxonomy. The Entry_ID element identifies the ID of the entry which is being mapped. The Entry_Name element identifies the name of the entry which is being mapped. The Mapping_Fit element identifies how close the CWE is to the entry in the taxonomy. The required Taxonomy_Name attribute identifies the taxonomy to which the mapping is being made. The WeaknessOrdinalitiesType complex type indicates potential ordering relationships with other weaknesses. The required Ordinality element identifies whether the weakness has a primary, resultant, or indirect relationship. The optional Description contains the context in which the relationship exists. It is important to note that it is possible for the same entry to be primary in some instances and resultant in others. The AbstractionEnumeration simple type defines the different abstraction levels that apply to a weakness. A "Pillar" is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. A "Class" is a weakness also described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. A "Base" is a more specific type of weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. A "Variant" is a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. A "Compound" weakness is a meaningful aggregation of several weaknesses, currently known as either a Chain or Composite. The AlternateTermRoleEnumeration simple type defines the roles that the specified alternate terms might play in understanding weaknesses or vulnerabilities. The ArchitectureClassEnumeration simple type contains a list of values corresponding to known classes of architectures. Used to indicate that the entry is not limited to a small set of architectures, i.e., it can appear in many different architectures. The ArchitectureNameEnumeration simple type contains a list of values corresponding to known architectures. The DetectionMethodEnumeration simple type defines the different methods used to detect a weakness. The DetectionEffectivenessEnumeration simple type defines the different levels of effectiveness that a detection method may have in detecting an associated weakness. The value "High" is used to describe a method that succeeds frequently and does not result in many false reports. The value "Moderate" is used to describe a method that is applicable to multiple circumstances, but it may not have complete coverage of the weakness, or it may result in a number of incorrect reports. The "SOAR Partial" value means that according to SOAR this method can be cost-effective for partial coverage of the objective. The value "Opportunistic" is used to describe a method that does not directly target the weakness but may still succeed by chance, rather than in a reliable manner. The value "Limited" is used to describe a method that may be useful in limited circumstances, only applicable to a subset of potential instances of a given weakness type, requires training/customization, or gives limited visibility. Even in its limited capacity, this may be part of a good defense in depth strategy. The value "None" is used to describe a method that is highly unlikely to work. However, it may be included in an entry to emphasize common, yet incorrect, methods that developers might introduce. Used to indicate that according to the IATAC State Of the Art Report (SOAR), the detection method is partially effective. The EffectivenessEnumeration simple type defines the different values related to how effective a mitigation may be in preventing the weakness. A value of "High" means the mitigation is frequently successful in eliminating the weakness entirely. A value of "Moderate" means the mitigation will prevent the weakness in multiple forms, but it does not have complete coverage of the weakness. A value of "Limited" means the mitigation may be useful in limited circumstances, or it is only applicable to a subset of potential errors of this weakness type. A value of "Incidental" means the mitigation is generally not effective and will only provide protection by chance, rather than in a reliable manner. A value of "Defense in Depth" means the mitigation may not necessarily prevent the weakness, but it may help to minimize the potential impact of an attacker exploiting the weakness. A value of "Discouraged Common Practice" is used to indicate mitigations that are commonly attempted but known to be ineffective or highly risky. The FunctionalAreaEnumeration simple type defines the different functional areas in which the weakness may appear. Used to indicate that the entry is not limited to a small set of functional areas, i.e., it can appear in many different functional areas. The ImportanceEnumeration simple type lists different values for importance. The LanguageClassEnumeration simple type contains a list of values corresponding to different classes of source code languages. The same language could belong to multiple language classes, such as 'Object-Oriented' and 'Memory-Unsafe'. Used to indicate that the entry is not limited to a small set of language classes, i.e., it can appear in many different language classes. The LanguageNameEnumeration simple type contains a list of values corresponding to different source code languages or data formats. The LikelihoodEnumeration simple type contains a list of values corresponding to different likelihoods. The value "Unknown" should be used when the actual likelihood of something occurring is not known. The MitigationStrategyEnumeration simple type lists general strategies for protecting a system to which a mitigation contributes. The NoteTypeEnumeration simple type defines the different types of notes that can be associated with a weakness. An "Applicable Platform" note provides additional information about the list of applicable platforms for a given weakness. A "Maintenance" note contains significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. A "Relationship" note provides clarifying details regarding the relationships between entities. A "Research Gap" note identifies potential opportunities for the vulnerability research community to conduct further exploration of issues related to this weakness. It is intended to highlight parts of CWE that have not received sufficient attention from researchers. A "Terminology" note contains a discussion of terminology issues related to this weakness, or clarifications when there is no established terminology, or if there are multiple uses of the same key term. It is different from the Alternate_Terms element, which is focused on specific terms that are commonly used. A "Theoretical" note describes the weakness using vulnerability theory concepts. It should be provided as needed, especially in cases where the application of vulnerability theory is not necessarily obvious for the weakness. An "Other" note provides potentially useful information that can not be categorized as another type of note. The ObexRationaleEnumeration enumeration provides hints as to why an Observed Example (typically a CVE Record) was included in a CWE entry. The Observed Example is one of the earliest examples that were recognized to be related to this weakness. The recognition could occur much later than the original publication. The Observed Example is an influential and/or newsworthy example of this weakness. The OrdinalEnumeration simple type contains a list of values used to determine if a relationship is the primary relationship for a given weakness entry within a given view. Currently, this attribute can only have the value "Primary". The OrdinalityEnumeration simple type contains a list of values used to indicate potential ordering relationships with other weaknesses. A primary relationship means the weakness exists independent of other weaknesses, while a resultant relationship is when a weakness exists only in the presence of some other weaknesses. An indirect relationship means the weakness does not directly lead to security-relevant weaknesses but is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect. The OperatingSystemClassEnumeration simple type contains a list of values corresponding to different classes of operating systems. Used to indicate that the entry is not limited to a small set of operating system classes, i.e., it can appear in many different operating system classes. The OperatingSystemNameEnumeration simple type contains a list of values corresponding to different operating systems. The PhaseEnumeration simple type lists different phases in the product life cycle. The AIPhaseEnumeration simple type lists different phases in the life cycle for AI-related products. The HardwarePhaseEnumeration simple type lists different phases in the life cycle for hardware-related products. The list was adapted from the SAE G-32 working group's "Proposed Microelectronics Hardware Lifecycle Phases and Definitions." This enumeration was then further developed and refined by members of the CWE Hardware Special Interest Group (HW-SIG) from August to October, 2026. Requirements, constraints, assumptions, security objectives, assurance objectives, updateability expectations, environmental assumptions, debug expectations, and trust expectations are defined and flowed down. Applies to both IP/SoC/Chip/SiP and board/device contexts. High-level structure, trust boundaries, security domains, major components or blocks, interfaces, debug strategy, lifecycle assumptions, HW/SW responsibilities, and major security mechanisms are defined. Applies to both IP/SoC/Chip/SiP and board/device contexts. Detailed behavior is defined. This includes pipelines, caches, speculation, buses, fabrics, bridges, debug/test blocks, processors, memories. In addition IP (including security IP) and component choices whose properties affect security. Applies primarily to IP/SoC/Chip/SiP. Not generally a board/device phase unless the CWE entry depends on selected component behavior. The design is realized through HDL, logic, state machines, registers, signals, modules, schematic capture, PCB layout, routing, connectors, physical interfaces, debug headers, test pads, buses, fabrics, tool constraints, control/data paths, security mechanisms, and pre-silicon IP/SoC integration. Applies to both IP/SoC/Chip/SiP and board/device contexts. The design is reviewed, simulated, formally analyzed, inspected, or otherwise verified before fabrication, assembly, or manufacturing release. Applies to both IP/SoC/Chip/SiP and board/device contexts. Generally used only for Detection Methods. Hardware is fabricated, packaged, assembled, programmed, tested, labeled, handled, or transferred through production flows, supplier handling, provenance, traceability, and production supply-chain handling (any of which may be outsourced). Applies to both IP/SoC/Chip/SiP and board/device contexts. Realized hardware is evaluated after manufacturing through bring-up, post-silicon validation, board/device validation, electrical/physical/security testing, and conformance checks. Applies to both IP/SoC/Chip/SiP and board/device contexts. Generally used only for Detection Methods. Device-specific state is established, including fuses, lifecycle states, debug lock state, keys, credentials, identifiers, firmware, settings, feature enablement, provisioning, and personalization data. Applies to both IP/SoC/Chip/SiP and board/device contexts. Realized chips, components, boards, devices, firmware, software, subsystems, or systems are integrated into a larger product, platform, or operational environment. Applies primarily to board/device/system contexts; applies to IP/SoC/Chip/SiP at application level only after the realized silicon is integrated into a larger product or system. Does not include pre-silicon IP/SoC integration. Hardware is operated, monitored, updated, serviced, repaired, replaced, reconfigured, mitigated, or otherwise sustained after deployment, including firmware/software mitigations that affect hardware behavior. Applies to both IP/SoC/Chip/SiP and board/device contexts. Hardware is prepared for renewed use, transfer, redeployment, refurbishment, resale, repair-return, or repurposing, including reset, requalification, residual-state review, provenance, and counterfeit-related concerns. Applies to both, but is more commonly board/device/system-facing. Hardware is permanently removed from service, retired, destroyed, recycled, discarded, or otherwise disposed of, including sanitization or destruction of stored data, firmware, credentials, keys, identifiers, personalization data, and lifecycle-state information. Applies to both, but is more commonly board/device/system-facing. The PrevalenceEnumeration simple type defines the different regularities that guide the applicability of platforms. The ReasonEnumeration simple type holds all the different types of reasons why a CWE might not be considered for mapping. The ReferenceAccessRestrictionsEnumeration simple type defines the different types of access restrictions that might apply to a reference. While CWE attempts to provide freely available references without access restrictions, sometimes it must cite restricted references. (Where possible, the reference will include an "Alt_URL" that provides an alternative with fewer restrictions.) The reference has no access restrictions, i.e., is freely available to anybody on the internet The reference is only available to proprietary consumers, e.g., paid subscribers such as individuals or academic/corporate institutions who pay for site-wide subscriptions, possibly at a cost that prevents some CWE users from being able to access the reference. The reference is only available (without financial expense) to users who must perform a minimal registration to access the reference, e.g., by providing an e-mail address, being logged into a widely-used service, signing up for marketing purposes, etc. The reference has been removed, e.g., taken off the web with HTTP 404 "Not Found", possibly without other copies of the reference available on other sites The ReferenceMediaTypeEnumeration simple type defines the different media type that a reference might use. The media type could make the reference easier or more difficult to access in different contexts. A given URL might point to multiple media types. Note: while CWE attempts to provide references with simple media types that could be used across many contexts and platforms, sometimes it must cite other media types. The reference is in text format, or in easily-parsed formats such as static HTML or Markdown The reference is in a proprietary text format that is frequently used, e.g., PDF, PowerPoint, Word docx, etc. The reference is in video format, possibly including audio, such as a conference presentation or tutorial. The reference is in audio format, without accompanying video. The reference is in some other format, which might indicate difficulty for some users to access. The ReferenceRationaleEnumeration enumeration provides hints as to why a Reference was cited in a CWE entry. The reference is being used in an example (whether an Observed_Example or Demonstrative_Example) and provides more details for the example; possibly the original source of the examples. The reference is an early publication - possibly the first - in which the weakness (or its exploitation) is described and explained in some depth. The reference is influential and/or newsworthy for describing this weakness (or its exploitation) in some depth. The reference is a manual, specification, or "man pages" that is a technical reference for related behavior with a technical audience, but the reference is not focused on the given weakness. This is typically used for background explanation. The reference proposes ways to mitigate or eliminate weaknesses on a systemic level. The reference points to formalized, commonly-used mechanisms related to rules or guides for secure development. The RelatedNatureEnumeration simple type defines the different values that can be used to define the nature of a related weakness. A ChildOf nature denotes a related weakness at a higher level of abstraction. A ParentOf nature denotes a related weakness at a lower level of abstraction. Used for Named Chains only. Denotes the start of a named chain that has a chaining structure. Denotes which weakness can appear before this one in a chaining relationship. Denotes which weakness can appear after this one in a chaining relationship. Used for relationships with Composites only. Indicates a composite weakness that requires the presence of this weakness. For Composites only. Indicates a weakness that is part of this composite weakness. The CanAlsoBe relationship denotes a weakness that, in the proper environment and context, can also be perceived as the target weakness, but is not a parent or child. Note that the CanAlsoBe relationship is not necessarily reciprocal. The PeerOf relationship is used to show some similarity with the target weakness that does not fit any of the other type of relationships. An Overlaps nature denotes a related weakness that has some overlap with the current weakness. Ideally, CWE should not have any overlapping entries, but this is not always the case. The ResourceEnumeration simple type defines different resources of a system. The ScopeEnumeration simple type defines the different areas of security that can be affected by exploiting a weakness. The StatusEnumeration simple type defines the different status values that an entity (view, category, weakness) can have. A value of Deprecated refers to an entity that has been removed from CWE, likely because it was a duplicate or was created in error. A value of Obsolete is used when an entity is still valid but no longer is relevant, likely because it has been superseded by a more recent entity. A value of Incomplete means that the entity does not have all important elements filled, and there is no guarantee of quality. A value of Draft refers to an entity that has all important elements filled, and critical elements such as Name and Description are reasonably well-written; the entity may still have important problems or gaps. A value of Usable refers to an entity that has received close, extensive review, with critical elements verified. A value of Stable indicates that all important elements have been verified, and the entry is unlikely to change significantly in the future. Note that the quality requirements for Draft and Usable status are very resource-intensive to accomplish, while some Incomplete and Draft entries are actively used by the general public; so, this status enumeration might change in the future. The StakeholderEnumeration simple type defines the different types of users within the CWE community. The StructureEnumeration simple type lists the different structural natures of a weakness. A Simple structure represents a single weakness whose exploitation is not dependent on the presence of another weakness. A Composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability, while a Chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. The StructuredCodeNatureEnumeration simple type defines the different values that state what type of code is being shown in an example. The TaxonomyMappingFitEnumeration simple type defines the different values used to describe how close a certain mapping to CWE is. The TaxonomyNameEnumeration simple type lists the different known taxonomies that can be mapped to CWE. The TechnicalImpactEnumeration simple type describes the technical impacts that can arise if an adversary successfully exploits a weakness. It is more difficult for humans or tools to analyze the product's code, documentation, and other artifacts to understand how the product works or is intended to work, which can make it more difficult to find and fix vulnerabilities. The TechnologyClassEnumeration simple type contains a list of values corresponding to different classes of technologies. The value "Not Technology-Specific" is used to indicate that the entry is not limited to a small set of technologies, i.e., it can appear in many different technologies. Represents technology involving a distributed application but for the purposes of CWE does not leverage a web browser. Represents technology that involves data storage and computing power being made available to multiple users via the internet instead of using local systems, without the need for users to perform all system management themselves. Represents technology related to Industrial Control Systems (ICS) and Operational Technology (OT), which are often considered to be distinct from Information Technology (IT) systems. Represents technology related to Service-oriented architecture (SOA). Represents technology that integrates all components of a computer within a single integrated circuit, to include FPGA and ASIC. Represents technology that involves applications or single-page sites that leverage a web browser to support client interactions. Used to indicate that the entry is not limited to a small set of technologies, i.e., it can appear in many different technologies. The TechnologyNameEnumeration simple type contains a list of values corresponding to different technologies. A technology represents a generally accepted feature of a system and often refers to a high-level functional component within a system. Within this context, "IP" stands for "Intellectual Property" and is the term used to distinguish unique blocks within a System on Chip, with each block potentially coming from a different source. Represents technology related to Artificial Intelligence (AI) and Machine Learning (ML) systems. Note: terminology in this space is inconsistently used, but the AI WG agreed on this usage for CWE 4.15. hardware Intellectual Property (IP) dedicated to offload a specific workload to enhance performance: DSP, packet processing, mathematical, compression, etc. hardware Intellectual Property (IP) that controls/senses the electricals for communication which receives/transmits signals conditioned outside of a system's digital domain. hardware Intellectual Property (IP) designed to manipulate audio/video data: coders/decoders, speech recognition, format converters, etc. hardware Intellectual Property (IP) implementing an interconnect among elements in a computing system: I2C, PCIe, DDR, MMC, USB, GPIO, NoC, etc. hardware Intellectual Property (IP) reflecting the passage of time in oscillations or human units: Real Time Clock, Watchdog, Monotonic Counter, etc. hardware Intellectual Property (IP) designed to transmit/receive information: Modulator/Demodulator, GPS, 802.11, Bluetooth, CDMA/DSM, etc. hardware Intellectual Property (IP) circuit hard-wired (e.g., an FSM) to react in a closed-loop control system or other limited context, to control another entity: Arbiter, APIC, USB, Peripheral, Memory, Storage, etc. hardware Intellectual Property (IP) implementing volatile (transient) data storage: DRAM, SRAM, etc. hardware Intellectual Property (IP) implementing a specialized processor acting as a programmable controller. hardware Intellectual Property (IP) that controls and/or monitors the power state of a system: voltage regulators, power controllers, power monitors, etc. hardware Intellectual Property (IP) implementing a general-purpose computing engine: CPU, GPU, RISC, CISC, etc. hardware Intellectual Property (IP), including hardware security modules (HSM), designed to protect assets: cryptography, auth, tamper detection, etc. hardware Intellectual Property (IP) designed to verify functionality and identify root cause of defects: JTAG, BIST, boundary scan, pattern generator, etc. The UsageEnumeration simple type is used for whether this CWE entry is supported for mapping. this CWE ID should not be used to map to real-world vulnerabilities this CWE ID must not be used to map to real-world vulnerabilities this CWE ID may be used to map to real-world vulnerabilities this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review The ViewTypeEnumeration simple type defines the different types of views that can be found within CWE. A graph is a hierarchical representation of weaknesses based on a specific vantage point that a user may take. The hierarchy often starts with a category, followed by a class/base weakness, and ends with a variant weakness. In addition to graphs, a view can be a slice, which is a flat list of entries that does not specify any relationships between those entries. An explicit slice is a subset of weaknesses that are related through some external factor. For example, an explicit slice may be used to represent mappings to external groupings like a Top-N list. An implicit slice is a subset of weaknesses that are related through a specific attribute, as indicated by the Filter element of the View. For example, an implicit slice may refer to all weaknesses in draft status, or all class level weaknesses. The StructuredTextType complex type is used to allow XHTML content embedded within standard string data. Some common elements are: <BR/> to insert a line break, <UL><LI/></UL> to create a bulleted list, <OL><LI/></OL> to create a numbered list, and <DIV style="margin-left:1em"></DIV> to create a new indented section. The StructuredCodeType complex type is used to present source code examples and other structured text that is not a regular paragraph. It allows embedded XHTML content to enable formatting of the code. The required Nature attribute states what type of code the example shows. The optional Language attribute states which source code language is used in the example. This is mostly appropriate when the Nature is "good" or "bad".