All CWE Categories
Categories are sets of weaknesses that share a common characteristic. They help organize and navigate the CWE list.
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that are typically introduced during unexpected environmental conditions. According to the authors of the Seven Pernicious Kingdoms, "This section includes everything that is outside of the source code but is still critical to the security of the product that is being created. Because the issues covered by this kingdom are not directly related to source code, we separated it from the rest of the kingdoms."
Weaknesses in this category are typically introduced during the configuration of the software.
Weaknesses in this category are typically found in functionality that processes data. Data processing is the manipulation of input to retrieve or save information.
Weaknesses in this category are related to the creation and modification of strings.
Weaknesses in this category are caused by improper data type transformation or improper handling of multiple data types.
Weaknesses in this category are related to the creation or neutralization of data using an incorrect format.
Weaknesses in this category are related to improper calculation or conversion of numbers.
Weaknesses in this category are related to improper handling of sensitive information.
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that involve the software using an API in a manner contrary to its intended use. According to the authors of the Seven Pernicious Kingdoms, "An API is a contract between a caller and a callee. The most common forms of API misuse occurs when the caller does not honor its end of this contract. For example, if a program does not call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller misuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated."
Functions that manipulate strings encourage buffer overflows.
Software security is not security software. Here we're concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management.
Weaknesses in this category are related to the management of credentials.
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Weaknesses in this category occur with improper handling, assignment, or management of privileges. A privilege is a property of an agent, such as a user. It lets the agent do things that are not ordinarily allowed. For example, there are privileges which allow an agent to perform maintenance functions such as restart a computer.
Weaknesses in this category are related to improper assignment or handling of permissions.
Weaknesses in this category are related to the design and implementation of data confidentiality and integrity. Frequently these deal with the use of encoding techniques, encryption libraries, and hashing algorithms. The weaknesses in this category could lead to a degradation of the quality data if they are not addressed.
Weaknesses in this category are related to errors in the management of cryptographic keys.
Weaknesses in this category are related to or introduced in the User Interface (UI).
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses related to the improper management of time and state in an environment that supports simultaneous or near-simultaneous computation by multiple systems, processes, or threads. According to the authors of the Seven Pernicious Kingdoms, "Distributed computation is about time and state. That is, in order for more than one component to communicate, state must be shared, and all that takes time. Most programmers anthropomorphize their work. They think about one thread of control carrying out the entire program in the same way they would if they had to do the job themselves. Modern computers, however, switch between tasks very quickly, and in multi-core, multi-CPU, or distributed systems, two events may take place at exactly the same time. Defects rush to fill the gap between the programmer's model of how a program executes and what happens in reality. These defects are related to unexpected interactions between threads, processes, time, and information. These interactions happen through shared state: semaphores, variables, the file system, and, basically, anything that can store information."
Weaknesses in this category are related to improper management of system state.
Weaknesses in this category are related to the improper handling of signals.
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that occur when an application does not properly handle errors that occur during processing. According to the authors of the Seven Pernicious Kingdoms, "Errors and error handling represent a class of API. Errors related to error handling are so common that they deserve a special kingdom of their own. As with 'API Abuse,' there are two ways to introduce an error-related security vulnerability: the most common one is handling errors poorly (or not at all). The second is producing errors that either give out too much information (to possible attackers) or are difficult to handle."
This category includes weaknesses that occur if a function does not generate the correct return/status code, or if the application does not handle all possible return/status codes that could be generated by a function. This type of problem is most often found in conditions that are rarely encountered during the normal operation of the product. Presumably, most bugs related to common conditions are found and eliminated during development and testing. In some cases, the attacker can directly control or influence the environment to trigger the rare conditions.
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that do not directly introduce a weakness or vulnerability, but indicate that the product has not been carefully developed or maintained. According to the authors of the Seven Pernicious Kingdoms, "Poor code quality leads to unpredictable behavior. From a user's perspective that often manifests itself as poor usability. For an adversary it provides an opportunity to stress the system in unexpected ways."
Weaknesses in this category are related to improper management of system resources.
Weaknesses in this category are related to improper handling of locks that are used to control access to resources.
Weaknesses in this category are related to improper handling of communication channels and access paths. These weaknesses include problems in creating, managing, or removing alternate channels and alternate paths. Some of these can overlap virtual file problems and are commonly used in "bypass" attacks, such as those that exploit authentication errors.
Weaknesses in this category are related to improper management of handlers.
Weaknesses in this category are related to unexpected behaviors from code that an application uses.
Weaknesses in this category occur in behaviors that are used for initialization and breakdown.
Weaknesses in this category are related to improper handling of pointers.
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that occur when the product does not sufficiently encapsulate critical data or functionality. According to the authors of the Seven Pernicious Kingdoms, "Encapsulation is about drawing strong boundaries. In a web browser that might mean ensuring that your mobile code cannot be abused by other mobile code. On the server it might mean differentiation between validated data and unvalidated data, between one user's data and another's, or between data users are allowed to see and data that they are not."
Weaknesses in this category are related to concurrent use of shared resources.
Weaknesses in this category are related to incorrectly written expressions within code.
Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2007.
Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2004.
Weaknesses in this category are related to the rules and recommendations in the Preprocessor (PRE) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Integers (INT) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Floating Point (FLP) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Arrays (ARR) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Memory Management (MEM) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Environment (ENV) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Signals (SIG) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Error Handling (ERR) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) chapter of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are related to the rules and recommendations in the POSIX (POS) appendix of the CERT C Secure Coding Standard (2008).
Weaknesses in this category are listed in the "Insecure Interaction Between Components" section of the 2009 CWE/SANS Top 25 Programming Errors.
Weaknesses in this category are listed in the "Risky Resource Management" section of the 2009 CWE/SANS Top 25 Programming Errors.
Weaknesses in this category are listed in the "Porous Defenses" section of the 2009 CWE/SANS Top 25 Programming Errors.
Weaknesses in this category are listed in the "Insecure Interaction Between Components" section of the 2010 CWE/SANS Top 25 Programming Errors.
Weaknesses in this category are listed in the "Risky Resource Management" section of the 2010 CWE/SANS Top 25 Programming Errors.
Weaknesses in this category are listed in the "Porous Defenses" section of the 2010 CWE/SANS Top 25 Programming Errors.
Weaknesses in this category are not part of the general Top 25, but they were part of the original nominee list from which the Top 25 was drawn.
Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2010.
Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2010.
Weaknesses in this category identify some of the underlying problems that commonly allow attackers to manipulate the business logic of an application. Errors in business logic can be devastating to an entire application. They can be difficult to find automatically, since they typically involve legitimate use of the application's functionality. However, many business logic errors can exhibit patterns that are similar to well-understood implementation and design weaknesses.
Weaknesses in this category are related to rules in the Input Validation and Data Sanitization (IDS) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Expressions (EXP) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Numeric Types and Operations (NUM) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Object Orientation (OBJ) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Methods (MET) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Exceptional Behavior (ERR) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Visibility and Atomicity (VNA) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Locking (LCK) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Thread APIs (THI) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Thread Pools (TPS) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Thread-Safety Miscellaneous (TSM) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Input Output (FIO) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Serialization (SER) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Platform Security (SEC) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Runtime Environment (ENV) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are related to rules in the Miscellaneous (MSC) chapter of The CERT Oracle Secure Coding Standard for Java (2011).
Weaknesses in this category are listed in the "Insecure Interaction Between Components" section of the 2011 CWE/SANS Top 25 Most Dangerous Software Errors.
Weaknesses in this category are listed in the "Risky Resource Management" section of the 2011 CWE/SANS Top 25 Most Dangerous Software Errors.
Weaknesses in this category are listed in the "Porous Defenses" section of the 2011 CWE/SANS Top 25 Most Dangerous Software Errors.
Weaknesses in this category are not part of the general Top 25, but they were part of the original nominee list from which the Top 25 was drawn.
Weaknesses in this category are related to rules in the Preprocessor (PRE) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Expressions (EXP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Integers (INT) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Floating Point Arithmetic (FLP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Arrays and the STL (ARR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Characters and Strings (STR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Memory Management (MEM) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Input Output (FIO) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Environment (ENV) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Signals (SIG) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Exceptions and Error Handling (ERR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Object Oriented Programming (OOP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Concurrency (CON) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
Weaknesses in this category are related to rules in the Miscellaneous (MSC) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
This category identifies Software Fault Patterns (SFPs) within the Risky Values cluster (SFP1).
This category identifies Software Fault Patterns (SFPs) within the Unused entities cluster (SFP2).
This category identifies Software Fault Patterns (SFPs) within the API cluster (SFP3).
This category identifies Software Fault Patterns (SFPs) within the Exception Management cluster (SFP4, SFP5, SFP6).
This category identifies Software Fault Patterns (SFPs) within the Memory Access cluster (SFP7, SFP8).
This category identifies Software Fault Patterns (SFPs) within the Memory Management cluster (SFP38).
This category identifies Software Fault Patterns (SFPs) within the Resource Management cluster (SFP37).
This category identifies Software Fault Patterns (SFPs) within the Path Resolution cluster (SFP16, SFP17, SFP18).
This category identifies Software Fault Patterns (SFPs) within the Synchronization cluster (SFP19, SFP20, SFP21, SFP22).
This category identifies Software Fault Patterns (SFPs) within the Information Leak cluster (SFP23).
This category identifies Software Fault Patterns (SFPs) within the Tainted Input cluster (SFP24, SFP25, SFP26, SFP27).
This category identifies Software Fault Patterns (SFPs) within the Entry Points cluster (SFP28).
This category identifies Software Fault Patterns (SFPs) within the Authentication cluster (SFP29, SFP30, SFP31, SFP32, SFP33, SFP34).
This category identifies Software Fault Patterns (SFPs) within the Access Control cluster (SFP35).
This category identifies Software Fault Patterns (SFPs) within the Privilege cluster (SFP36).
This category identifies Software Fault Patterns (SFPs) within the Channel cluster.
This category identifies Software Fault Patterns (SFPs) within the Cryptography cluster.
This category identifies Software Fault Patterns (SFPs) within the Malware cluster.
This category identifies Software Fault Patterns (SFPs) within the Predictability cluster.
This category identifies Software Fault Patterns (SFPs) within the UI cluster.
This category identifies Software Fault Patterns (SFPs) within the Other cluster.
Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2013.
Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2013.
This category identifies Software Fault Patterns (SFPs) within the Access Management cluster.
This category identifies Software Fault Patterns (SFPs) within the Insecure Resource Access cluster (SFP35).
This category identifies Software Fault Patterns (SFPs) within the Insecure Resource Permissions cluster.
This category identifies Software Fault Patterns (SFPs) within the Authentication Bypass cluster.
This category identifies Software Fault Patterns (SFPs) within the Digital Certificate cluster.
This category identifies Software Fault Patterns (SFPs) within the Faulty Endpoint Authentication cluster (SFP29).
This category identifies Software Fault Patterns (SFPs) within the Hardcoded Sensitive Data cluster (SFP33).
This category identifies Software Fault Patterns (SFPs) within the Insecure Authentication Policy cluster.
This category identifies Software Fault Patterns (SFPs) within the Missing Authentication cluster.
This category identifies Software Fault Patterns (SFPs) within the Missing Endpoint Authentication cluster (SFP30).
This category identifies Software Fault Patterns (SFPs) within the Multiple Binds to the Same Port cluster (SFP32).
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Authentication cluster (SFP34).
This category identifies Software Fault Patterns (SFPs) within the Channel Attack cluster.
This category identifies Software Fault Patterns (SFPs) within the Protocol Error cluster.
This category identifies Software Fault Patterns (SFPs) within the Broken Cryptography cluster.
This category identifies Software Fault Patterns (SFPs) within the Weak Cryptography cluster.
This category identifies Software Fault Patterns (SFPs) within the Ambiguous Exception Type cluster (SFP5).
This category identifies Software Fault Patterns (SFPs) within the Incorrect Exception Behavior cluster (SFP6).
This category identifies Software Fault Patterns (SFPs) within the Unchecked Status Condition cluster (SFP4).
This category identifies Software Fault Patterns (SFPs) within the Exposed Data cluster (SFP23).
This category identifies Software Fault Patterns (SFPs) within the Exposure Temporary File cluster.
This category identifies Software Fault Patterns (SFPs) within the Insecure Session Management cluster.
This category identifies Software Fault Patterns (SFPs) within the Other Exposures cluster.
This category identifies Software Fault Patterns (SFPs) within the State Disclosure cluster.
This category identifies Software Fault Patterns (SFPs) within the Covert Channel cluster.
This category identifies Software Fault Patterns (SFPs) within the Faulty Memory Release cluster (SFP12).
This category identifies Software Fault Patterns (SFPs) within the Faulty Buffer Access cluster (SFP8).
This category identifies Software Fault Patterns (SFPs) within the Faulty Pointer Use cluster (SFP7).
This category identifies Software Fault Patterns (SFPs) within the Faulty String Expansion cluster (SFP9).
This category identifies Software Fault Patterns (SFPs) within the Improper NULL Termination cluster (SFP11).
This category identifies Software Fault Patterns (SFPs) within the Incorrect Buffer Length Computation cluster (SFP10).
This category identifies Software Fault Patterns (SFPs) within the Architecture cluster.
This category identifies Software Fault Patterns (SFPs) within the Compiler cluster.
This category identifies Software Fault Patterns (SFPs) within the Design cluster.
This category identifies Software Fault Patterns (SFPs) within the Implementation cluster.
This category identifies Software Fault Patterns (SFPs) within the Failed Chroot Jail cluster (SFP17).
This category identifies Software Fault Patterns (SFPs) within the Link in Resource Name Resolution cluster (SFP18).
This category identifies Software Fault Patterns (SFPs) within the Path Traversal cluster (SFP16).
This category identifies Software Fault Patterns (SFPs) within the Failure to Release Resource cluster (SFP14).
This category identifies Software Fault Patterns (SFPs) within the Faulty Resource Use cluster (SFP15).
This category identifies Software Fault Patterns (SFPs) within the Life Cycle cluster.
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Consumption cluster (SFP13).
This category identifies Software Fault Patterns (SFPs) within the Missing Lock cluster (SFP19).
This category identifies Software Fault Patterns (SFPs) within the Multiple Locks/Unlocks cluster (SFP21).
This category identifies Software Fault Patterns (SFPs) within the Race Condition Window cluster (SFP20).
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Lock cluster (SFP22).
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Command cluster (SFP24).
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Environment cluster (SFP27).
This category identifies Software Fault Patterns (SFPs) within the Faulty Input Transformation cluster.
This category identifies Software Fault Patterns (SFPs) within the Incorrect Input Handling cluster.
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Variable cluster (SFP25).
This category identifies Software Fault Patterns (SFPs) within the Feature cluster.
This category identifies Software Fault Patterns (SFPs) within the Security cluster.
This category identifies Software Fault Patterns (SFPs) within the Information Loss cluster.
This category identifies Software Fault Patterns (SFPs) within the Glitch in Computation cluster (SFP1).
This category identifies Software Fault Patterns (SFPs) within the Use of an Improper API cluster (SFP3).
This category identifies Software Fault Patterns (SFPs) within the Unexpected Entry Points cluster.
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that exist when an application does not properly validate or represent input. According to the authors of the Seven Pernicious Kingdoms, "Input validation and representation problems are caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input."
Weaknesses in this category are related to coding practices that are deemed unsafe and increase the chances that an exploitable vulnerability will be present in the application. These weaknesses do not directly introduce a vulnerability, but indicate that the product has not been carefully developed or maintained. If a program is complex, difficult to maintain, not portable, or shows evidence of neglect, then there is a higher likelihood that weaknesses are buried in the code.
Weaknesses in this category are related to the design and architecture of audit-based components of the system. Frequently these deal with logging user activities in order to identify attackers and modifications to the system. The weaknesses in this category could lead to a degradation of the quality of the audit capability if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of authentication components of the system. Frequently these deal with verifying the entity is indeed who it claims to be. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of a system's authorization components. Frequently these deal with enforcing that agents have the required permissions before performing certain operations, such as modifying data. The weaknesses in this category could lead to a degradation of quality of the authorization capability if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of multiple security tactics and how they affect a system. For example, information exposure can impact the Limit Access and Limit Exposure security tactics. The weaknesses in this category could lead to a degradation of the quality of many capabilities if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of data confidentiality in a system. Frequently these deal with the use of encryption libraries. The weaknesses in this category could lead to a degradation of the quality data encryption if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of a system's identification management components. Frequently these deal with verifying that external agents provide inputs into the system. The weaknesses in this category could lead to a degradation of the quality of identification management if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of system resources. Frequently these deal with restricting the amount of resources that are accessed by actors, such as memory, network connections, CPU or access points. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of the entry points to a system. Frequently these deal with minimizing the attack surface through designing the system with the least needed amount of entry points. The weaknesses in this category could lead to a degradation of a system's defenses if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of a system's lockout mechanism. Frequently these deal with scenarios that take effect in case of multiple failed attempts to access a given resource. The weaknesses in this category could lead to a degradation of access to system assets if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of session management. Frequently these deal with the information or status about each user and their access rights for the duration of multiple requests. The weaknesses in this category could lead to a degradation of the quality of session management if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of a system's input validation components. Frequently these deal with sanitizing, neutralizing and validating any externally provided inputs to minimize malformed data from entering the system and preventing code injection in the input data. The weaknesses in this category could lead to a degradation of the quality of data flow in a system if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the design and architecture of a system's data integrity components. Frequently these deal with ensuring integrity of data, such as messages, resource files, deployment files, and configuration files. The weaknesses in this category could lead to a degradation of data integrity quality if they are not addressed when designing or implementing a secure architecture.
Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2017.
Weaknesses in this category are related to the CISQ Quality Measures for Reliability, as documented in 2016 with the Automated Source Code CISQ Reliability Measure (ASCRM) Specification 1.0. Presence of these weaknesses could reduce the reliability of the software.
Weaknesses in this category are related to the CISQ Quality Measures for Maintainability, as documented in 2016 with the Automated Source Code Maintainability Measure (ASCMM) Specification 1.0. Presence of these weaknesses could reduce the maintainability of the software.
Weaknesses in this category are related to the CISQ Quality Measures for Security, as documented in 2016 with the Automated Source Code Security Measure (ASCSM) Specification 1.0. Presence of these weaknesses could reduce the security of the software.
Weaknesses in this category are related to the CISQ Quality Measures for Performance Efficiency, as documented in 2016 with the Automated Source Code Performance Efficiency Measure (ASCPEM) Specification 1.0. Presence of these weaknesses could reduce the performance efficiency of the software.
Weaknesses in this category are related to the rules and recommendations in the Input Validation and Data Sanitization (IDS) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Numeric Types and Operations (NUM) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Object Orientation (OBJ) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Methods (MET) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Exceptional Behavior (ERR) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Visibility and Atomicity (VNA) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Locking (LCK) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Thread APIs (THI) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Thread Pools (TPS) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Thread-Safety Miscellaneous (TSM) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Serialization (SER) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Platform Security (SEC) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Runtime Environment (ENV) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Java Native Interface (JNI) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Android (DRD) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Preprocessor (PRE) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Integers (INT) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Floating Point (FLP) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Arrays (ARR) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Memory Management (MEM) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Environment (ENV) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Signals (SIG) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Error Handling (ERR) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Application Programming Interfaces (API) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Concurrency (CON) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the POSIX (POS) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Microsoft Windows (WIN) section of the SEI CERT C Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Concurrency (CON) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the rules and recommendations in the Input Validation and Data Sanitization (IDS) section of the SEI CERT Perl Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) section of the SEI CERT Perl Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT Perl Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Integers (INT) section of the SEI CERT Perl Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Strings (STR) section of the SEI CERT Perl Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Object-Oriented Programming (OOP) section of the SEI CERT Perl Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the File Input and Output (FIO) section of the SEI CERT Perl Coding Standard.
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) section of the SEI CERT Perl Coding Standard.
Weaknesses in this category are root-caused to defects that arise in the semiconductor-manufacturing process or during the life cycle and supply chain.
Weaknesses in this category are related to improper design of full-system security flows, including but not limited to secure boot, secure update, and hardware-device attestation.
Weaknesses in this category are those that arise due to integration of multiple hardware Intellectual Property (IP) cores, from System-on-a-Chip (SoC) subsystem interactions, or from hardware platform subsystem interactions.
Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of sensitive shared hardware resources such as registers and fuses.
Weaknesses in this category are related to hardware-circuit design and logic (e.g., CMOS transistors, finite state machines, and registers) as well as issues related to hardware description languages such as System Verilog and VHDL.
Weaknesses in this category are typically associated with CPUs, Graphics, Vision, AI, FPGA, and microcontrollers.
Weaknesses in this category are typically associated with memory (e.g., DRAM, SRAM) and storage technologies (e.g., NAND Flash, OTP, EEPROM, and eMMC).
Weaknesses in this category are related to hardware security problems that apply to peripheral devices, IO interfaces, on-chip interconnects, network-on-chip (NoC), and buses. For example, this category includes issues related to design of hardware interconnect and/or protocols such as PCIe, USB, SMBUS, general-purpose IO pins, and user-input peripherals such as mouse and keyboard.
Weaknesses in this category are related to hardware implementations of cryptographic protocols and other hardware-security primitives such as physical unclonable functions (PUFs) and random number generators (RNGs).
Weaknesses in this category are related to system power, voltage, current, temperature, clocks, system state saving/restoring, and resets at the platform and SoC level.
Weaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain.
Weaknesses in this category can arise in multiple areas of hardware design or can apply to a wide cross-section of components.
Weaknesses in this category are related to audit-based components of a software system. Frequently these deal with logging user activities in order to identify undesired access and modifications to the system. The weaknesses in this category could lead to a degradation of the quality of the audit capability if they are not addressed.
Weaknesses in this category are related to authentication components of a system. Frequently these deal with the ability to verify that an entity is indeed who it claims to be. If not addressed when designing or implementing a software system, these weaknesses could lead to a degradation of the quality of the authentication capability.
Weaknesses in this category are related to authorization components of a system. Frequently these deal with the ability to enforce that agents have the required permissions before performing certain operations, such as modifying data. If not addressed when designing or implementing a software system, these weaknesses could lead to a degradation of the quality of the authorization capability.
Weaknesses in this category are related to a software system's random number generation.
Weaknesses in this category are related to a software system's data integrity components. Frequently these deal with the ability to ensure the integrity of data, such as messages, resource files, deployment files, and configuration files. The weaknesses in this category could lead to a degradation of data integrity quality if they are not addressed.
Weaknesses in this category are related to a software system's components for input validation, output validation, or other kinds of validation. Validation is a frequently-used technique for ensuring that data conforms to expectations before it is further processed as input or output. There are many varieties of validation (see CWE-20, which is just for input validation). Validation is distinct from other techniques that attempt to modify data before processing it, although developers may consider all attempts to product "safe" inputs or outputs as some kind of validation. Regardless, validation is a powerful tool that is often used to minimize malformed data from entering the system, or indirectly avoid code injection or other potentially-malicious patterns when generating output. The weaknesses in this category could lead to a degradation of the quality of data flow in a system if they are not addressed.
Weaknesses in this category are related to a software system's lockout mechanism. Frequently these deal with scenarios that take effect in case of multiple failed attempts to access a given resource. The weaknesses in this category could lead to a degradation of access to system assets if they are not addressed.
Weaknesses in this category are related to session management. Frequently these deal with the information or status about each user and their access rights for the duration of multiple requests. The weaknesses in this category could lead to a degradation of the quality of session management if they are not addressed.
Weaknesses in this category are related to the handling of memory buffers within a software system.
Weaknesses in this category are related to the handling of files within a software system. Files, directories, and folders are so central to information technology that many different weaknesses and variants have been discovered.
Weaknesses in this category are related to the documentation provided to support, create, or analyze a product.
Weaknesses in this category are associated with things being overly complex.
Weaknesses in this category are related to issues surrounding the bundling of data with the methods intended to operate on that data.
Weaknesses in this category are related to the use of built-in functions or external APIs.
This category identifies Software Fault Patterns (SFPs) within the Faulty Resource Release cluster (SFP37).
This category identifies Software Fault Patterns (SFPs) within the Failure to Release Memory cluster (SFP38).
Weaknesses in this category are related to the CISQ Quality Measures for Reliability. Presence of these weaknesses could reduce the reliability of the software.
Weaknesses in this category are related to the CISQ Quality Measures for Maintainability. Presence of these weaknesses could reduce the maintainability of the software.
Weaknesses in this category are related to the CISQ Quality Measures for Security. Presence of these weaknesses could reduce the security of the software.
Weaknesses in this category are related to the CISQ Quality Measures for Efficiency. Presence of these weaknesses could reduce the efficiency of the software.
Weaknesses in this category are related to the A01 category "Broken Access Control" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A02 category "Cryptographic Failures" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A03 category "Injection" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A04 "Insecure Design" category in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A05 category "Security Misconfiguration" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A06 category "Vulnerable and Outdated Components" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A07 category "Identification and Authentication Failures" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A08 category "Software and Data Integrity Failures" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A09 category "Security Logging and Monitoring Failures" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the A10 category "Server-Side Request Forgery (SSRF)" in the OWASP Top Ten 2021.
Weaknesses in this category are related to the "ICS Communications" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Weaknesses in this category are related to the "ICS Dependencies (& Architecture)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Weaknesses in this category are related to the "ICS Supply Chain" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Weaknesses in this category are related to the "ICS Engineering (Constructions/Deployment)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Weaknesses in this category are related to the "ICS Operations (& Maintenance)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Weaknesses in this category are related to the "Zone Boundary Failures" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Within an ICS system, for traffic that crosses through network zone boundaries, vulnerabilities arise when those boundaries were designed for safety or other purposes but are being repurposed for security." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Unreliability" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Vulnerabilities arise in reaction to disruptions in the physical layer (e.g. creating electrical noise) used to carry the traffic." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Frail Security in Protocols" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Vulnerabilities arise as a result of mis-implementation or incomplete implementation of security in ICS implementations of communication protocols." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "External Physical Systems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Due to the highly interconnected technologies in use, an external dependency on another physical system could cause an availability interruption for the protected system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "External Digital Systems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Due to the highly interconnected technologies in use, an external dependency on another digital system could cause a confidentiality, integrity, or availability incident for the protected system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "IT/OT Convergence/Expansion" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The increased penetration of DER devices and smart loads make emerging ICS networks more like IT networks and thus susceptible to vulnerabilities similar to those of IT networks." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Common Mode Frailties" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "At the component level, most ICS systems are assembled from common parts made by other companies. One or more of these common parts might contain a vulnerability that could result in a wide-spread incident." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Poorly Documented or Undocumented Features" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Undocumented capabilities and configurations pose a risk by not having a clear understanding of what the device is specifically supposed to do and only do. Therefore possibly opening up the attack surface and vulnerabilities." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "OT Counterfeit and Malicious Corruption" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "In ICS, when this procurement process results in a vulnerability or component damage, it can have grid impacts or cause physical harm." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Trust Model Problems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Assumptions made about the user during the design or construction phase may result in vulnerabilities after the system is installed if the user operates it using a different security approach or process than what was designed or built." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Maker Breaker Blindness" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Lack of awareness of deliberate attack techniques by people (vs failure modes from natural causes like weather or metal fatigue) may lead to insufficient security controls being built into ICS systems." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Gaps in Details/Data" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Highly complex systems are often operated by personnel who have years of experience in managing that particular facility or plant. Much of their knowledge is passed along through verbal or hands-on training but may not be fully documented in written practices and procedures." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Security Gaps in Commissioning" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "As a large system is brought online components of the system may remain vulnerable until the entire system is operating and functional and security controls are put in place. This creates a window of opportunity for an adversary during the commissioning process." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Inherent Predictability in Design" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The commonality of design (in ICS/SCADA architectures) for energy systems and environments opens up the possibility of scaled compromise by leveraging the inherent predictability in the design." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Gaps in obligations and training" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "OT ownership and responsibility for identifying and mitigating vulnerabilities are not clearly defined or communicated within an organization, leaving environments unpatched, exploitable, and with a broader attack surface." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Human factors in ICS environments" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Environmental factors in ICS including physical duress, system complexities, and isolation may result in security gaps or inadequacies in the performance of individual duties and responsibilities." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Post-analysis changes" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Changes made to a previously analyzed and approved ICS environment can introduce new security vulnerabilities (as opposed to safety)." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Exploitable Standard Operational Procedures" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Standard ICS Operational Procedures developed for safety and operational functionality in a closed, controlled communications environment can introduce vulnerabilities in a more connected environment." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Emerging Energy Technologies" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "With the rapid evolution of the energy system accelerated by the emergence of new technologies such as DERs, electric vehicles, advanced communications (5G+), novel and diverse challenges arise for secure and resilient operation of the system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to the "Compliance/Conformance with Regulatory Requirements" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The ICS environment faces overlapping regulatory regimes and authorities with multiple focus areas (e.g., operational resiliency, physical safety, interoperability, and security) which can result in cyber security vulnerabilities when implemented as written due to gaps in considerations, outdatedness, or conflicting requirements." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Weaknesses in this category are related to concerns of physical access.
Weaknesses in this category are related to access control.
Weaknesses in this category are related to comparison.
Weaknesses in this category are related to component interaction.
Weaknesses in this category are related to memory safety.
Weaknesses in this category are related to concurrency.
Weaknesses in this category are related to encryption.
Weaknesses in this category are related to exposed resource.
Weaknesses in this category are related to file handling.
Weaknesses in this category are related to improper check or handling of exceptional conditions.
Weaknesses in this category are related to improper input validation.
Weaknesses in this category are related to improper neutralization.
Weaknesses in this category are related to incorrect calculation.
Weaknesses in this category are related to injection.
Weaknesses in this category are related to insufficient control flow management.
Weaknesses in this category are related to insufficient verification of data authenticity.
Weaknesses in this category are related to poor coding practices.
Weaknesses in this category are related to protection mechanism failure.
Weaknesses in this category are related to randomness.
Weaknesses in this category are related to resource control.
Weaknesses in this category are related to resource lifecycle management.
Weaknesses in this category are related to sensitive information exposure.
Weaknesses in this category are related to violation of secure design principles.
Weaknesses in this category were not included in the 2025 Most Important Hardware Weaknesses (MIHW) because they did not have sufficient weakness data to support their inclusion. However, they stand out as expert-driven selections. Each of these weaknesses received high scores from Subject Matter Experts, reflecting strong consensus among those with deep domain knowledge.