CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-1400: Comprehensive Categorization for Software Assurance Trends (4.17)  
ID

CWE VIEW: Comprehensive Categorization for Software Assurance Trends

View ID: 1400
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Type: Graph
Downloads: Booklet | CSV | XML
+ Objective

This view organizes weaknesses around categories that are of interest to large-scale software assurance research to support the elimination of weaknesses using tactics such as secure language development. It is also intended to help tracking weakness trends in publicly disclosed vulnerability data. This view is comprehensive in that every weakness must be contained in it, unlike most other views that only use a subset of weaknesses. This view is structured with categories at the top level, with a second level of only weaknesses. Relationships among the weaknesses presented under the research view (CWE-1000) are not shown.

Each weakness is added to only one category. All categories are mutually exclusive; that is, no weakness can be a member of more than one category. While weaknesses defy strict categorization along only one characteristic, the forced bucketing into a single category can simplify certain kinds of analysis.

Note that the size of each category can vary widely because (1) CWE is not as well fleshed-out in some areas compared to others; (2) abstraction of the CWEs in the grouping might go down to Variant level for some buckets, versus others.

+ Audience
Stakeholder Description
Academic Researchers Researchers can use this view to evaluate the breadth and depth of software assurance with respect to mitigating and managing weaknesses before they become vulnerabilities.
+ Relationships
The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.
Show Details:
1400 - Comprehensive Categorization for Software Assurance Trends
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Access Control - (1396)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control)
Weaknesses in this category are related to access control.
* Variant Variant - 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. J2EE Misconfiguration: Weak Access Permissions for EJB Methods - (9)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 9 (J2EE Misconfiguration: Weak Access Permissions for EJB Methods)
If elevated access rights are assigned to EJB methods, then an attacker can take advantage of the permissions to exploit the product.
* Variant Variant - 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. ASP.NET Misconfiguration: Password in Configuration File - (13)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 13 (ASP.NET Misconfiguration: Password in Configuration File)
Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.
* Base Base - a 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. Exposure of Sensitive Information Through Data Queries - (202)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 202 (Exposure of Sensitive Information Through Data Queries)
When trying to keep information confidential, an attacker can often infer some of the information by using statistics.
* Base Base - a 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. Plaintext Storage of a Password - (256)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 256 (Plaintext Storage of a Password)
Storing a password in plaintext may result in a system compromise.
* Base Base - a 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. Storing Passwords in a Recoverable Format - (257)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 257 (Storing Passwords in a Recoverable Format)
The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.
* Variant Variant - 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. Empty Password in Configuration File - (258)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 258 (Empty Password in Configuration File)
Using an empty string as a password is insecure.
* Variant Variant - 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. Use of Hard-coded Password - (259)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 259 (Use of Hard-coded Password)
The product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
* Base Base - a 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. Password in Configuration File - (260)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 260 (Password in Configuration File)
The product stores a password in a configuration file that might be accessible to actors who do not know the password.
* Base Base - a 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. Weak Encoding for Password - (261)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 261 (Weak Encoding for Password)
Obscuring a password with a trivial encoding does not protect the password.
* Base Base - a 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. Not Using Password Aging - (262)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 262 (Not Using Password Aging)
The product does not have a mechanism in place for managing password aging.
* Base Base - a 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. Password Aging with Long Expiration - (263)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 263 (Password Aging with Long Expiration)
The product supports password aging, but the expiration period is too long.
* Base Base - a 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. Incorrect Privilege Assignment - (266)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 266 (Incorrect Privilege Assignment)
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
* Base Base - a 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. Privilege Defined With Unsafe Actions - (267)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 267 (Privilege Defined With Unsafe Actions)
A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity.
* Base Base - a 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. Privilege Chaining - (268)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 268 (Privilege Chaining)
Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.
* Class Class - a weakness that is 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. Improper Privilege Management - (269)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 269 (Improper Privilege Management)
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
* Base Base - a 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. Privilege Context Switching Error - (270)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 270 (Privilege Context Switching Error)
The product does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.
* Class Class - a weakness that is 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. Privilege Dropping / Lowering Errors - (271)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 271 (Privilege Dropping / Lowering Errors)
The product does not drop privileges before passing control of a resource to an actor that does not have those privileges.
* Base Base - a 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. Least Privilege Violation - (272)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 272 (Least Privilege Violation)
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
* Base Base - a 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. Improper Check for Dropped Privileges - (273)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 273 (Improper Check for Dropped Privileges)
The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
* Base Base - a 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. Improper Handling of Insufficient Privileges - (274)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 274 (Improper Handling of Insufficient Privileges)
The product does not handle or incorrectly handles when it has insufficient privileges to perform an operation, leading to resultant weaknesses.
* Base Base - a 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. Incorrect Default Permissions - (276)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 276 (Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
* Variant Variant - 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. Insecure Inherited Permissions - (277)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 277 (Insecure Inherited Permissions)
A product defines a set of insecure permissions that are inherited by objects that are created by the program.
* Variant Variant - 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. Insecure Preserved Inherited Permissions - (278)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 278 (Insecure Preserved Inherited Permissions)
A product inherits a set of insecure permissions for an object, e.g. when copying from an archive file, without user awareness or involvement.
* Variant Variant - 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. Incorrect Execution-Assigned Permissions - (279)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 279 (Incorrect Execution-Assigned Permissions)
While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
* Base Base - a 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. Improper Handling of Insufficient Permissions or Privileges - (280)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 280 (Improper Handling of Insufficient Permissions or Privileges )
The product does not handle or incorrectly handles when it has insufficient privileges to access resources or functionality as specified by their permissions. This may cause it to follow unexpected code paths that may leave the product in an invalid state.
* Base Base - a 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. Improper Preservation of Permissions - (281)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 281 (Improper Preservation of Permissions)
The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.
* Class Class - a weakness that is 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. Improper Ownership Management - (282)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 282 (Improper Ownership Management)
The product assigns the wrong ownership, or does not properly verify the ownership, of an object or resource.
* Base Base - a 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. Unverified Ownership - (283)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 283 (Unverified Ownership)
The product does not properly verify that a critical resource is owned by the proper entity.
* Pillar Pillar - a weakness that 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. Improper Access Control - (284)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 284 (Improper Access Control)
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. Authorization
* Class Class - a weakness that is 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. Improper Authorization - (285)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 285 (Improper Authorization)
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. AuthZ
* Class Class - a weakness that is 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. Incorrect User Management - (286)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 286 (Incorrect User Management)
The product does not properly manage a user within its environment.
* Class Class - a weakness that is 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. Improper Authentication - (287)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 287 (Improper Authentication)
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. authentification AuthN AuthC
* Base Base - a 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. Authentication Bypass Using an Alternate Path or Channel - (288)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 288 (Authentication Bypass Using an Alternate Path or Channel)
The product requires authentication, but the product has an alternate path or channel that does not require authentication.
* Base Base - a 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. Authentication Bypass by Alternate Name - (289)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 289 (Authentication Bypass by Alternate Name)
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
* Base Base - a 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. Authentication Bypass by Spoofing - (290)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 290 (Authentication Bypass by Spoofing)
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
* Variant Variant - 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. Reliance on IP Address for Authentication - (291)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 291 (Reliance on IP Address for Authentication)
The product uses an IP address for authentication.
* Variant Variant - 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. Using Referer Field for Authentication - (293)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 293 (Using Referer Field for Authentication)
The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking. referrer
* Base Base - a 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. Authentication Bypass by Capture-replay - (294)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 294 (Authentication Bypass by Capture-replay)
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
* Base Base - a 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. Improper Certificate Validation - (295)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 295 (Improper Certificate Validation)
The product does not validate, or incorrectly validates, a certificate.
* Base Base - a 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. Improper Following of a Certificate's Chain of Trust - (296)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 296 (Improper Following of a Certificate's Chain of Trust)
The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
* Variant Variant - 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. Improper Validation of Certificate with Host Mismatch - (297)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 297 (Improper Validation of Certificate with Host Mismatch)
The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.
* Variant Variant - 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. Improper Validation of Certificate Expiration - (298)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 298 (Improper Validation of Certificate Expiration)
A certificate expiration is not validated or is incorrectly validated, so trust may be assigned to certificates that have been abandoned due to age.
* Base Base - a 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. Improper Check for Certificate Revocation - (299)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 299 (Improper Check for Certificate Revocation)
The product does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.
* Class Class - a weakness that is 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. Channel Accessible by Non-Endpoint - (300)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 300 (Channel Accessible by Non-Endpoint)
The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint. Adversary-in-the-Middle / AITM Man-in-the-Middle / MITM Person-in-the-Middle / PITM Monkey-in-the-Middle Monster-in-the-Middle Manipulator-in-the-Middle On-path attack Interception attack
* Base Base - a 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. Reflection Attack in an Authentication Protocol - (301)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 301 (Reflection Attack in an Authentication Protocol)
Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.
* Base Base - a 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. Authentication Bypass by Assumed-Immutable Data - (302)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 302 (Authentication Bypass by Assumed-Immutable Data)
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
* Base Base - a 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. Incorrect Implementation of Authentication Algorithm - (303)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 303 (Incorrect Implementation of Authentication Algorithm)
The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.
* Base Base - a 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. Missing Critical Step in Authentication - (304)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 304 (Missing Critical Step in Authentication)
The product implements an authentication technique, but it skips a step that weakens the technique.
* Base Base - a 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. Authentication Bypass by Primary Weakness - (305)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 305 (Authentication Bypass by Primary Weakness)
The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.
* Base Base - a 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. Missing Authentication for Critical Function - (306)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 306 (Missing Authentication for Critical Function)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
* Base Base - a 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. Improper Restriction of Excessive Authentication Attempts - (307)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 307 (Improper Restriction of Excessive Authentication Attempts)
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.
* Base Base - a 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. Use of Single-factor Authentication - (308)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 308 (Use of Single-factor Authentication)
The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.
* Base Base - a 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. Use of Password System for Primary Authentication - (309)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 309 (Use of Password System for Primary Authentication)
The use of password systems as the primary means of authentication may be subject to several flaws or shortcomings, each reducing the effectiveness of the mechanism.
* Variant Variant - 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. Use of Hard-coded Cryptographic Key - (321)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 321 (Use of Hard-coded Cryptographic Key)
The product uses a hard-coded, unchangeable cryptographic key.
* Base Base - a 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. Key Exchange without Entity Authentication - (322)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 322 (Key Exchange without Entity Authentication)
The product performs a key exchange with an actor without verifying the identity of that actor.
* Variant Variant - 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. Reliance on Reverse DNS Resolution for a Security-Critical Action - (350)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 350 (Reliance on Reverse DNS Resolution for a Security-Critical Action)
The product performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.
* Variant Variant - 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. Missing Check for Certificate Revocation after Initial Check - (370)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 370 (Missing Check for Certificate Revocation after Initial Check)
The product does not check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.
* Composite Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability. Session Fixation - (384)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 384 (Session Fixation)
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
* Base Base - a 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. Unprotected Primary Channel - (419)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 419 (Unprotected Primary Channel)
The product uses a primary channel for administration or restricted functionality, but it does not properly protect the channel.
* Base Base - a 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. Unprotected Alternate Channel - (420)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 420 (Unprotected Alternate Channel)
The product protects a primary channel, but it does not use the same level of protection for an alternate channel.
* Base Base - a 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. Race Condition During Access to Alternate Channel - (421)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 421 (Race Condition During Access to Alternate Channel)
The product opens an alternate channel to communicate with an authorized user, but the channel is accessible to other actors.
* Variant Variant - 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. Unprotected Windows Messaging Channel ('Shatter') - (422)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 422 (Unprotected Windows Messaging Channel ('Shatter'))
The product does not properly verify the source of a message in the Windows Messaging System while running at elevated privileges, creating an alternate channel through which an attacker can directly send a message to the product.
* Base Base - a 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. Direct Request ('Forced Browsing') - (425)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 425 (Direct Request ('Forced Browsing'))
The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files. forced browsing
* Class Class - a weakness that is 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. Unintended Proxy or Intermediary ('Confused Deputy') - (441)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Confused Deputy
* Variant Variant - 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. .NET Misconfiguration: Use of Impersonation - (520)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 520 (.NET Misconfiguration: Use of Impersonation)
Allowing a .NET application to run at potentially escalated levels of access to the underlying operating and file systems can be dangerous and result in various forms of attacks.
* Base Base - a 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. Weak Password Requirements - (521)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 521 (Weak Password Requirements)
The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts.
* Class Class - a weakness that is 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. Insufficiently Protected Credentials - (522)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 522 (Insufficiently Protected Credentials)
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
* Base Base - a 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. Unprotected Transport of Credentials - (523)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 523 (Unprotected Transport of Credentials)
Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.
* Base Base - a 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. Missing Password Field Masking - (549)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 549 (Missing Password Field Masking)
The product does not mask passwords during entry, increasing the potential for attackers to observe and capture passwords.
* Base Base - a 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. Incorrect Behavior Order: Authorization Before Parsing and Canonicalization - (551)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 551 (Incorrect Behavior Order: Authorization Before Parsing and Canonicalization)
If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.
* Variant Variant - 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. J2EE Misconfiguration: Plaintext Password in Configuration File - (555)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 555 (J2EE Misconfiguration: Plaintext Password in Configuration File)
The J2EE application stores a plaintext password in a configuration file.
* Variant Variant - 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. ASP.NET Misconfiguration: Use of Identity Impersonation - (556)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 556 (ASP.NET Misconfiguration: Use of Identity Impersonation)
Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.
* Variant Variant - 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. Authorization Bypass Through User-Controlled SQL Primary Key - (566)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 566 (Authorization Bypass Through User-Controlled SQL Primary Key)
The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
* Variant Variant - 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. Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created - (593)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 593 (Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created)
The product modifies the SSL context after connection creation has begun.
* Variant Variant - 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. Missing Validation of OpenSSL Certificate - (599)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 599 (Missing Validation of OpenSSL Certificate)
The product uses OpenSSL and trusts or uses a certificate without using the SSL_get_verify_result() function to ensure that the certificate satisfies all necessary security requirements.
* Base Base - a 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. URL Redirection to Untrusted Site ('Open Redirect') - (601)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 601 (URL Redirection to Untrusted Site ('Open Redirect'))
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect. Open Redirect Cross-site Redirect Cross-domain Redirect Unvalidated Redirect
* Base Base - a 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. Use of Client-Side Authentication - (603)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 603 (Use of Client-Side Authentication)
A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.
* Base Base - a 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. Improper Restriction of XML External Entity Reference - (611)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 611 (Improper Restriction of XML External Entity Reference)
The product processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output. XXE
* Base Base - a 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. Improper Authorization of Index Containing Sensitive Information - (612)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 612 (Improper Authorization of Index Containing Sensitive Information)
The product creates a search index of private or sensitive documents, but it does not properly limit index access to actors who are authorized to see the original information.
* Base Base - a 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. Insufficient Session Expiration - (613)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 613 (Insufficient Session Expiration)
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
* Base Base - a 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. Unverified Password Change - (620)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 620 (Unverified Password Change)
When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication.
* Variant Variant - 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. Unsafe ActiveX Control Marked Safe For Scripting - (623)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 623 (Unsafe ActiveX Control Marked Safe For Scripting)
An ActiveX control is intended for restricted use, but it has been marked as safe-for-scripting.
* Base Base - a 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. Authorization Bypass Through User-Controlled Key - (639)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 639 (Authorization Bypass Through User-Controlled Key)
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. Insecure Direct Object Reference / IDOR Broken Object Level Authorization / BOLA Horizontal Authorization
* Base Base - a 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. Weak Password Recovery Mechanism for Forgotten Password - (640)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 640 (Weak Password Recovery Mechanism for Forgotten Password)
The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
* Base Base - a 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. Overly Restrictive Account Lockout Mechanism - (645)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 645 (Overly Restrictive Account Lockout Mechanism)
The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.
* Variant Variant - 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. Use of Non-Canonical URL Paths for Authorization Decisions - (647)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 647 (Use of Non-Canonical URL Paths for Authorization Decisions)
The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
* Base Base - a 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. Incorrect Use of Privileged APIs - (648)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 648 (Incorrect Use of Privileged APIs)
The product does not conform to the API requirements for a function call that requires extra privileges. This could allow attackers to gain privileges by causing the function to be called incorrectly.
* Base Base - a 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. Incorrect Ownership Assignment - (708)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 708 (Incorrect Ownership Assignment)
The product assigns an owner to a resource, but the owner is outside of the intended control sphere.
* Class Class - a weakness that is 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. Incorrect Permission Assignment for Critical Resource - (732)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 732 (Incorrect Permission Assignment for Critical Resource)
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
* Base Base - a 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. Use of Hard-coded Credentials - (798)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 798 (Use of Hard-coded Credentials)
The product contains hard-coded credentials, such as a password or cryptographic key.
* Base Base - a 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. Guessable CAPTCHA - (804)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 804 (Guessable CAPTCHA)
The product uses a CAPTCHA challenge, but the challenge can be guessed or automatically recognized by a non-human actor.
* Base Base - a 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. Use of Password Hash Instead of Password for Authentication - (836)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 836 (Use of Password Hash Instead of Password for Authentication)
The product records password hashes in a data store, receives a hash of a password from a client, and compares the supplied hash to the hash obtained from the data store.
* Base Base - a 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. Placement of User into Incorrect Group - (842)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 842 (Placement of User into Incorrect Group)
The product or the administrator places a user into an incorrect group.
* Class Class - a weakness that is 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. Missing Authorization - (862)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 862 (Missing Authorization)
The product does not perform an authorization check when an actor attempts to access a resource or perform an action. AuthZ
* Class Class - a weakness that is 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. Incorrect Authorization - (863)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 863 (Incorrect Authorization)
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. AuthZ
* Base Base - a 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. Server-Side Request Forgery (SSRF) - (918)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 918 (Server-Side Request Forgery (SSRF))
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. XSPA SSRF
* Base Base - a 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. Storage of Sensitive Data in a Mechanism without Access Control - (921)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 921 (Storage of Sensitive Data in a Mechanism without Access Control)
The product stores sensitive information in a file system or device that does not have built-in access control.
* Class Class - a weakness that is 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. Improper Restriction of Communication Channel to Intended Endpoints - (923)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 923 (Improper Restriction of Communication Channel to Intended Endpoints)
The product establishes a communication channel to (or from) an endpoint for privileged or protected operations, but it does not properly ensure that it is communicating with the correct endpoint.
* Variant Variant - 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. Improper Verification of Intent by Broadcast Receiver - (925)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 925 (Improper Verification of Intent by Broadcast Receiver)
The Android application uses a Broadcast Receiver that receives an Intent but does not properly verify that the Intent came from an authorized source. Intent Spoofing
* Variant Variant - 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. Improper Export of Android Application Components - (926)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 926 (Improper Export of Android Application Components)
The Android application exports a component for use by other applications, but does not properly restrict which applications can launch the component or access the data it contains.
* Variant Variant - 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. Use of Implicit Intent for Sensitive Communication - (927)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 927 (Use of Implicit Intent for Sensitive Communication)
The Android application uses an implicit intent for transmitting sensitive data to other applications.
* Base Base - a 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. Improper Authorization in Handler for Custom URL Scheme - (939)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 939 (Improper Authorization in Handler for Custom URL Scheme)
The product uses a handler for a custom URL scheme, but it does not properly restrict which actors can invoke the handler using the scheme.
* Base Base - a 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. Improper Verification of Source of a Communication Channel - (940)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 940 (Improper Verification of Source of a Communication Channel)
The product establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.
* Base Base - a 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. Incorrectly Specified Destination in a Communication Channel - (941)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 941 (Incorrectly Specified Destination in a Communication Channel)
The product creates a communication channel to initiate an outgoing request to an actor, but it does not correctly specify the intended destination for that actor.
* Variant Variant - 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. Permissive Cross-domain Policy with Untrusted Domains - (942)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 942 (Permissive Cross-domain Policy with Untrusted Domains)
The product uses a cross-domain policy file that includes domains that should not be trusted.
* Variant Variant - 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. Sensitive Cookie Without 'HttpOnly' Flag - (1004)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1004 (Sensitive Cookie Without 'HttpOnly' Flag)
The product uses a cookie to store sensitive information, but the cookie is not marked with the HttpOnly flag.
* Base Base - a 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. Improper Restriction of Rendered UI Layers or Frames - (1021)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1021 (Improper Restriction of Rendered UI Layers or Frames)
The web application does not restrict or incorrectly restricts frame objects or UI layers that belong to another application or domain, which can lead to user confusion about which interface the user is interacting with. Clickjacking UI Redress Attack Tapjacking
* Variant Variant - 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. Use of Web Link to Untrusted Target with window.opener Access - (1022)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1022 (Use of Web Link to Untrusted Target with window.opener Access)
The web application produces links to untrusted external sites outside of its sphere of control, but it does not properly prevent the external site from modifying security-critical properties of the window.opener object, such as the location property. tabnabbing
* Base Base - a 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. On-Chip Debug and Test Interface With Improper Access Control - (1191)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1191 (On-Chip Debug and Test Interface With Improper Access Control)
The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.
* Base Base - a 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. Insufficient Granularity of Access Control - (1220)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1220 (Insufficient Granularity of Access Control)
The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.
* Variant Variant - 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. Insufficient Granularity of Address Regions Protected by Register Locks - (1222)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1222 (Insufficient Granularity of Address Regions Protected by Register Locks)
The product defines a large address region protected from modification by the same register lock control bit. This results in a conflict between the functional requirement that some addresses need to be writable by software during operation and the security requirement that the system configuration lock bit must be set during the boot process.
* Base Base - a 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. Improper Restriction of Write-Once Bit Fields - (1224)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1224 (Improper Restriction of Write-Once Bit Fields)
The hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.
* Base Base - a 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. Exposure of Sensitive Information Through Metadata - (1230)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1230 (Exposure of Sensitive Information Through Metadata)
The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.
* Base Base - a 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. Improper Prevention of Lock Bit Modification - (1231)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1231 (Improper Prevention of Lock Bit Modification)
The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.
* Base Base - a 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. Security-Sensitive Hardware Controls with Missing Lock Bit Protection - (1233)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1233 (Security-Sensitive Hardware Controls with Missing Lock Bit Protection)
The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.
* Base Base - a 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. Inclusion of Undocumented Features or Chicken Bits - (1242)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1242 (Inclusion of Undocumented Features or Chicken Bits)
The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.
* Base Base - a 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. Sensitive Non-Volatile Information Not Protected During Debug - (1243)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1243 (Sensitive Non-Volatile Information Not Protected During Debug)
Access to security-sensitive information stored in fuses is not limited during debug.
* Base Base - a 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. Internal Asset Exposed to Unsafe Debug Access Level or State - (1244)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1244 (Internal Asset Exposed to Unsafe Debug Access Level or State)
The product uses physical debug or test interfaces with support for multiple access levels, but it assigns the wrong debug access level to an internal asset, providing unintended access to the asset from untrusted debug agents.
* Base Base - a 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. CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations - (1252)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1252 (CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations)
The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.
* Base Base - a 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. Improper Restriction of Software Interfaces to Hardware Features - (1256)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1256 (Improper Restriction of Software Interfaces to Hardware Features)
The product provides software-controllable device functionality for capabilities such as power and clock management, but it does not properly limit functionality that can lead to modification of hardware memory or register bits, or the ability to observe physical side channels.
* Base Base - a 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. Improper Access Control Applied to Mirrored or Aliased Memory Regions - (1257)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1257 (Improper Access Control Applied to Mirrored or Aliased Memory Regions)
Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware. A possible result is that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region.
* Base Base - a 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. Improper Restriction of Security Token Assignment - (1259)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1259 (Improper Restriction of Security Token Assignment)
The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.
* Base Base - a 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. Improper Handling of Overlap Between Protected Memory Ranges - (1260)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1260 (Improper Handling of Overlap Between Protected Memory Ranges)
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
* Base Base - a 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. Improper Access Control for Register Interface - (1262)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1262 (Improper Access Control for Register Interface)
The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.
* Class Class - a weakness that is 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. Improper Physical Access Control - (1263)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1263 (Improper Physical Access Control)
The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.
* Base Base - a 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. Policy Uses Obsolete Encoding - (1267)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1267 (Policy Uses Obsolete Encoding)
The product uses an obsolete encoding mechanism to implement access controls.
* Base Base - a 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. Policy Privileges are not Assigned Consistently Between Control and Data Agents - (1268)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1268 (Policy Privileges are not Assigned Consistently Between Control and Data Agents)
The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.
* Base Base - a 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. Generation of Incorrect Security Tokens - (1270)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1270 (Generation of Incorrect Security Tokens)
The product implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens generated in the system are incorrect.
* Base Base - a 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. Improper Access Control for Volatile Memory Containing Boot Code - (1274)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1274 (Improper Access Control for Volatile Memory Containing Boot Code)
The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.
* Variant Variant - 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. Sensitive Cookie with Improper SameSite Attribute - (1275)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1275 (Sensitive Cookie with Improper SameSite Attribute)
The SameSite attribute for sensitive cookies is not set, or an insecure value is used.
* Base Base - a 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. Hardware Child Block Incorrectly Connected to Parent System - (1276)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1276 (Hardware Child Block Incorrectly Connected to Parent System)
Signals between a hardware IP and the parent system design are incorrectly connected causing security risks.
* Base Base - a 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. Mutable Attestation or Measurement Reporting Data - (1283)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1283 (Mutable Attestation or Measurement Reporting Data)
The register contents used for attestation or measurement reporting data to verify boot flow are modifiable by an adversary.
* Base Base - a 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. Incorrect Decoding of Security Identifiers - (1290)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1290 (Incorrect Decoding of Security Identifiers )
The product implements a decoding mechanism to decode certain bus-transaction signals to security identifiers. If the decoding is implemented incorrectly, then untrusted agents can now gain unauthorized access to the asset.
* Base Base - a 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. Incorrect Conversion of Security Identifiers - (1292)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1292 (Incorrect Conversion of Security Identifiers)
The product implements a conversion mechanism to map certain bus-transaction signals to security identifiers. However, if the conversion is incorrectly implemented, untrusted agents can gain unauthorized access to the asset.
* Class Class - a weakness that is 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. Insecure Security Identifier Mechanism - (1294)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1294 (Insecure Security Identifier Mechanism)
The System-on-Chip (SoC) implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers are not correctly implemented.
* Base Base - a 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. Incorrect Chaining or Granularity of Debug Components - (1296)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1296 (Incorrect Chaining or Granularity of Debug Components)
The product's debug components contain incorrect chaining or granularity of debug components.
* Base Base - a 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. Unprotected Confidential Information on Device is Accessible by OSAT Vendors - (1297)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1297 (Unprotected Confidential Information on Device is Accessible by OSAT Vendors)
The product does not adequately protect confidential information on the device from being accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.
* Base Base - a 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. Missing Protection Mechanism for Alternate Hardware Interface - (1299)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1299 (Missing Protection Mechanism for Alternate Hardware Interface)
The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.
* Base Base - a 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. Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC) - (1302)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1302 (Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC))
The product implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. A transaction is sent without a security identifier.
* Base Base - a 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. Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation - (1304)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1304 (Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation)
The product performs a power save/restore operation, but it does not ensure that the integrity of the configuration state is maintained and/or verified between the beginning and ending of the operation.
* Base Base - a 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. Improper Translation of Security Attributes by Fabric Bridge - (1311)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1311 (Improper Translation of Security Attributes by Fabric Bridge)
The bridge incorrectly translates security attributes from either trusted to untrusted or from untrusted to trusted when converting from one fabric protocol to another.
* Base Base - a 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. Missing Protection for Mirrored Regions in On-Chip Fabric Firewall - (1312)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1312 (Missing Protection for Mirrored Regions in On-Chip Fabric Firewall)
The firewall in an on-chip fabric protects the main addressed region, but it does not protect any mirrored memory or memory-mapped-IO (MMIO) regions.
* Base Base - a 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. Hardware Allows Activation of Test or Debug Logic at Runtime - (1313)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1313 (Hardware Allows Activation of Test or Debug Logic at Runtime)
During runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary.
* Base Base - a 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. Missing Write Protection for Parametric Data Values - (1314)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1314 (Missing Write Protection for Parametric Data Values)
The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure.
* Base Base - a 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. Improper Setting of Bus Controlling Capability in Fabric End-point - (1315)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1315 (Improper Setting of Bus Controlling Capability in Fabric End-point)
The bus controller enables bits in the fabric end-point to allow responder devices to control transactions on the fabric.
* Base Base - a 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. Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges - (1316)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1316 (Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges)
The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.
* Base Base - a 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. Improper Access Control in Fabric Bridge - (1317)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1317 (Improper Access Control in Fabric Bridge)
The product uses a fabric bridge for transactions between two Intellectual Property (IP) blocks, but the bridge does not properly perform the expected privilege, identity, or other access control checks between those IP blocks.
* Base Base - a 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. Improper Protection for Outbound Error Messages and Alert Signals - (1320)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1320 (Improper Protection for Outbound Error Messages and Alert Signals)
Untrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts.
* Base Base - a 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. Improper Management of Sensitive Trace Data - (1323)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1323 (Improper Management of Sensitive Trace Data)
Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.
* Base Base - a 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. Security Version Number Mutable to Older Versions - (1328)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1328 (Security Version Number Mutable to Older Versions)
Security-version number in hardware is mutable, resulting in the ability to downgrade (roll-back) the boot firmware to vulnerable code versions.
* Base Base - a 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. Unauthorized Error Injection Can Degrade Hardware Redundancy - (1334)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1334 (Unauthorized Error Injection Can Degrade Hardware Redundancy)
An unauthorized agent can inject errors into a redundant block to deprive the system of redundancy or put the system in a degraded operating mode.
* Class Class - a weakness that is 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. Weak Authentication - (1390)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1390 (Weak Authentication)
The product uses an authentication mechanism to restrict access to specific users or identities, but the mechanism does not sufficiently prove that the claimed identity is correct.
* Class Class - a weakness that is 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. Use of Weak Credentials - (1391)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1391 (Use of Weak Credentials)
The product uses weak credentials (such as a default key or hard-coded password) that can be calculated, derived, reused, or guessed by an attacker.
* Base Base - a 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. Use of Default Credentials - (1392)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1392 (Use of Default Credentials)
The product uses default credentials (such as passwords or cryptographic keys) for potentially critical functionality.
* Base Base - a 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. Use of Default Password - (1393)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1393 (Use of Default Password)
The product uses default passwords for potentially critical functionality.
* Base Base - a 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. Use of Default Cryptographic Key - (1394)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1396 (Comprehensive Categorization: Access Control) > 1394 (Use of Default Cryptographic Key)
The product uses a default cryptographic key for potentially critical functionality.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Comparison - (1397)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison)
Weaknesses in this category are related to comparison.
* Base Base - a 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. Permissive List of Allowed Inputs - (183)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 183 (Permissive List of Allowed Inputs)
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses. Allowlist / Allow List Safelist / Safe List Whitelist / White List
* Class Class - a weakness that is 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. Incorrect Regular Expression - (185)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 185 (Incorrect Regular Expression)
The product specifies a regular expression in a way that causes data to be improperly matched or compared.
* Base Base - a 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. Overly Restrictive Regular Expression - (186)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 186 (Overly Restrictive Regular Expression)
A regular expression is overly restrictive, which prevents dangerous values from being detected.
* Variant Variant - 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. Partial String Comparison - (187)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 187 (Partial String Comparison)
The product performs a comparison that only examines a portion of a factor before determining whether there is a match, such as a substring, leading to resultant weaknesses.
* Base Base - a 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. Missing Default Case in Multiple Condition Expression - (478)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 478 (Missing Default Case in Multiple Condition Expression)
The code does not have a default case in an expression with multiple conditions, such as a switch statement.
* Variant Variant - 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. Comparison of Classes by Name - (486)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 486 (Comparison of Classes by Name)
The product compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.
* Variant Variant - 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. Comparison of Object References Instead of Object Contents - (595)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 595 (Comparison of Object References Instead of Object Contents)
The product compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
* Variant Variant - 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. Use of Wrong Operator in String Comparison - (597)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 597 (Use of Wrong Operator in String Comparison)
The product uses the wrong operator when comparing a string, such as using "==" when the .equals() method should be used instead.
* Base Base - a 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. Permissive Regular Expression - (625)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 625 (Permissive Regular Expression)
The product uses a regular expression that does not sufficiently restrict the set of allowed values.
* Pillar Pillar - a weakness that 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. Incorrect Comparison - (697)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 697 (Incorrect Comparison)
The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
* Variant Variant - 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. Regular Expression without Anchors - (777)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 777 (Regular Expression without Anchors)
The product uses a regular expression to perform neutralization, but the regular expression is not anchored and may allow malicious or malformed data to slip through.
* Base Base - a 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. Numeric Range Comparison Without Minimum Check - (839)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 839 (Numeric Range Comparison Without Minimum Check)
The product checks a value to ensure that it is less than or equal to a maximum, but it does not also verify that the value is greater than or equal to the minimum. Signed comparison
* Class Class - a weakness that is 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. Incomplete Comparison with Missing Factors - (1023)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 1023 (Incomplete Comparison with Missing Factors)
The product performs a comparison between entities that must consider multiple factors or characteristics of each entity, but the comparison does not include one or more of these factors.
* Base Base - a 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. Comparison of Incompatible Types - (1024)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 1024 (Comparison of Incompatible Types)
The product performs a comparison between two entities, but the entities are of different, incompatible types that cannot be guaranteed to provide correct results when they are directly compared.
* Base Base - a 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. Comparison Using Wrong Factors - (1025)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 1025 (Comparison Using Wrong Factors)
The code performs a comparison between two entities, but the comparison examines the wrong factors or characteristics of the entities, which can lead to incorrect results and resultant weaknesses.
* Variant Variant - 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. Floating Point Comparison with Incorrect Operator - (1077)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1397 (Comprehensive Categorization: Comparison) > 1077 (Floating Point Comparison with Incorrect Operator)
The code performs a comparison such as an equality test between two float (floating point) values, but it uses comparison operators that do not account for the possibility of loss of precision.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Component Interaction - (1398)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction)
Weaknesses in this category are related to component interaction.
* Variant Variant - 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. Compiler Removal of Code to Clear Buffers - (14)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 14 (Compiler Removal of Code to Clear Buffers)
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
* Base Base - a 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. Misinterpretation of Input - (115)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 115 (Misinterpretation of Input)
The product misinterprets an input, whether from an attacker or another product, in a security-relevant fashion.
* Pillar Pillar - a weakness that 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. Improper Interaction Between Multiple Correctly-Behaving Entities - (435)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 435 (Improper Interaction Between Multiple Correctly-Behaving Entities)
An interaction error occurs when two entities have correct behavior when running independently of each other, but when they are integrated as components in a larger system or process, they introduce incorrect behaviors that may cause resultant weaknesses. Interaction Error Emergent Fault
* Class Class - a weakness that is 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. Interpretation Conflict - (436)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 436 (Interpretation Conflict)
Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
* Base Base - a 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. Incomplete Model of Endpoint Features - (437)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 437 (Incomplete Model of Endpoint Features)
A product acts as an intermediary or monitor between two or more endpoints, but it does not have a complete model of an endpoint's features, behaviors, or state, potentially causing the product to perform incorrect actions based on this incomplete model.
* Base Base - a 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. Behavioral Change in New Version or Environment - (439)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 439 (Behavioral Change in New Version or Environment)
A's behavior or functionality changes with a new version of A, or a new environment, which is not known (or manageable) by B. Functional change
* Base Base - a 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. Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - (444)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling'))
The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination. HTTP Request Smuggling HTTP Response Smuggling HTTP Smuggling
* Variant Variant - 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. Trusting HTTP Permission Methods on the Server Side - (650)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 650 (Trusting HTTP Permission Methods on the Server Side)
The server contains a protection mechanism that assumes that any URI that is accessed using HTTP GET will not cause a state change to the associated resource. This might allow attackers to bypass intended access restrictions and conduct resource modification and deletion attacks, since some applications allow GET to modify state.
* Base Base - a 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. Compiler Optimization Removal or Modification of Security-critical Code - (733)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 733 (Compiler Optimization Removal or Modification of Security-critical Code)
The developer builds a security-critical protection mechanism into the software, but the compiler optimizes the program such that the mechanism is removed or modified.
* Base Base - a 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. Processor Optimization Removal or Modification of Security-critical Code - (1037)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 1037 (Processor Optimization Removal or Modification of Security-critical Code)
The developer builds a security-critical protection mechanism into the software, but the processor optimizes the execution of the program such that the mechanism is removed or modified.
* Class Class - a weakness that is 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. Insecure Automated Optimizations - (1038)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1398 (Comprehensive Categorization: Component Interaction) > 1038 (Insecure Automated Optimizations)
The product uses a mechanism that automatically optimizes code, e.g. to improve a characteristic such as performance, but the optimizations can have an unintended side effect that might violate an intended security assumption.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Concurrency - (1401)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency)
Weaknesses in this category are related to concurrency.
* Class Class - a weakness that is 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. Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. Race Condition
* Base Base - a 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. Race Condition Enabling Link Following - (363)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 363 (Race Condition Enabling Link Following)
The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.
* Base Base - a 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. Signal Handler Race Condition - (364)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 364 (Signal Handler Race Condition)
The product uses a signal handler that introduces a race condition.
* Base Base - a 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. Race Condition within a Thread - (366)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 366 (Race Condition within a Thread)
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
* Base Base - a 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. Time-of-check Time-of-use (TOCTOU) Race Condition - (367)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 367 (Time-of-check Time-of-use (TOCTOU) Race Condition)
The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the product to perform invalid actions when the resource is in an unexpected state. TOCTTOU TOCCTOU
* Base Base - a 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. Context Switching Race Condition - (368)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 368 (Context Switching Race Condition)
A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product's behavior during the switch.
* Base Base - a 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. Unrestricted Externally Accessible Lock - (412)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 412 (Unrestricted Externally Accessible Lock)
The product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.
* Base Base - a 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. Improper Resource Locking - (413)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 413 (Improper Resource Locking)
The product does not lock or does not correctly lock a resource when the product must have exclusive access to the resource.
* Base Base - a 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. Missing Lock Check - (414)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 414 (Missing Lock Check)
A product does not check to see if a lock is present before performing sensitive operations on a resource.
* Base Base - a 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. Dangerous Signal Handler not Disabled During Sensitive Operations - (432)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 432 (Dangerous Signal Handler not Disabled During Sensitive Operations)
The product uses a signal handler that shares state with other signal handlers, but it does not properly mask or prevent those signal handlers from being invoked while the original signal handler is still running.
* Variant Variant - 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. Signal Handler Use of a Non-reentrant Function - (479)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 479 (Signal Handler Use of a Non-reentrant Function)
The product defines a signal handler that calls a non-reentrant function.
* Variant Variant - 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. Use of Singleton Pattern Without Synchronization in a Multithreaded Context - (543)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 543 (Use of Singleton Pattern Without Synchronization in a Multithreaded Context)
The product uses the singleton pattern when creating a resource within a multithreaded environment.
* Variant Variant - 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. Use of getlogin() in Multithreaded Application - (558)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 558 (Use of getlogin() in Multithreaded Application)
The product uses the getlogin() function in a multithreaded context, potentially causing it to return incorrect values.
* Base Base - a 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. Unsynchronized Access to Shared Data in a Multithreaded Context - (567)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 567 (Unsynchronized Access to Shared Data in a Multithreaded Context)
The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.
* Variant Variant - 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. Call to Thread run() instead of start() - (572)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 572 (Call to Thread run() instead of start())
The product calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.
* Variant Variant - 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. EJB Bad Practices: Use of Synchronization Primitives - (574)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 574 (EJB Bad Practices: Use of Synchronization Primitives)
The product violates the Enterprise JavaBeans (EJB) specification by using thread synchronization primitives.
* Variant Variant - 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. Sensitive Data Storage in Improperly Locked Memory - (591)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 591 (Sensitive Data Storage in Improperly Locked Memory)
The product stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.
* Base Base - a 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. Double-Checked Locking - (609)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 609 (Double-Checked Locking)
The product uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.
* Base Base - a 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. Use of a Non-reentrant Function in a Concurrent Context - (663)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 663 (Use of a Non-reentrant Function in a Concurrent Context)
The product calls a non-reentrant function in a concurrent context in which a competing code sequence (e.g. thread or signal handler) may have an opportunity to call the same function or otherwise influence its state.
* Class Class - a weakness that is 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. Improper Locking - (667)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 667 (Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
* Composite Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability. Permission Race Condition During Resource Copy - (689)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 689 (Permission Race Condition During Resource Copy)
The product, while copying or cloning a resource, does not set the resource's permissions or access control until the copy is complete, leaving the resource exposed to other spheres while the copy is taking place.
* Base Base - a 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. Multiple Locks of a Critical Resource - (764)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 764 (Multiple Locks of a Critical Resource)
The product locks a critical resource more times than intended, leading to an unexpected state in the system.
* Base Base - a 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. Multiple Unlocks of a Critical Resource - (765)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 765 (Multiple Unlocks of a Critical Resource)
The product unlocks a critical resource more times than intended, leading to an unexpected state in the system.
* Base Base - a 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. Missing Synchronization - (820)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 820 (Missing Synchronization)
The product utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.
* Base Base - a 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. Incorrect Synchronization - (821)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 821 (Incorrect Synchronization)
The product utilizes a shared resource in a concurrent manner, but it does not correctly synchronize access to the resource.
* Variant Variant - 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. Signal Handler with Functionality that is not Asynchronous-Safe - (828)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 828 (Signal Handler with Functionality that is not Asynchronous-Safe)
The product defines a signal handler that contains code sequences that are not asynchronous-safe, i.e., the functionality is not reentrant, or it can be interrupted.
* Variant Variant - 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. Signal Handler Function Associated with Multiple Signals - (831)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 831 (Signal Handler Function Associated with Multiple Signals)
The product defines a function that is used as a handler for more than one signal.
* Base Base - a 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. Unlock of a Resource that is not Locked - (832)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 832 (Unlock of a Resource that is not Locked)
The product attempts to unlock a resource that is not locked.
* Base Base - a 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. Deadlock - (833)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 833 (Deadlock)
The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.
* Base Base - a 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. Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element - (1058)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 1058 (Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element)
The code contains a function or method that operates in a multi-threaded environment but owns an unsafe non-final static storable or member data element.
* Base Base - a 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. Synchronous Access of Remote Resource without Timeout - (1088)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 1088 (Synchronous Access of Remote Resource without Timeout)
The code has a synchronous call to a remote resource, but there is no timeout for the call, or the timeout is set to infinite.
* Variant Variant - 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. Singleton Class Instance Creation without Proper Locking or Synchronization - (1096)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 1096 (Singleton Class Instance Creation without Proper Locking or Synchronization)
The product implements a Singleton design pattern but does not use appropriate locking or other synchronization mechanism to ensure that the singleton class is only instantiated once.
* Base Base - a 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. Race Condition for Write-Once Attributes - (1223)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 1223 (Race Condition for Write-Once Attributes)
A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.
* Base Base - a 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. Improper Lock Behavior After Power State Transition - (1232)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 1232 (Improper Lock Behavior After Power State Transition)
Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.
* Base Base - a 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. Hardware Internal or Debug Modes Allow Override of Locks - (1234)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 1234 (Hardware Internal or Debug Modes Allow Override of Locks)
System configuration protection may be bypassed during debug mode.
* Base Base - a 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. Hardware Logic with Insecure De-Synchronization between Control and Data Channels - (1264)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 1264 (Hardware Logic with Insecure De-Synchronization between Control and Data Channels)
The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.
* Base Base - a 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. Hardware Logic Contains Race Conditions - (1298)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1401 (Comprehensive Categorization: Concurrency) > 1298 (Hardware Logic Contains Race Conditions)
A race condition in the hardware logic results in undermining security guarantees of the system.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Encryption - (1402)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption)
Weaknesses in this category are related to encryption.
* Variant Variant - 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. J2EE Misconfiguration: Data Transmission Without Encryption - (5)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 5 (J2EE Misconfiguration: Data Transmission Without Encryption)
Information sent over a network can be compromised while in transit. An attacker may be able to read or modify the contents if the data are sent in plaintext or are weakly encrypted.
* Class Class - a weakness that is 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. Missing Encryption of Sensitive Data - (311)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 311 (Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
* Base Base - a 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. Cleartext Storage of Sensitive Information - (312)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 312 (Cleartext Storage of Sensitive Information)
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
* Variant Variant - 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. Cleartext Storage in a File or on Disk - (313)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 313 (Cleartext Storage in a File or on Disk)
The product stores sensitive information in cleartext in a file, or on disk.
* Variant Variant - 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. Cleartext Storage in the Registry - (314)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 314 (Cleartext Storage in the Registry)
The product stores sensitive information in cleartext in the registry.
* Variant Variant - 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. Cleartext Storage of Sensitive Information in a Cookie - (315)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 315 (Cleartext Storage of Sensitive Information in a Cookie)
The product stores sensitive information in cleartext in a cookie.
* Variant Variant - 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. Cleartext Storage of Sensitive Information in Memory - (316)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 316 (Cleartext Storage of Sensitive Information in Memory)
The product stores sensitive information in cleartext in memory.
* Variant Variant - 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. Cleartext Storage of Sensitive Information in GUI - (317)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 317 (Cleartext Storage of Sensitive Information in GUI)
The product stores sensitive information in cleartext within the GUI.
* Variant Variant - 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. Cleartext Storage of Sensitive Information in Executable - (318)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 318 (Cleartext Storage of Sensitive Information in Executable)
The product stores sensitive information in cleartext in an executable.
* Base Base - a 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. Cleartext Transmission of Sensitive Information - (319)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 319 (Cleartext Transmission of Sensitive Information)
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
* Base Base - a 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. Use of a Key Past its Expiration Date - (324)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 324 (Use of a Key Past its Expiration Date)
The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.
* Base Base - a 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. Missing Cryptographic Step - (325)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 325 (Missing Cryptographic Step)
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
* Class Class - a weakness that is 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. Inadequate Encryption Strength - (326)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 326 (Inadequate Encryption Strength)
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
* Class Class - a weakness that is 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. Use of a Broken or Risky Cryptographic Algorithm - (327)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 327 (Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
* Base Base - a 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. Use of Weak Hash - (328)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 328 (Use of Weak Hash)
The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
* Base Base - a 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. Improper Verification of Cryptographic Signature - (347)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 347 (Improper Verification of Cryptographic Signature)
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
* Variant Variant - 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. Sensitive Cookie in HTTPS Session Without 'Secure' Attribute - (614)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 614 (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute)
The Secure attribute for sensitive cookies in HTTPS sessions is not set, which could cause the user agent to send those cookies in plaintext over an HTTP session.
* Variant Variant - 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. Use of a One-Way Hash without a Salt - (759)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 759 (Use of a One-Way Hash without a Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input.
* Variant Variant - 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. Use of a One-Way Hash with a Predictable Salt - (760)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 760 (Use of a One-Way Hash with a Predictable Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product uses a predictable salt as part of the input.
* Variant Variant - 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. Use of RSA Algorithm without OAEP - (780)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 780 (Use of RSA Algorithm without OAEP)
The product uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
* Base Base - a 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. Use of Password Hash With Insufficient Computational Effort - (916)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 916 (Use of Password Hash With Insufficient Computational Effort)
The product generates a hash for a password, but it uses a scheme that does not provide a sufficient level of computational effort that would make password cracking attacks infeasible or expensive.
* Base Base - a 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. Use of a Cryptographic Primitive with a Risky Implementation - (1240)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 1240 (Use of a Cryptographic Primitive with a Risky Implementation)
To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.
* Base Base - a 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. Reliance on HTTP instead of HTTPS - (1428)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1402 (Comprehensive Categorization: Encryption) > 1428 (Reliance on HTTP instead of HTTPS)
The product provides or relies on use of HTTP communications when HTTPS is available.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Exposed Resource - (1403)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource)
Weaknesses in this category are related to exposed resource.
* Variant Variant - 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. J2EE Misconfiguration: Entity Bean Declared Remote - (8)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 8 (J2EE Misconfiguration: Entity Bean Declared Remote)
When an application exposes a remote interface for an entity bean, it might also expose methods that get or set the bean's data. These methods could be leveraged to read sensitive information, or to change data in ways that violate the application's expectations, potentially leading to other vulnerabilities.
* Base Base - a 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. External Control of System or Configuration Setting - (15)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 15 (External Control of System or Configuration Setting)
One or more system settings or configuration elements can be externally controlled by a user.
* Base Base - a 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. External Control of File Name or Path - (73)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 73 (External Control of File Name or Path)
The product allows user input to control or influence paths or file names that are used in filesystem operations.
* Class Class - a weakness that is 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. Process Control - (114)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 114 (Process Control)
Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.
* Variant Variant - 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. Storage of File with Sensitive Data Under Web Root - (219)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 219 (Storage of File with Sensitive Data Under Web Root)
The product stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.
* Variant Variant - 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. Storage of File With Sensitive Data Under FTP Root - (220)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 220 (Storage of File With Sensitive Data Under FTP Root)
The product stores sensitive data under the FTP server root with insufficient access control, which might make it accessible to untrusted parties.
* Base Base - a 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. Passing Mutable Objects to an Untrusted Method - (374)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 374 (Passing Mutable Objects to an Untrusted Method)
The product sends non-cloned mutable data as an argument to a method or function.
* Base Base - a 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. Returning a Mutable Object to an Untrusted Caller - (375)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 375 (Returning a Mutable Object to an Untrusted Caller)
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
* Class Class - a weakness that is 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. Insecure Temporary File - (377)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 377 (Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
* Base Base - a 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. Creation of Temporary File With Insecure Permissions - (378)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 378 (Creation of Temporary File With Insecure Permissions)
Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.
* Base Base - a 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. Creation of Temporary File in Directory with Insecure Permissions - (379)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 379 (Creation of Temporary File in Directory with Insecure Permissions)
The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.
* Class Class - a weakness that is 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. Transmission of Private Resources into a New Sphere ('Resource Leak') - (402)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 402 (Transmission of Private Resources into a New Sphere ('Resource Leak'))
The product makes resources available to untrusted parties when those resources are only intended to be accessed by the product. Resource Leak
* Base Base - a 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. Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak') - (403)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 403 (Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak'))
A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors. File descriptor leak
* Base Base - a 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. Untrusted Search Path - (426)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 426 (Untrusted Search Path)
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control. Untrusted Path
* Base Base - a 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. Uncontrolled Search Path Element - (427)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 427 (Uncontrolled Search Path Element)
The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors. DLL preloading Binary planting Insecure library loading Dependency confusion
* Base Base - a 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. Unquoted Search Path or Element - (428)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 428 (Unquoted Search Path or Element)
The product uses a search path that contains an unquoted element, in which the element contains whitespace or other separators. This can cause the product to access resources in a parent path.
* Variant Variant - 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. Unparsed Raw Web Content Delivery - (433)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 433 (Unparsed Raw Web Content Delivery)
The product stores raw content or supporting code under the web document root with an extension that is not specifically handled by the server.
* Base Base - a 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. External Control of Assumed-Immutable Web Parameter - (472)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 472 (External Control of Assumed-Immutable Web Parameter)
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields. Assumed-Immutable Parameter Tampering
* Base Base - a 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. Exposure of Data Element to Wrong Session - (488)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 488 (Exposure of Data Element to Wrong Session)
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
* Variant Variant - 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. Public cloneable() Method Without Final ('Object Hijack') - (491)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 491 (Public cloneable() Method Without Final ('Object Hijack'))
A class has a cloneable() method that is not declared final, which allows an object to be created without calling the constructor. This can cause the object to be in an unexpected state.
* Variant Variant - 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. Use of Inner Class Containing Sensitive Data - (492)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 492 (Use of Inner Class Containing Sensitive Data)
Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.
* Variant Variant - 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. Critical Public Variable Without Final Modifier - (493)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 493 (Critical Public Variable Without Final Modifier)
The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.
* Variant Variant - 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. Cloneable Class Containing Sensitive Information - (498)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 498 (Cloneable Class Containing Sensitive Information)
The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.
* Variant Variant - 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. Serializable Class Containing Sensitive Data - (499)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 499 (Serializable Class Containing Sensitive Data)
The code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class.
* Variant Variant - 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. Public Static Field Not Marked Final - (500)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 500 (Public Static Field Not Marked Final)
An object contains a public static field that is not marked final, which might allow it to be modified in unexpected ways.
* Base Base - a 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. Use of Cache Containing Sensitive Information - (524)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 524 (Use of Cache Containing Sensitive Information)
The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.
* Variant Variant - 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. Use of Web Browser Cache Containing Sensitive Information - (525)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 525 (Use of Web Browser Cache Containing Sensitive Information)
The web application does not use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached.
* Variant Variant - 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. Exposure of Version-Control Repository to an Unauthorized Control Sphere - (527)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 527 (Exposure of Version-Control Repository to an Unauthorized Control Sphere)
The product stores a CVS, git, or other repository in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
* Variant Variant - 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. Exposure of Core Dump File to an Unauthorized Control Sphere - (528)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 528 (Exposure of Core Dump File to an Unauthorized Control Sphere)
The product generates a core dump file in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
* Variant Variant - 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. Exposure of Access Control List Files to an Unauthorized Control Sphere - (529)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 529 (Exposure of Access Control List Files to an Unauthorized Control Sphere)
The product stores access control list files in a directory or other container that is accessible to actors outside of the intended control sphere.
* Variant Variant - 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. Exposure of Backup File to an Unauthorized Control Sphere - (530)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 530 (Exposure of Backup File to an Unauthorized Control Sphere)
A backup file is stored in a directory or archive that is made accessible to unauthorized actors.
* Variant Variant - 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. Use of Persistent Cookies Containing Sensitive Information - (539)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 539 (Use of Persistent Cookies Containing Sensitive Information)
The web application uses persistent cookies, but the cookies contain sensitive information.
* Base Base - a 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. Files or Directories Accessible to External Parties - (552)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 552 (Files or Directories Accessible to External Parties)
The product makes files or directories accessible to unauthorized actors, even though they should not be.
* Variant Variant - 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. Command Shell in Externally Accessible Directory - (553)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 553 (Command Shell in Externally Accessible Directory)
A possible shell file exists in /cgi-bin/ or other accessible directories. This is extremely dangerous and can be used by an attacker to execute commands on the web server.
* Base Base - a 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. Reliance on Cookies without Validation and Integrity Checking - (565)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 565 (Reliance on Cookies without Validation and Integrity Checking)
The product relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.
* Variant Variant - 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. Array Declared Public, Final, and Static - (582)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 582 (Array Declared Public, Final, and Static)
The product declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.
* Variant Variant - 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. finalize() Method Declared Public - (583)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 583 (finalize() Method Declared Public)
The product violates secure coding principles for mobile code by declaring a finalize() method public.
* Variant Variant - 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. Struts: Non-private Field in ActionForm Class - (608)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 608 (Struts: Non-private Field in ActionForm Class)
An ActionForm class contains a field that has not been declared private, which can be accessed without using a setter or getter.
* Base Base - a 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. Dangling Database Cursor ('Cursor Injection') - (619)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 619 (Dangling Database Cursor ('Cursor Injection'))
If a database cursor is not closed properly, then it could become accessible to other users while retaining the same privileges that were originally assigned, leaving the cursor "dangling."
* Class Class - a weakness that is 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. External Control of Critical State Data - (642)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 642 (External Control of Critical State Data)
The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.
* Class Class - a weakness that is 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. Exposure of Resource to Wrong Sphere - (668)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 668 (Exposure of Resource to Wrong Sphere)
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
* Base Base - a 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. Access to Critical Private Variable via Public Method - (767)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 767 (Access to Critical Private Variable via Public Method)
The product defines a public method that reads or modifies a private variable.
* Variant Variant - 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. Reliance on Cookies without Validation and Integrity Checking in a Security Decision - (784)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 784 (Reliance on Cookies without Validation and Integrity Checking in a Security Decision)
The product uses a protection mechanism that relies on the existence or values of a cookie, but it does not properly ensure that the cookie is valid for the associated user.
* Base Base - a 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. Assumed-Immutable Data is Stored in Writable Memory - (1282)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 1282 (Assumed-Immutable Data is Stored in Writable Memory)
Immutable data, such as a first-stage bootloader, device identifiers, and "write-once" configuration settings are stored in writable memory that can be re-programmed or updated in the field.
* Base Base - a 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. Binding to an Unrestricted IP Address - (1327)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1403 (Comprehensive Categorization: Exposed Resource) > 1327 (Binding to an Unrestricted IP Address)
The product assigns the address 0.0.0.0 for a database server, a cloud service/instance, or any computing resource that communicates remotely.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: File Handling - (1404)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling)
Weaknesses in this category are related to file handling.
* Base Base - a 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. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Directory traversal Path traversal
* Base Base - a 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. Relative Path Traversal - (23)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 23 (Relative Path Traversal)
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory. Zip Slip
* Variant Variant - 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. Path Traversal: '../filedir' - (24)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 24 (Path Traversal: '../filedir')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "../" sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '/../filedir' - (25)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 25 (Path Traversal: '/../filedir')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "/../" sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '/dir/../filename' - (26)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 26 (Path Traversal: '/dir/../filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "/dir/../filename" sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: 'dir/../../filename' - (27)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 27 (Path Traversal: 'dir/../../filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize multiple internal "../" sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '..\filedir' - (28)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 28 (Path Traversal: '..\filedir')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "..\" sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '\..\filename' - (29)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 29 (Path Traversal: '\..\filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '\dir\..\filename' - (30)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 30 (Path Traversal: '\dir\..\filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\dir\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: 'dir\..\..\filename' - (31)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 31 (Path Traversal: 'dir\..\..\filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize 'dir\..\..\filename' (multiple internal backslash dot dot) sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '...' (Triple Dot) - (32)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 32 (Path Traversal: '...' (Triple Dot))
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '...' (triple dot) sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '....' (Multiple Dot) - (33)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 33 (Path Traversal: '....' (Multiple Dot))
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '....' (multiple dot) sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '....//' - (34)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 34 (Path Traversal: '....//')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '....//' (doubled dot dot slash) sequences that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '.../...//' - (35)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 35 (Path Traversal: '.../...//')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '.../...//' (doubled triple dot slash) sequences that can resolve to a location that is outside of that directory.
* Base Base - a 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. Absolute Path Traversal - (36)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 36 (Absolute Path Traversal)
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory.
* Variant Variant - 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. Path Traversal: '/absolute/pathname/here' - (37)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 37 (Path Traversal: '/absolute/pathname/here')
The product accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Traversal: '\absolute\pathname\here' - (38)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 38 (Path Traversal: '\absolute\pathname\here')
The product accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Traversal: 'C:dirname' - (39)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 39 (Path Traversal: 'C:dirname')
The product accepts input that contains a drive letter or Windows volume letter ('C:dirname') that potentially redirects access to an unintended location or arbitrary file.
* Variant Variant - 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. Path Traversal: '\\UNC\share\name\' (Windows UNC Share) - (40)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 40 (Path Traversal: '\\UNC\share\name\' (Windows UNC Share))
The product accepts input that identifies a Windows UNC share ('\\UNC\share\name') that potentially redirects access to an unintended location or arbitrary file.
* Base Base - a 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. Improper Resolution of Path Equivalence - (41)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 41 (Improper Resolution of Path Equivalence)
The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.
* Variant Variant - 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. Path Equivalence: 'filename.' (Trailing Dot) - (42)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 42 (Path Equivalence: 'filename.' (Trailing Dot))
The product accepts path input in the form of trailing dot ('filedir.') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'filename....' (Multiple Trailing Dot) - (43)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 43 (Path Equivalence: 'filename....' (Multiple Trailing Dot))
The product accepts path input in the form of multiple trailing dot ('filedir....') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'file.name' (Internal Dot) - (44)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 44 (Path Equivalence: 'file.name' (Internal Dot))
The product accepts path input in the form of internal dot ('file.ordir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'file...name' (Multiple Internal Dot) - (45)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 45 (Path Equivalence: 'file...name' (Multiple Internal Dot))
The product accepts path input in the form of multiple internal dot ('file...dir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'filename ' (Trailing Space) - (46)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 46 (Path Equivalence: 'filename ' (Trailing Space))
The product accepts path input in the form of trailing space ('filedir ') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: ' filename' (Leading Space) - (47)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 47 (Path Equivalence: ' filename' (Leading Space))
The product accepts path input in the form of leading space (' filedir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'file name' (Internal Whitespace) - (48)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 48 (Path Equivalence: 'file name' (Internal Whitespace))
The product accepts path input in the form of internal space ('file(SPACE)name') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'filename/' (Trailing Slash) - (49)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 49 (Path Equivalence: 'filename/' (Trailing Slash))
The product accepts path input in the form of trailing slash ('filedir/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: '//multiple/leading/slash' - (50)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 50 (Path Equivalence: '//multiple/leading/slash')
The product accepts path input in the form of multiple leading slash ('//multiple/leading/slash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: '/multiple//internal/slash' - (51)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 51 (Path Equivalence: '/multiple//internal/slash')
The product accepts path input in the form of multiple internal slash ('/multiple//internal/slash/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: '/multiple/trailing/slash//' - (52)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 52 (Path Equivalence: '/multiple/trailing/slash//')
The product accepts path input in the form of multiple trailing slash ('/multiple/trailing/slash//') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: '\multiple\\internal\backslash' - (53)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 53 (Path Equivalence: '\multiple\\internal\backslash')
The product accepts path input in the form of multiple internal backslash ('\multiple\trailing\\slash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'filedir\' (Trailing Backslash) - (54)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 54 (Path Equivalence: 'filedir\' (Trailing Backslash))
The product accepts path input in the form of trailing backslash ('filedir\') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: '/./' (Single Dot Directory) - (55)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 55 (Path Equivalence: '/./' (Single Dot Directory))
The product accepts path input in the form of single dot directory exploit ('/./') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'filedir*' (Wildcard) - (56)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 56 (Path Equivalence: 'filedir*' (Wildcard))
The product accepts path input in the form of asterisk wildcard ('filedir*') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
* Variant Variant - 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. Path Equivalence: 'fakedir/../realdir/filename' - (57)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 57 (Path Equivalence: 'fakedir/../realdir/filename')
The product contains protection mechanisms to restrict access to 'realdir/filename', but it constructs pathnames using external input in the form of 'fakedir/../realdir/filename' that are not handled by those mechanisms. This allows attackers to perform unauthorized actions against the targeted file.
* Variant Variant - 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. Path Equivalence: Windows 8.3 Filename - (58)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 58 (Path Equivalence: Windows 8.3 Filename)
The product contains a protection mechanism that restricts access to a long filename on a Windows operating system, but it does not properly restrict access to the equivalent short "8.3" filename.
* Base Base - a 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. Improper Link Resolution Before File Access ('Link Following') - (59)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 59 (Improper Link Resolution Before File Access ('Link Following'))
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource. insecure temporary file Zip Slip
* Composite Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability. UNIX Symbolic Link (Symlink) Following - (61)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 61 (UNIX Symbolic Link (Symlink) Following)
The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files. Symlink following symlink vulnerability
* Variant Variant - 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. UNIX Hard Link - (62)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 62 (UNIX Hard Link)
The product, when opening a file or directory, does not sufficiently account for when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
* Variant Variant - 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. Windows Shortcut Following (.LNK) - (64)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 64 (Windows Shortcut Following (.LNK))
The product, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files. Windows symbolic link following symlink
* Variant Variant - 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. Windows Hard Link - (65)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 65 (Windows Hard Link)
The product, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
* Base Base - a 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. Improper Handling of File Names that Identify Virtual Resources - (66)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 66 (Improper Handling of File Names that Identify Virtual Resources)
The product does not handle or incorrectly handles a file name that identifies a "virtual" resource that is not directly specified within the directory that is associated with the file name, causing the product to perform file-based operations on a resource that is not a file.
* Variant Variant - 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. Improper Handling of Windows Device Names - (67)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 67 (Improper Handling of Windows Device Names)
The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
* Variant Variant - 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. Improper Handling of Windows ::DATA Alternate Data Stream - (69)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 69 (Improper Handling of Windows ::DATA Alternate Data Stream)
The product does not properly prevent access to, or detect usage of, alternate data streams (ADS).
* Variant Variant - 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. Improper Handling of Apple HFS+ Alternate Data Stream Path - (72)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1404 (Comprehensive Categorization: File Handling) > 72 (Improper Handling of Apple HFS+ Alternate Data Stream Path)
The product does not properly handle special paths that may identify the data or resource fork of a file on the HFS+ file system.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions - (1405)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions)
Weaknesses in this category are related to improper check or handling of exceptional conditions.
* Variant Variant - 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. J2EE Misconfiguration: Missing Custom Error Page - (7)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 7 (J2EE Misconfiguration: Missing Custom Error Page)
The default error page of a web application should not display sensitive information about the product.
* Variant Variant - 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. ASP.NET Misconfiguration: Missing Custom Error Page - (12)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 12 (ASP.NET Misconfiguration: Missing Custom Error Page)
An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses.
* Base Base - a 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. Unchecked Return Value - (252)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 252 (Unchecked Return Value)
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
* Base Base - a 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. Detection of Error Condition Without Action - (390)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 390 (Detection of Error Condition Without Action)
The product detects a specific error, but takes no actions to handle the error.
* Base Base - a 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. Unchecked Error Condition - (391)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 391 (Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
* Base Base - a 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. Unexpected Status Code or Return Value - (394)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 394 (Unexpected Status Code or Return Value)
The product does not properly check when a function or operation returns a value that is legitimate for the function, but is not expected by the product.
* Base Base - a 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. Missing Standardized Error Handling Mechanism - (544)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 544 (Missing Standardized Error Handling Mechanism)
The product does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.
* Pillar Pillar - a weakness that 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. Improper Check or Handling of Exceptional Conditions - (703)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 703 (Improper Check or Handling of Exceptional Conditions)
The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
* Class Class - a weakness that is 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. Improper Check for Unusual or Exceptional Conditions - (754)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 754 (Improper Check for Unusual or Exceptional Conditions)
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
* Class Class - a weakness that is 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. Improper Handling of Exceptional Conditions - (755)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 755 (Improper Handling of Exceptional Conditions)
The product does not handle or incorrectly handles an exceptional condition.
* Base Base - a 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. Missing Custom Error Page - (756)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 756 (Missing Custom Error Page)
The product does not return custom error pages to the user, possibly exposing sensitive information.
* Base Base - a 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. Improper Protection Against Voltage and Clock Glitches - (1247)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 1247 (Improper Protection Against Voltage and Clock Glitches)
The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.
* Base Base - a 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. Improper Handling of Single Event Upsets - (1261)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 1261 (Improper Handling of Single Event Upsets)
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.
* Base Base - a 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. Improper Handling of Faults that Lead to Instruction Skips - (1332)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 1332 (Improper Handling of Faults that Lead to Instruction Skips)
The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.
* Base Base - a 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. Improper Handling of Hardware Behavior in Exceptionally Cold Environments - (1351)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 1351 (Improper Handling of Hardware Behavior in Exceptionally Cold Environments)
A hardware device, or the firmware running on it, is missing or has incorrect protection features to maintain goals of security primitives when the device is cooled below standard operating temperatures.
* Class Class - a weakness that is 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. Improper Handling of Physical or Environmental Conditions - (1384)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1405 (Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions) > 1384 (Improper Handling of Physical or Environmental Conditions)
The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Improper Input Validation - (1406)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation)
Weaknesses in this category are related to improper input validation.
* Class Class - a weakness that is 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. Improper Input Validation - (20)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 20 (Improper Input Validation)
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
* Variant Variant - 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. Struts: Form Field Without Validator - (105)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 105 (Struts: Form Field Without Validator)
The product has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation.
* Variant Variant - 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. Struts: Plug-in Framework not in Use - (106)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 106 (Struts: Plug-in Framework not in Use)
When an application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation.
* Variant Variant - 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. Struts: Unvalidated Action Form - (108)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 108 (Struts: Unvalidated Action Form)
Every Action Form must have a corresponding validation form.
* Variant Variant - 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. Struts: Validator Turned Off - (109)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 109 (Struts: Validator Turned Off)
Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation.
* Base Base - a 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. Missing XML Validation - (112)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 112 (Missing XML Validation)
The product accepts XML from an untrusted source but does not validate the XML against the proper schema.
* Variant Variant - 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. ASP.NET Misconfiguration: Not Using Input Validation Framework - (554)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 554 (ASP.NET Misconfiguration: Not Using Input Validation Framework)
The ASP.NET application does not use an input validation framework.
* Base Base - a 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. Unchecked Input for Loop Condition - (606)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 606 (Unchecked Input for Loop Condition)
The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.
* Variant Variant - 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. Improper Validation of Function Hook Arguments - (622)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 622 (Improper Validation of Function Hook Arguments)
The product adds hooks to user-accessible API functions, but it does not properly validate the arguments. This could lead to resultant vulnerabilities.
* Variant Variant - 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. Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code - (781)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 781 (Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code)
The product defines an IOCTL that uses METHOD_NEITHER for I/O, but it does not validate or incorrectly validates the addresses that are provided.
* Base Base - a 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. Improper Use of Validation Framework - (1173)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 1173 (Improper Use of Validation Framework)
The product does not use, or incorrectly uses, an input validation framework that is provided by the source language or an independent library.
* Variant Variant - 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. ASP.NET Misconfiguration: Improper Model Validation - (1174)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 1174 (ASP.NET Misconfiguration: Improper Model Validation)
The ASP.NET application does not use, or incorrectly uses, the model validation framework.
* Base Base - a 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. Improper Validation of Specified Quantity in Input - (1284)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 1284 (Improper Validation of Specified Quantity in Input)
The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.
* Base Base - a 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. Improper Validation of Specified Index, Position, or Offset in Input - (1285)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 1285 (Improper Validation of Specified Index, Position, or Offset in Input)
The product receives input that is expected to specify an index, position, or offset into an indexable resource such as a buffer or file, but it does not validate or incorrectly validates that the specified index/position/offset has the required properties.
* Base Base - a 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. Improper Validation of Syntactic Correctness of Input - (1286)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 1286 (Improper Validation of Syntactic Correctness of Input)
The product receives input that is expected to be well-formed - i.e., to comply with a certain syntax - but it does not validate or incorrectly validates that the input complies with the syntax.
* Base Base - a 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. Improper Validation of Specified Type of Input - (1287)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 1287 (Improper Validation of Specified Type of Input)
The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.
* Base Base - a 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. Improper Validation of Consistency within Input - (1288)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 1288 (Improper Validation of Consistency within Input)
The product receives a complex input with multiple elements or fields that must be consistent with each other, but it does not validate or incorrectly validates that the input is actually consistent.
* Base Base - a 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. Improper Validation of Unsafe Equivalence in Input - (1289)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1406 (Comprehensive Categorization: Improper Input Validation) > 1289 (Improper Validation of Unsafe Equivalence in Input)
The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Improper Neutralization - (1407)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization)
Weaknesses in this category are related to improper neutralization.
* Class Class - a weakness that is 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. Improper Encoding or Escaping of Output - (116)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 116 (Improper Encoding or Escaping of Output)
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved. Output Sanitization Output Validation Output Encoding
* Base Base - a 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. Improper Output Neutralization for Logs - (117)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 117 (Improper Output Neutralization for Logs)
The product constructs a log message from external input, but it does not neutralize or incorrectly neutralizes special elements when the message is written to a log file. Log forging
* Base Base - a 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. Improper Handling of Length Parameter Inconsistency - (130)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 130 (Improper Handling of Length Parameter Inconsistency)
The product parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data. length manipulation length tampering
* Class Class - a weakness that is 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. Improper Neutralization of Special Elements - (138)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 138 (Improper Neutralization of Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.
* Base Base - a 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. Improper Neutralization of Delimiters - (140)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 140 (Improper Neutralization of Delimiters)
The product does not neutralize or incorrectly neutralizes delimiters.
* Variant Variant - 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. Improper Neutralization of Parameter/Argument Delimiters - (141)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 141 (Improper Neutralization of Parameter/Argument Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as parameter or argument delimiters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Value Delimiters - (142)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 142 (Improper Neutralization of Value Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as value delimiters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Record Delimiters - (143)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 143 (Improper Neutralization of Record Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as record delimiters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Line Delimiters - (144)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 144 (Improper Neutralization of Line Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Section Delimiters - (145)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 145 (Improper Neutralization of Section Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as section delimiters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Expression/Command Delimiters - (146)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 146 (Improper Neutralization of Expression/Command Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as expression or command delimiters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Input Terminators - (147)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 147 (Improper Neutralization of Input Terminators)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as input terminators when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Input Leaders - (148)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 148 (Improper Neutralization of Input Leaders)
The product does not properly handle when a leading character or sequence ("leader") is missing or malformed, or if multiple leaders are used when only one should be allowed.
* Variant Variant - 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. Improper Neutralization of Quoting Syntax - (149)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 149 (Improper Neutralization of Quoting Syntax)
Quotes injected into a product can be used to compromise a system. As data are parsed, an injected/absent/duplicate/malformed use of quotes may cause the process to take unexpected actions.
* Variant Variant - 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. Improper Neutralization of Escape, Meta, or Control Sequences - (150)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 150 (Improper Neutralization of Escape, Meta, or Control Sequences)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Comment Delimiters - (151)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 151 (Improper Neutralization of Comment Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as comment delimiters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Macro Symbols - (152)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 152 (Improper Neutralization of Macro Symbols)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as macro symbols when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Substitution Characters - (153)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 153 (Improper Neutralization of Substitution Characters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as substitution characters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Variable Name Delimiters - (154)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 154 (Improper Neutralization of Variable Name Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as variable name delimiters when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Wildcards or Matching Symbols - (155)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 155 (Improper Neutralization of Wildcards or Matching Symbols)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as wildcards or matching symbols when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Whitespace - (156)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 156 (Improper Neutralization of Whitespace)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as whitespace when they are sent to a downstream component. White space
* Variant Variant - 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. Failure to Sanitize Paired Delimiters - (157)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 157 (Failure to Sanitize Paired Delimiters)
The product does not properly handle the characters that are used to mark the beginning and ending of a group of entities, such as parentheses, brackets, and braces.
* Variant Variant - 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. Improper Neutralization of Null Byte or NUL Character - (158)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 158 (Improper Neutralization of Null Byte or NUL Character)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes NUL characters or null bytes when they are sent to a downstream component.
* Class Class - a weakness that is 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. Improper Handling of Invalid Use of Special Elements - (159)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 159 (Improper Handling of Invalid Use of Special Elements)
The product does not properly filter, remove, quote, or otherwise manage the invalid use of special elements in user-controlled input, which could cause adverse effect on its behavior and integrity.
* Variant Variant - 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. Improper Neutralization of Leading Special Elements - (160)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 160 (Improper Neutralization of Leading Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Multiple Leading Special Elements - (161)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 161 (Improper Neutralization of Multiple Leading Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Trailing Special Elements - (162)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 162 (Improper Neutralization of Trailing Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Multiple Trailing Special Elements - (163)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 163 (Improper Neutralization of Multiple Trailing Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Internal Special Elements - (164)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 164 (Improper Neutralization of Internal Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes internal special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
* Variant Variant - 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. Improper Neutralization of Multiple Internal Special Elements - (165)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 165 (Improper Neutralization of Multiple Internal Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple internal special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
* Base Base - a 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. Improper Handling of Missing Special Element - (166)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 166 (Improper Handling of Missing Special Element)
The product receives input from an upstream component, but it does not handle or incorrectly handles when an expected special element is missing.
* Base Base - a 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. Improper Handling of Additional Special Element - (167)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 167 (Improper Handling of Additional Special Element)
The product receives input from an upstream component, but it does not handle or incorrectly handles when an additional unexpected special element is provided.
* Base Base - a 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. Improper Handling of Inconsistent Special Elements - (168)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 168 (Improper Handling of Inconsistent Special Elements)
The product does not properly handle input in which an inconsistency exists between two or more special characters or reserved words.
* Base Base - a 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. Improper Null Termination - (170)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 170 (Improper Null Termination)
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
* Class Class - a weakness that is 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. Encoding Error - (172)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 172 (Encoding Error)
The product does not properly encode or decode the data, resulting in unexpected values.
* Variant Variant - 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. Improper Handling of Alternate Encoding - (173)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 173 (Improper Handling of Alternate Encoding)
The product does not properly handle when an input uses an alternate encoding that is valid for the control sphere to which the input is being sent.
* Variant Variant - 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. Double Decoding of the Same Data - (174)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 174 (Double Decoding of the Same Data)
The product decodes the same input twice, which can limit the effectiveness of any protection mechanism that occurs in between the decoding operations.
* Variant Variant - 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. Improper Handling of Mixed Encoding - (175)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 175 (Improper Handling of Mixed Encoding)
The product does not properly handle when the same input uses several different (mixed) encodings.
* Variant Variant - 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. Improper Handling of Unicode Encoding - (176)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 176 (Improper Handling of Unicode Encoding)
The product does not properly handle when an input contains Unicode encoding.
* Variant Variant - 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. Improper Handling of URL Encoding (Hex Encoding) - (177)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 177 (Improper Handling of URL Encoding (Hex Encoding))
The product does not properly handle when all or part of an input has been URL encoded.
* Class Class - a weakness that is 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. Improper Handling of Syntactically Invalid Structure - (228)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 228 (Improper Handling of Syntactically Invalid Structure)
The product does not handle or incorrectly handles input that is not syntactically well-formed with respect to the associated specification.
* Base Base - a 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. Improper Handling of Values - (229)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 229 (Improper Handling of Values)
The product does not properly handle when the expected number of values for parameters, fields, or arguments is not provided in input, or if those values are undefined.
* Variant Variant - 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. Improper Handling of Missing Values - (230)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 230 (Improper Handling of Missing Values)
The product does not handle or incorrectly handles when a parameter, field, or argument name is specified, but the associated value is missing, i.e. it is empty, blank, or null.
* Variant Variant - 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. Improper Handling of Extra Values - (231)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 231 (Improper Handling of Extra Values)
The product does not handle or incorrectly handles when more values are provided than expected.
* Variant Variant - 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. Improper Handling of Undefined Values - (232)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 232 (Improper Handling of Undefined Values)
The product does not handle or incorrectly handles when a value is not defined or supported for the associated parameter, field, or argument name.
* Base Base - a 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. Improper Handling of Parameters - (233)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 233 (Improper Handling of Parameters)
The product does not properly handle when the expected number of parameters, fields, or arguments is not provided in input, or if those parameters are undefined.
* Variant Variant - 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. Failure to Handle Missing Parameter - (234)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 234 (Failure to Handle Missing Parameter)
If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. Potentially, a variable number of arguments could be exhausted in a function as well.
* Variant Variant - 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. Improper Handling of Extra Parameters - (235)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 235 (Improper Handling of Extra Parameters)
The product does not handle or incorrectly handles when the number of parameters, fields, or arguments with the same name exceeds the expected amount.
* Variant Variant - 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. Improper Handling of Undefined Parameters - (236)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 236 (Improper Handling of Undefined Parameters)
The product does not handle or incorrectly handles when a particular parameter, field, or argument name is not defined or supported by the product.
* Base Base - a 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. Improper Handling of Structural Elements - (237)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 237 (Improper Handling of Structural Elements)
The product does not handle or incorrectly handles inputs that are related to complex structures.
* Variant Variant - 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. Improper Handling of Incomplete Structural Elements - (238)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 238 (Improper Handling of Incomplete Structural Elements)
The product does not handle or incorrectly handles when a particular structural element is not completely specified.
* Variant Variant - 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. Failure to Handle Incomplete Element - (239)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 239 (Failure to Handle Incomplete Element)
The product does not properly handle when a particular element is not completely specified.
* Base Base - a 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. Improper Handling of Inconsistent Structural Elements - (240)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 240 (Improper Handling of Inconsistent Structural Elements)
The product does not handle or incorrectly handles when two or more structural elements should be consistent, but are not.
* Base Base - a 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. Improper Handling of Unexpected Data Type - (241)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 241 (Improper Handling of Unexpected Data Type)
The product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).
* Base Base - a 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. Deletion of Data Structure Sentinel - (463)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 463 (Deletion of Data Structure Sentinel)
The accidental deletion of a data-structure sentinel can cause serious programming logic problems.
* Base Base - a 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. Addition of Data Structure Sentinel - (464)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 464 (Addition of Data Structure Sentinel)
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
* Variant Variant - 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. Null Byte Interaction Error (Poison Null Byte) - (626)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 626 (Null Byte Interaction Error (Poison Null Byte))
The product does not properly handle null bytes or NUL characters when passing data between different representations or components.
* Variant Variant - 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. Improper Neutralization of HTTP Headers for Scripting Syntax - (644)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 644 (Improper Neutralization of HTTP Headers for Scripting Syntax)
The product does not neutralize or incorrectly neutralizes web scripting syntax in HTTP headers that can be used by web browser components that can process raw headers, such as Flash.
* Pillar Pillar - a weakness that 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. Improper Neutralization - (707)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 707 (Improper Neutralization)
The product does not ensure or incorrectly ensures that structured messages or data are well-formed and that certain security properties are met before being read from an upstream component or sent to a downstream component.
* Class Class - a weakness that is 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. Improper Filtering of Special Elements - (790)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 790 (Improper Filtering of Special Elements)
The product receives data from an upstream component, but does not filter or incorrectly filters special elements before sending it to a downstream component.
* Base Base - a 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. Incomplete Filtering of Special Elements - (791)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 791 (Incomplete Filtering of Special Elements)
The product receives data from an upstream component, but does not completely filter special elements before sending it to a downstream component.
* Variant Variant - 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. Incomplete Filtering of One or More Instances of Special Elements - (792)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 792 (Incomplete Filtering of One or More Instances of Special Elements)
The product receives data from an upstream component, but does not completely filter one or more instances of special elements before sending it to a downstream component.
* Variant Variant - 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. Only Filtering One Instance of a Special Element - (793)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 793 (Only Filtering One Instance of a Special Element)
The product receives data from an upstream component, but only filters a single instance of a special element before sending it to a downstream component.
* Variant Variant - 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. Incomplete Filtering of Multiple Instances of Special Elements - (794)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 794 (Incomplete Filtering of Multiple Instances of Special Elements)
The product receives data from an upstream component, but does not filter all instances of a special element before sending it to a downstream component.
* Base Base - a 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. Only Filtering Special Elements at a Specified Location - (795)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 795 (Only Filtering Special Elements at a Specified Location)
The product receives data from an upstream component, but only accounts for special elements at a specified location, thereby missing remaining special elements that may exist before sending it to a downstream component.
* Variant Variant - 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. Only Filtering Special Elements Relative to a Marker - (796)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 796 (Only Filtering Special Elements Relative to a Marker)
The product receives data from an upstream component, but only accounts for special elements positioned relative to a marker (e.g. "at the beginning/end of a string; the second argument"), thereby missing remaining special elements that may exist before sending it to a downstream component.
* Variant Variant - 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. Only Filtering Special Elements at an Absolute Position - (797)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 797 (Only Filtering Special Elements at an Absolute Position)
The product receives data from an upstream component, but only accounts for special elements at an absolute position (e.g. "byte number 10"), thereby missing remaining special elements that may exist before sending it to a downstream component.
* Base Base - a 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. Inappropriate Encoding for Output Context - (838)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1407 (Comprehensive Categorization: Improper Neutralization) > 838 (Inappropriate Encoding for Output Context)
The product uses or specifies an encoding when generating output to a downstream component, but the specified encoding is not the same as the encoding that is expected by the downstream component.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Incorrect Calculation - (1408)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation)
Weaknesses in this category are related to incorrect calculation.
* Base Base - a 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. Wrap-around Error - (128)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 128 (Wrap-around Error)
Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.
* Base Base - a 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. Incorrect Calculation of Multi-Byte String Length - (135)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 135 (Incorrect Calculation of Multi-Byte String Length)
The product does not correctly calculate the length of strings that can contain wide or multi-byte characters.
* Base Base - a 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. Integer Overflow or Wraparound - (190)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 190 (Integer Overflow or Wraparound)
The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number. Overflow Wraparound wrap, wrap-around, wrap around
* Base Base - a 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. Integer Underflow (Wrap or Wraparound) - (191)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 191 (Integer Underflow (Wrap or Wraparound))
The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result. Integer underflow
* Base Base - a 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. Off-by-one Error - (193)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 193 (Off-by-one Error)
A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value. off-by-five
* Base Base - a 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. Divide By Zero - (369)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 369 (Divide By Zero)
The product divides a value by zero.
* Variant Variant - 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. Use of sizeof() on a Pointer Type - (467)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 467 (Use of sizeof() on a Pointer Type)
The code calls sizeof() on a pointer type, which can be an incorrect calculation if the programmer intended to determine the size of the data that is being pointed to.
* Base Base - a 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. Incorrect Pointer Scaling - (468)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 468 (Incorrect Pointer Scaling)
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
* Base Base - a 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. Use of Pointer Subtraction to Determine Size - (469)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 469 (Use of Pointer Subtraction to Determine Size)
The product subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk.
* Pillar Pillar - a weakness that 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. Incorrect Calculation - (682)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 682 (Incorrect Calculation)
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
* Base Base - a 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. Incorrect Bitwise Shift of Integer - (1335)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 1335 (Incorrect Bitwise Shift of Integer)
An integer value is specified to be shifted by a negative amount or an amount greater than or equal to the number of bits contained in the value causing an unexpected or indeterminate result.
* Base Base - a 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. Insufficient Precision or Accuracy of a Real Number - (1339)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1408 (Comprehensive Categorization: Incorrect Calculation) > 1339 (Insufficient Precision or Accuracy of a Real Number)
The product processes a real number with an implementation in which the number's representation does not preserve required accuracy and precision in its fractional part, causing an incorrect result.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Injection - (1409)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection)
Weaknesses in this category are related to injection.
* Class Class - a weakness that is 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. Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') - (74)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'))
The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
* Class Class - a weakness that is 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. Failure to Sanitize Special Elements into a Different Plane (Special Element Injection) - (75)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 75 (Failure to Sanitize Special Elements into a Different Plane (Special Element Injection))
The product does not adequately filter user-controlled input for special elements with control implications.
* Base Base - a 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. Improper Neutralization of Equivalent Special Elements - (76)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 76 (Improper Neutralization of Equivalent Special Elements)
The product correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.
* Class Class - a weakness that is 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. Improper Neutralization of Special Elements used in a Command ('Command Injection') - (77)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection'))
The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component. Command injection
* Base Base - a 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. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Shell injection Shell metacharacters OS Command Injection
* Base Base - a 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. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. XSS HTML Injection Reflected XSS / Non-Persistent XSS / Type 1 XSS Stored XSS / Persistent XSS / Type 2 XSS DOM-Based XSS / Type 0 XSS CSS
* Variant Variant - 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. Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) - (80)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.
* Variant Variant - 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. Improper Neutralization of Script in an Error Message Web Page - (81)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 81 (Improper Neutralization of Script in an Error Message Web Page)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters that could be interpreted as web-scripting elements when they are sent to an error page.
* Variant Variant - 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. Improper Neutralization of Script in Attributes of IMG Tags in a Web Page - (82)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 82 (Improper Neutralization of Script in Attributes of IMG Tags in a Web Page)
The web application does not neutralize or incorrectly neutralizes scripting elements within attributes of HTML IMG tags, such as the src attribute.
* Variant Variant - 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. Improper Neutralization of Script in Attributes in a Web Page - (83)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 83 (Improper Neutralization of Script in Attributes in a Web Page)
The product does not neutralize or incorrectly neutralizes "javascript:" or other URIs from dangerous attributes within tags, such as onmouseover, onload, onerror, or style.
* Variant Variant - 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. Improper Neutralization of Encoded URI Schemes in a Web Page - (84)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 84 (Improper Neutralization of Encoded URI Schemes in a Web Page)
The web application improperly neutralizes user-controlled input for executable script disguised with URI encodings.
* Variant Variant - 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. Doubled Character XSS Manipulations - (85)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 85 (Doubled Character XSS Manipulations)
The web application does not filter user-controlled input for executable script disguised using doubling of the involved characters.
* Variant Variant - 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. Improper Neutralization of Invalid Characters in Identifiers in Web Pages - (86)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 86 (Improper Neutralization of Invalid Characters in Identifiers in Web Pages)
The product does not neutralize or incorrectly neutralizes invalid characters or byte sequences in the middle of tag names, URI schemes, and other identifiers.
* Variant Variant - 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. Improper Neutralization of Alternate XSS Syntax - (87)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 87 (Improper Neutralization of Alternate XSS Syntax)
The product does not neutralize or incorrectly neutralizes user-controlled input for alternate script syntax.
* Base Base - a 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. Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') - (88)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))
The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.
* Base Base - a 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. Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. SQL injection SQLi
* Base Base - a 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. Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') - (90)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 90 (Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'))
The product constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.
* Base Base - a 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. XML Injection (aka Blind XPath Injection) - (91)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 91 (XML Injection (aka Blind XPath Injection))
The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
* Base Base - a 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. Improper Neutralization of CRLF Sequences ('CRLF Injection') - (93)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 93 (Improper Neutralization of CRLF Sequences ('CRLF Injection'))
The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
* Base Base - a 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. Improper Control of Generation of Code ('Code Injection') - (94)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 94 (Improper Control of Generation of Code ('Code Injection'))
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment. Code Injection
* Variant Variant - 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. Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') - (95)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
* Base Base - a 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. Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') - (96)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 96 (Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection'))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.
* Variant Variant - 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. Improper Neutralization of Server-Side Includes (SSI) Within a Web Page - (97)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 97 (Improper Neutralization of Server-Side Includes (SSI) Within a Web Page)
The product generates a web page, but does not neutralize or incorrectly neutralizes user-controllable input that could be interpreted as a server-side include (SSI) directive.
* Class Class - a weakness that is 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. Improper Control of Resource Identifiers ('Resource Injection') - (99)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 99 (Improper Control of Resource Identifiers ('Resource Injection'))
The product receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control. Insecure Direct Object Reference
* Variant Variant - 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. Struts: Duplicate Validation Forms - (102)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 102 (Struts: Duplicate Validation Forms)
The product uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect.
* Variant Variant - 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. Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') - (113)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 113 (Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'))
The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers. HTTP Request Splitting HTTP Response Splitting
* Variant Variant - 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. SQL Injection: Hibernate - (564)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 564 (SQL Injection: Hibernate)
Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.
* Variant Variant - 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. Variable Extraction Error - (621)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 621 (Variable Extraction Error)
The product uses external input to determine the names of variables into which information is extracted, without verifying that the names of the specified variables are valid. This could cause the program to overwrite unintended variables. Variable overwrite
* Base Base - a 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. Executable Regular Expression Error - (624)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 624 (Executable Regular Expression Error)
The product uses a regular expression that either (1) contains an executable component with user-controlled inputs, or (2) allows a user to enable execution by inserting pattern modifiers.
* Variant Variant - 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. Dynamic Variable Evaluation - (627)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 627 (Dynamic Variable Evaluation)
In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions. Dynamic evaluation
* Base Base - a 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. Improper Restriction of Names for Files and Other Resources - (641)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 641 (Improper Restriction of Names for Files and Other Resources)
The product constructs the name of a file or other resource using input from an upstream component, but it does not restrict or incorrectly restricts the resulting name.
* Base Base - a 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. Improper Neutralization of Data within XPath Expressions ('XPath Injection') - (643)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 643 (Improper Neutralization of Data within XPath Expressions ('XPath Injection'))
The product uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
* Base Base - a 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. Improper Neutralization of Data within XQuery Expressions ('XQuery Injection') - (652)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 652 (Improper Neutralization of Data within XQuery Expressions ('XQuery Injection'))
The product uses external input to dynamically construct an XQuery expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
* Chain Chain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure. Incomplete Denylist to Cross-Site Scripting - (692)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 692 (Incomplete Denylist to Cross-Site Scripting)
The product uses a denylist-based protection mechanism to defend against XSS attacks, but the denylist is incomplete, allowing XSS variants to succeed.
* Base Base - a 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. Use of Multiple Resources with Duplicate Identifier - (694)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 694 (Use of Multiple Resources with Duplicate Identifier)
The product uses multiple resources that can have the same identifier, in a context in which unique identifiers are required.
* Base Base - a 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. Improper Control of Dynamically-Identified Variables - (914)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 914 (Improper Control of Dynamically-Identified Variables)
The product does not properly restrict reading from or writing to dynamically-identified variables.
* Base Base - a 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. Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') - (917)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 917 (Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection'))
The product constructs all or part of an expression language (EL) statement in a framework such as a Java Server Page (JSP) using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended EL statement before it is executed. EL Injection
* Class Class - a weakness that is 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. Improper Neutralization of Special Elements in Data Query Logic - (943)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 943 (Improper Neutralization of Special Elements in Data Query Logic)
The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query. NoSQL Injection, NoSQLi
* Base Base - a 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. Improper Neutralization of Formula Elements in a CSV File - (1236)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 1236 (Improper Neutralization of Formula Elements in a CSV File)
The product saves user-provided information into a Comma-Separated Value (CSV) file, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as a command when the file is opened by a spreadsheet product. CSV Injection Formula Injection Excel Macro Injection
* Base Base - a 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. Improper Neutralization of Special Elements Used in a Template Engine - (1336)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 1336 (Improper Neutralization of Special Elements Used in a Template Engine)
The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine. Server-Side Template Injection / SSTI Client-Side Template Injection / CSTI
* Base Base - a 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. Improper Validation of Generative AI Output - (1426)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 1426 (Improper Validation of Generative AI Output)
The product invokes a generative AI/ML component whose behaviors and outputs cannot be directly controlled, but the product does not validate or insufficiently validates the outputs to ensure that they align with the intended security, content, or privacy policy.
* Base Base - a 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. Improper Neutralization of Input Used for LLM Prompting - (1427)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1409 (Comprehensive Categorization: Injection) > 1427 (Improper Neutralization of Input Used for LLM Prompting)
The product uses externally-provided data to build prompts provided to large language models (LLMs), but the way these prompts are constructed causes the LLM to fail to distinguish between user-supplied inputs and developer provided system directives. prompt injection
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Insufficient Control Flow Management - (1410)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management)
Weaknesses in this category are related to insufficient control flow management.
* Base Base - a 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. Incorrect Behavior Order: Early Validation - (179)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 179 (Incorrect Behavior Order: Early Validation)
The product validates input before applying protection mechanisms that modify the input, which could allow an attacker to bypass the validation via dangerous inputs that only arise after the modification.
* Variant Variant - 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. Incorrect Behavior Order: Validate Before Canonicalize - (180)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 180 (Incorrect Behavior Order: Validate Before Canonicalize)
The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.
* Variant Variant - 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. Incorrect Behavior Order: Validate Before Filter - (181)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 181 (Incorrect Behavior Order: Validate Before Filter)
The product validates data before it has been filtered, which prevents the product from detecting data that becomes invalid after the filtering step. Validate-before-cleanse
* Base Base - a 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. Uncaught Exception - (248)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 248 (Uncaught Exception)
An exception is thrown from a function, but it is not caught.
* Variant Variant - 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. J2EE Bad Practices: Use of System.exit() - (382)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 382 (J2EE Bad Practices: Use of System.exit())
A J2EE application uses System.exit(), which also shuts down its container.
* Base Base - a 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. Use of NullPointerException Catch to Detect NULL Pointer Dereference - (395)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 395 (Use of NullPointerException Catch to Detect NULL Pointer Dereference)
Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.
* Base Base - a 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. Declaration of Catch for Generic Exception - (396)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 396 (Declaration of Catch for Generic Exception)
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
* Base Base - a 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. Declaration of Throws for Generic Exception - (397)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 397 (Declaration of Throws for Generic Exception)
The product throws or raises an overly broad exceptions that can hide important details and produce inappropriate responses to certain conditions.
* Base Base - a 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. Incorrect Behavior Order: Early Amplification - (408)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 408 (Incorrect Behavior Order: Early Amplification)
The product allows an entity to perform a legitimate but expensive operation before authentication or authorization has taken place.
* Base Base - a 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. Deployment of Wrong Handler - (430)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 430 (Deployment of Wrong Handler)
The wrong "handler" is assigned to process an object.
* Base Base - a 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. Missing Handler - (431)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 431 (Missing Handler)
A handler is not available or implemented.
* Base Base - a 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. Non-exit on Failed Initialization - (455)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 455 (Non-exit on Failed Initialization)
The product does not exit or otherwise modify its operation when security-relevant errors occur during initialization, such as when a configuration file has a format error or a hardware security module (HSM) cannot be activated, which can cause the product to execute in a less secure fashion than intended by the administrator.
* Base Base - a 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. Use of Incorrect Operator - (480)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 480 (Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
* Variant Variant - 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. Assigning instead of Comparing - (481)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 481 (Assigning instead of Comparing)
The code uses an operator for assignment when the intention was to perform a comparison.
* Variant Variant - 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. Comparing instead of Assigning - (482)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 482 (Comparing instead of Assigning)
The code uses an operator for comparison when the intention was to perform an assignment.
* Base Base - a 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. Incorrect Block Delimitation - (483)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 483 (Incorrect Block Delimitation)
The code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error.
* Base Base - a 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. Return Inside Finally Block - (584)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 584 (Return Inside Finally Block)
The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.
* Variant Variant - 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. Uncaught Exception in Servlet - (600)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 600 (Uncaught Exception in Servlet )
The Servlet does not catch all exceptions, which may reveal sensitive debugging information. Missing Catch Block
* Base Base - a 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. Reachable Assertion - (617)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 617 (Reachable Assertion)
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary. assertion failure
* Class Class - a weakness that is 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. Always-Incorrect Control Flow Implementation - (670)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 670 (Always-Incorrect Control Flow Implementation)
The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.
* Class Class - a weakness that is 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. Uncontrolled Recursion - (674)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 674 (Uncontrolled Recursion)
The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack. Stack Exhaustion
* Pillar Pillar - a weakness that 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. Insufficient Control Flow Management - (691)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 691 (Insufficient Control Flow Management)
The code does not sufficiently manage its control flow during execution, creating conditions in which the control flow can be modified in unexpected ways.
* Class Class - a weakness that is 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. Incorrect Behavior Order - (696)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 696 (Incorrect Behavior Order)
The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.
* Base Base - a 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. Execution After Redirect (EAR) - (698)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 698 (Execution After Redirect (EAR))
The web application sends a redirect to another location, but instead of exiting, it executes additional code. Redirect Without Exit
* Class Class - a weakness that is 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. Incorrect Control Flow Scoping - (705)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 705 (Incorrect Control Flow Scoping)
The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
* Variant Variant - 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. Incorrect Short Circuit Evaluation - (768)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 768 (Incorrect Short Circuit Evaluation)
The product contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.
* Base Base - a 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. Operator Precedence Logic Error - (783)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 783 (Operator Precedence Logic Error)
The product uses an expression in which operator precedence causes incorrect logic to be used.
* Class Class - a weakness that is 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. Improper Control of Interaction Frequency - (799)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 799 (Improper Control of Interaction Frequency)
The product does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. Insufficient anti-automation Brute force
* Class Class - a weakness that is 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. Excessive Iteration - (834)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 834 (Excessive Iteration)
The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed.
* Base Base - a 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. Loop with Unreachable Exit Condition ('Infinite Loop') - (835)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 835 (Loop with Unreachable Exit Condition ('Infinite Loop'))
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
* Base Base - a 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. Improper Enforcement of a Single, Unique Action - (837)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 837 (Improper Enforcement of a Single, Unique Action)
The product requires that an actor should only be able to perform an action once, or to have only one unique action, but the product does not enforce or improperly enforces this restriction.
* Base Base - a 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. Improper Enforcement of Behavioral Workflow - (841)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 841 (Improper Enforcement of Behavioral Workflow)
The product supports a session in which more than one behavior must be performed by an actor, but it does not properly ensure that the actor performs the behaviors in the required sequence.
* Base Base - a 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. DMA Device Enabled Too Early in Boot Phase - (1190)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 1190 (DMA Device Enabled Too Early in Boot Phase)
The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.
* Base Base - a 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. Power-On of Untrusted Execution Core Before Enabling Fabric Access Control - (1193)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 1193 (Power-On of Untrusted Execution Core Before Enabling Fabric Access Control)
The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.
* Base Base - a 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. Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls - (1265)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 1265 (Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls)
During execution of non-reentrant code, the product performs a call that unintentionally produces a nested invocation of the non-reentrant code.
* Base Base - a 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. Access Control Check Implemented After Asset is Accessed - (1280)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 1280 (Access Control Check Implemented After Asset is Accessed)
A product's hardware-based access control check occurs after the asset has been accessed.
* Base Base - a 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. Sequence of Processor Instructions Leads to Unexpected Behavior - (1281)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 1281 (Sequence of Processor Instructions Leads to Unexpected Behavior)
Specific combinations of processor instructions lead to undesirable behavior such as locking the processor until a hard reset performed.
* Base Base - a 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. Use of Blocking Code in Single-threaded, Non-blocking Context - (1322)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1410 (Comprehensive Categorization: Insufficient Control Flow Management) > 1322 (Use of Blocking Code in Single-threaded, Non-blocking Context)
The product uses a non-blocking model that relies on a single threaded process for features such as scalability, but it contains code that can block when it is invoked.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Insufficient Verification of Data Authenticity - (1411)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity)
Weaknesses in this category are related to insufficient verification of data authenticity.
* Class Class - a weakness that is 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. Insufficient Verification of Data Authenticity - (345)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 345 (Insufficient Verification of Data Authenticity)
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
* Class Class - a weakness that is 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. Origin Validation Error - (346)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 346 (Origin Validation Error)
The product does not properly verify that the source of data or communication is valid.
* Base Base - a 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. Use of Less Trusted Source - (348)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 348 (Use of Less Trusted Source)
The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack.
* Base Base - a 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. Acceptance of Extraneous Untrusted Data With Trusted Data - (349)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
* Base Base - a 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. Insufficient Type Distinction - (351)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 351 (Insufficient Type Distinction)
The product does not properly distinguish between different types of elements in a way that leads to insecure behavior.
* Composite Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability. Cross-Site Request Forgery (CSRF) - (352)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 352 (Cross-Site Request Forgery (CSRF))
The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor. Session Riding Cross Site Reference Forgery XSRF CSRF
* Base Base - a 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. Missing Support for Integrity Check - (353)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 353 (Missing Support for Integrity Check)
The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.
* Base Base - a 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. Improper Validation of Integrity Check Value - (354)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 354 (Improper Validation of Integrity Check Value)
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
* Base Base - a 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. Trust of System Event Data - (360)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 360 (Trust of System Event Data)
Security based on event locations are insecure and can be spoofed.
* Base Base - a 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. Download of Code Without Integrity Check - (494)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 494 (Download of Code Without Integrity Check)
The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
* Variant Variant - 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. Incomplete Identification of Uploaded File Variables (PHP) - (616)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 616 (Incomplete Identification of Uploaded File Variables (PHP))
The PHP application uses an old method for processing uploaded files by referencing the four global variables that are set for each file (e.g. $varname, $varname_size, $varname_name, $varname_type). These variables could be overwritten by attackers, causing the application to process unauthorized files.
* Variant Variant - 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. Reliance on File Name or Extension of Externally-Supplied File - (646)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 646 (Reliance on File Name or Extension of Externally-Supplied File)
The product allows a file to be uploaded, but it relies on the file name or extension of the file to determine the appropriate behaviors. This could be used by attackers to cause the file to be misclassified and processed in a dangerous fashion.
* Base Base - a 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. Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking - (649)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 649 (Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking)
The product uses obfuscation or encryption of inputs that should not be mutable by an external actor, but the product does not use integrity checks to detect if those inputs have been modified.
* Base Base - a 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. Improper Enforcement of Message Integrity During Transmission in a Communication Channel - (924)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 924 (Improper Enforcement of Message Integrity During Transmission in a Communication Channel)
The product establishes a communication channel with an endpoint and receives a message from that endpoint, but it does not sufficiently ensure that the message was not modified during transmission.
* Base Base - a 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. Missing Source Correlation of Multiple Independent Data - (1293)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 1293 (Missing Source Correlation of Multiple Independent Data)
The product relies on one source of data, preventing the ability to detect if an adversary has compromised a data source.
* Variant Variant - 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. Missing Origin Validation in WebSockets - (1385)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1411 (Comprehensive Categorization: Insufficient Verification of Data Authenticity) > 1385 (Missing Origin Validation in WebSockets)
The product uses a WebSocket, but it does not properly verify that the source of data or communication is valid. Cross-Site WebSocket hijacking (CSWSH)
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Memory Safety - (1399)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety)
Weaknesses in this category are related to memory safety.
* Class Class - a weakness that is 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. Improper Restriction of Operations within the Bounds of a Memory Buffer - (119)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. Buffer Overflow buffer overrun memory safety
* Base Base - a 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. Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow. Classic Buffer Overflow Unbounded Transfer
* Variant Variant - 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. Stack-based Buffer Overflow - (121)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 121 (Stack-based Buffer Overflow)
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function). Stack Overflow
* Variant Variant - 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. Heap-based Buffer Overflow - (122)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 122 (Heap-based Buffer Overflow)
A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
* Base Base - a 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. Write-what-where Condition - (123)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 123 (Write-what-where Condition)
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
* Base Base - a 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. Buffer Underwrite ('Buffer Underflow') - (124)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 124 (Buffer Underwrite ('Buffer Underflow'))
The product writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer. buffer underrun
* Base Base - a 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. Out-of-bounds Read - (125)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 125 (Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer. OOB read
* Variant Variant - 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. Buffer Over-read - (126)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 126 (Buffer Over-read)
The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.
* Variant Variant - 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. Buffer Under-read - (127)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 127 (Buffer Under-read)
The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer.
* Variant Variant - 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. Improper Validation of Array Index - (129)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 129 (Improper Validation of Array Index)
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array. out-of-bounds array index index-out-of-range array index underflow
* Base Base - a 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. Incorrect Calculation of Buffer Size - (131)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 131 (Incorrect Calculation of Buffer Size)
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
* Base Base - a 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. Use of Externally-Controlled Format String - (134)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 134 (Use of Externally-Controlled Format String)
The product uses a function that accepts a format string as an argument, but the format string originates from an external source.
* Base Base - a 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. Reliance on Data/Memory Layout - (188)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 188 (Reliance on Data/Memory Layout)
The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
* Variant Variant - 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. Use of Incorrect Byte Ordering - (198)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 198 (Use of Incorrect Byte Ordering)
The product receives input from an upstream component, but it does not account for byte ordering (e.g. big-endian and little-endian) when processing the input, causing an incorrect number or value to be used.
* Variant Variant - 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. Improper Clearing of Heap Memory Before Release ('Heap Inspection') - (244)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 244 (Improper Clearing of Heap Memory Before Release ('Heap Inspection'))
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.
* Variant Variant - 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. Missing Release of Memory after Effective Lifetime - (401)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 401 (Missing Release of Memory after Effective Lifetime)
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse. Memory Leak
* Variant Variant - 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. Double Free - (415)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 415 (Double Free)
The product calls free() twice on the same memory address. Double-free
* Variant Variant - 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. Use After Free - (416)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 416 (Use After Free)
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. Dangling pointer UAF Use-After-Free
* Base Base - a 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. Return of Pointer Value Outside of Expected Range - (466)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 466 (Return of Pointer Value Outside of Expected Range)
A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference.
* Base Base - a 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. Return of Stack Variable Address - (562)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 562 (Return of Stack Variable Address)
A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.
* Variant Variant - 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. Assignment of a Fixed Address to a Pointer - (587)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 587 (Assignment of a Fixed Address to a Pointer)
The product sets a pointer to a specific address other than NULL or 0.
* Variant Variant - 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. Free of Memory not on the Heap - (590)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 590 (Free of Memory not on the Heap)
The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
* Chain Chain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure. Integer Overflow to Buffer Overflow - (680)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 680 (Integer Overflow to Buffer Overflow)
The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow.
* Chain Chain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure. Unchecked Return Value to NULL Pointer Dereference - (690)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 690 (Unchecked Return Value to NULL Pointer Dereference)
The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference.
* Variant Variant - 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. Free of Pointer not at Start of Buffer - (761)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 761 (Free of Pointer not at Start of Buffer)
The product calls free() on a pointer to a memory resource that was allocated on the heap, but the pointer is not at the start of the buffer.
* Variant Variant - 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. Mismatched Memory Management Routines - (762)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 762 (Mismatched Memory Management Routines)
The product attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.
* Base Base - a 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. Release of Invalid Pointer or Reference - (763)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 763 (Release of Invalid Pointer or Reference)
The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
* Base Base - a 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. Access of Memory Location Before Start of Buffer - (786)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 786 (Access of Memory Location Before Start of Buffer)
The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
* Base Base - a 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. Out-of-bounds Write - (787)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 787 (Out-of-bounds Write)
The product writes data past the end, or before the beginning, of the intended buffer. Memory Corruption
* Base Base - a 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. Access of Memory Location After End of Buffer - (788)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 788 (Access of Memory Location After End of Buffer)
The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.
* Variant Variant - 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. Memory Allocation with Excessive Size Value - (789)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 789 (Memory Allocation with Excessive Size Value)
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated. Stack Exhaustion
* Base Base - a 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. Buffer Access with Incorrect Length Value - (805)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 805 (Buffer Access with Incorrect Length Value)
The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
* Variant Variant - 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. Buffer Access Using Size of Source Buffer - (806)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 806 (Buffer Access Using Size of Source Buffer)
The product uses the size of a source buffer when reading from or writing to a destination buffer, which may cause it to access memory that is outside of the bounds of the buffer.
* Base Base - a 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. Untrusted Pointer Dereference - (822)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 822 (Untrusted Pointer Dereference)
The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.
* Base Base - a 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. Use of Out-of-range Pointer Offset - (823)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 823 (Use of Out-of-range Pointer Offset)
The product performs pointer arithmetic on a valid pointer, but it uses an offset that can point outside of the intended range of valid memory locations for the resulting pointer. Untrusted pointer offset
* Base Base - a 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. Access of Uninitialized Pointer - (824)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 824 (Access of Uninitialized Pointer)
The product accesses or uses a pointer that has not been initialized.
* Base Base - a 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. Expired Pointer Dereference - (825)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1399 (Comprehensive Categorization: Memory Safety) > 825 (Expired Pointer Dereference)
The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid. Dangling pointer
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Poor Coding Practices - (1412)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices)
Weaknesses in this category are related to poor coding practices.
* Variant Variant - 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. ASP.NET Misconfiguration: Creating Debug Binary - (11)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 11 (ASP.NET Misconfiguration: Creating Debug Binary)
Debugging messages help attackers learn about the system and plan a form of attack.
* Variant Variant - 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. Struts: Incomplete validate() Method Definition - (103)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 103 (Struts: Incomplete validate() Method Definition)
The product has a validator form that either does not define a validate() method, or defines a validate() method but does not call super.validate().
* Variant Variant - 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. Struts: Form Bean Does Not Extend Validation Class - (104)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 104 (Struts: Form Bean Does Not Extend Validation Class)
If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation.
* Variant Variant - 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. Struts: Unused Validation Form - (107)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 107 (Struts: Unused Validation Form)
An unused validation form indicates that validation logic is not up-to-date.
* Variant Variant - 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. Struts: Validator Without Form Field - (110)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 110 (Struts: Validator Without Form Field)
Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.
* Variant Variant - 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. Direct Use of Unsafe JNI - (111)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 111 (Direct Use of Unsafe JNI)
When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.
* Base Base - a 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. Use of Inherently Dangerous Function - (242)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 242 (Use of Inherently Dangerous Function)
The product calls a function that can never be guaranteed to work safely.
* Variant Variant - 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. J2EE Bad Practices: Direct Management of Connections - (245)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 245 (J2EE Bad Practices: Direct Management of Connections)
The J2EE application directly manages connections, instead of using the container's connection management facilities.
* Variant Variant - 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. J2EE Bad Practices: Direct Use of Sockets - (246)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 246 (J2EE Bad Practices: Direct Use of Sockets)
The J2EE application directly uses sockets instead of using framework method calls.
* Base Base - a 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. Incorrect Check of Function Return Value - (253)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 253 (Incorrect Check of Function Return Value)
The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.
* Base Base - a 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. Improperly Implemented Security Check for Standard - (358)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 358 (Improperly Implemented Security Check for Standard)
The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.
* Variant Variant - 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. J2EE Bad Practices: Direct Use of Threads - (383)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 383 (J2EE Bad Practices: Direct Use of Threads)
Thread management in a Web application is forbidden in some circumstances and is always highly error prone.
* Base Base - a 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. Missing Report of Error Condition - (392)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 392 (Missing Report of Error Condition)
The product encounters an error but does not provide a status code or return value to indicate that an error has occurred.
* Base Base - a 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. Return of Wrong Status Code - (393)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 393 (Return of Wrong Status Code)
A function or operation returns an incorrect return value or status code that does not indicate the true result of execution, causing the product to modify its behavior based on the incorrect result.
* Base Base - a 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. Expected Behavior Violation - (440)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 440 (Expected Behavior Violation)
A feature, API, or function does not perform according to its specification.
* Class Class - a weakness that is 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. UI Discrepancy for Security Feature - (446)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 446 (UI Discrepancy for Security Feature)
The user interface does not correctly enable or configure a security feature, but the interface provides feedback that causes the user to believe that the feature is in a secure state.
* Base Base - a 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. Obsolete Feature in UI - (448)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 448 (Obsolete Feature in UI)
A UI function is obsolete and the product does not warn the user.
* Base Base - a 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. The UI Performs the Wrong Action - (449)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 449 (The UI Performs the Wrong Action)
The UI performs the wrong action with respect to the user's request.
* Class Class - a weakness that is 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. User Interface (UI) Misrepresentation of Critical Information - (451)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 451 (User Interface (UI) Misrepresentation of Critical Information)
The user interface (UI) does not properly represent critical information to the user, allowing the information - or its source - to be obscured or spoofed. This is often a component in phishing attacks.
* Variant Variant - 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. Duplicate Key in Associative List (Alist) - (462)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 462 (Duplicate Key in Associative List (Alist))
Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.
* Base Base - a 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. Use of Function with Inconsistent Implementations - (474)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 474 (Use of Function with Inconsistent Implementations)
The code uses a function that has inconsistent implementations across operating systems and versions.
* Base Base - a 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. Undefined Behavior for Input to API - (475)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 475 (Undefined Behavior for Input to API)
The behavior of this function is undefined unless its control parameter is set to a specific value.
* Base Base - a 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. NULL Pointer Dereference - (476)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 476 (NULL Pointer Dereference)
The product dereferences a pointer that it expects to be valid but is NULL. NPD null deref NPE nil pointer dereference
* Base Base - a 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. Use of Obsolete Function - (477)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 477 (Use of Obsolete Function)
The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.
* Base Base - a 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. Omitted Break Statement in Switch - (484)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 484 (Omitted Break Statement in Switch)
The product omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.
* Base Base - a 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. Active Debug Code - (489)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 489 (Active Debug Code)
The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information. Leftover debug code
* Class Class - a weakness that is 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. Embedded Malicious Code - (506)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 506 (Embedded Malicious Code)
The product contains code that appears to be malicious in nature.
* Base Base - a 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. Trojan Horse - (507)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 507 (Trojan Horse)
The product appears to contain benign or useful functionality, but it also contains code that is hidden from normal operation that violates the intended security policy of the user or the system administrator.
* Base Base - a 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. Non-Replicating Malicious Code - (508)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 508 (Non-Replicating Malicious Code)
Non-replicating malicious code only resides on the target system or product that is attacked; it does not attempt to spread to other systems.
* Base Base - a 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. Replicating Malicious Code (Virus or Worm) - (509)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 509 (Replicating Malicious Code (Virus or Worm))
Replicating malicious code, including viruses and worms, will attempt to attack other systems once it has successfully compromised the target system or the product.
* Base Base - a 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. Trapdoor - (510)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 510 (Trapdoor)
A trapdoor is a hidden piece of code that responds to a special input, allowing its user access to resources without passing through the normal security enforcement mechanism.
* Base Base - a 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. Logic/Time Bomb - (511)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 511 (Logic/Time Bomb)
The product contains code that is designed to disrupt the legitimate operation of the product (or its environment) when a certain time passes, or when a certain logical condition is met.
* Base Base - a 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. Spyware - (512)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 512 (Spyware)
The product collects personally identifiable information about a human user or the user's activities, but the product accesses this information using other resources besides itself, and it does not require that user's explicit approval or direct input into the product.
* Variant Variant - 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. Suspicious Comment - (546)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 546 (Suspicious Comment)
The code contains comments that suggest the presence of bugs, incomplete functionality, or weaknesses.
* Base Base - a 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. Use of Hard-coded, Security-relevant Constants - (547)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 547 (Use of Hard-coded, Security-relevant Constants)
The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.
* Variant Variant - 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. Use of umask() with chmod-style Argument - (560)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 560 (Use of umask() with chmod-style Argument)
The product calls umask() with an incorrect argument that is specified as if it is an argument to chmod().
* Base Base - a 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. Dead Code - (561)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 561 (Dead Code)
The product contains dead code, which can never be executed.
* Base Base - a 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. Assignment to Variable without Use - (563)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 563 (Assignment to Variable without Use)
The variable's value is assigned but never used, making it a dead store. Unused Variable
* Base Base - a 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. Expression is Always False - (570)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 570 (Expression is Always False)
The product contains an expression that will always evaluate to false.
* Base Base - a 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. Expression is Always True - (571)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 571 (Expression is Always True)
The product contains an expression that will always evaluate to true.
* Class Class - a weakness that is 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. Improper Following of Specification by Caller - (573)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 573 (Improper Following of Specification by Caller)
The product does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.
* Variant Variant - 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. EJB Bad Practices: Use of AWT Swing - (575)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 575 (EJB Bad Practices: Use of AWT Swing)
The product violates the Enterprise JavaBeans (EJB) specification by using AWT/Swing.
* Variant Variant - 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. EJB Bad Practices: Use of Java I/O - (576)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 576 (EJB Bad Practices: Use of Java I/O)
The product violates the Enterprise JavaBeans (EJB) specification by using the java.io package.
* Variant Variant - 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. EJB Bad Practices: Use of Sockets - (577)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 577 (EJB Bad Practices: Use of Sockets)
The product violates the Enterprise JavaBeans (EJB) specification by using sockets.
* Variant Variant - 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. EJB Bad Practices: Use of Class Loader - (578)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 578 (EJB Bad Practices: Use of Class Loader)
The product violates the Enterprise JavaBeans (EJB) specification by using the class loader.
* Variant Variant - 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. J2EE Bad Practices: Non-serializable Object Stored in Session - (579)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 579 (J2EE Bad Practices: Non-serializable Object Stored in Session)
The product stores a non-serializable object as an HttpSession attribute, which can hurt reliability.
* Variant Variant - 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. Object Model Violation: Just One of Equals and Hashcode Defined - (581)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 581 (Object Model Violation: Just One of Equals and Hashcode Defined)
The product does not maintain equal hashcodes for equal objects.
* Variant Variant - 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. Empty Synchronized Block - (585)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 585 (Empty Synchronized Block)
The product contains an empty synchronized block.
* Base Base - a 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. Explicit Call to Finalize() - (586)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 586 (Explicit Call to Finalize())
The product makes an explicit call to the finalize() method from outside the finalizer.
* Variant Variant - 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. Call to Non-ubiquitous API - (589)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 589 (Call to Non-ubiquitous API)
The product uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.
* Variant Variant - 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. J2EE Framework: Saving Unserializable Objects to Disk - (594)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 594 (J2EE Framework: Saving Unserializable Objects to Disk)
When the J2EE container attempts to write unserializable objects to disk there is no guarantee that the process will complete successfully.
* Variant Variant - 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. Multiple Binds to the Same Port - (605)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 605 (Multiple Binds to the Same Port)
When multiple sockets are allowed to bind to the same port, other services on that port may be stolen or spoofed.
* Base Base - a 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. Function Call with Incorrectly Specified Arguments - (628)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 628 (Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
* Class Class - a weakness that is 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. Multiple Operations on Resource in Single-Operation Context - (675)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 675 (Multiple Operations on Resource in Single-Operation Context)
The product performs the same operation on a resource two or more times, when the operation should only be applied once.
* Base Base - a 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. Use of Potentially Dangerous Function - (676)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 676 (Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
* Variant Variant - 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. Function Call With Incorrect Order of Arguments - (683)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 683 (Function Call With Incorrect Order of Arguments)
The product calls a function, procedure, or routine, but the caller specifies the arguments in an incorrect order, leading to resultant weaknesses.
* Class Class - a weakness that is 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. Incorrect Provision of Specified Functionality - (684)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 684 (Incorrect Provision of Specified Functionality)
The code does not function according to its published specifications, potentially leading to incorrect usage.
* Variant Variant - 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. Function Call With Incorrect Number of Arguments - (685)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 685 (Function Call With Incorrect Number of Arguments)
The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.
* Variant Variant - 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. Function Call With Incorrect Argument Type - (686)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 686 (Function Call With Incorrect Argument Type)
The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
* Variant Variant - 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. Function Call With Incorrectly Specified Argument Value - (687)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 687 (Function Call With Incorrectly Specified Argument Value)
The product calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, which may lead to resultant weaknesses.
* Variant Variant - 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. Function Call With Incorrect Variable or Reference as Argument - (688)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 688 (Function Call With Incorrect Variable or Reference as Argument)
The product calls a function, procedure, or routine, but the caller specifies the wrong variable or reference as one of the arguments, which may lead to undefined behavior and resultant weaknesses.
* Base Base - a 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. Use of Low-Level Functionality - (695)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 695 (Use of Low-Level Functionality)
The product uses low-level functionality that is explicitly prohibited by the framework or specification under which the product is supposed to operate.
* Pillar Pillar - a weakness that 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. Improper Adherence to Coding Standards - (710)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 710 (Improper Adherence to Coding Standards)
The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.
* Class Class - a weakness that is 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. Reliance on Undefined, Unspecified, or Implementation-Defined Behavior - (758)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
* Base Base - a 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. Critical Data Element Declared Public - (766)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 766 (Critical Data Element Declared Public)
The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.
* Variant Variant - 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. Use of Path Manipulation Function without Maximum-sized Buffer - (785)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 785 (Use of Path Manipulation Function without Maximum-sized Buffer)
The product invokes a function for normalizing paths or file names, but it provides an output buffer that is smaller than the maximum possible size, such as PATH_MAX.
* Class Class - a weakness that is 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. Hidden Functionality - (912)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 912 (Hidden Functionality)
The product contains functionality that is not documented, not part of the specification, and not accessible through an interface or command sequence that is obvious to the product's users or administrators.
* Base Base - a 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. Insufficient Visual Distinction of Homoglyphs Presented to User - (1007)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1007 (Insufficient Visual Distinction of Homoglyphs Presented to User)
The product displays information or identifiers to a user, but the display mechanism does not make it easy for the user to distinguish between visually similar or identical glyphs (homoglyphs), which may cause the user to misinterpret a glyph and perform an unintended, insecure action. Homograph Attack
* Base Base - a 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. Use of Redundant Code - (1041)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1041 (Use of Redundant Code)
The product has multiple functions, methods, procedures, macros, etc. that contain the same code.
* Base Base - a 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. Data Element Aggregating an Excessively Large Number of Non-Primitive Elements - (1043)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1043 (Data Element Aggregating an Excessively Large Number of Non-Primitive Elements)
The product uses a data element that has an excessively large number of sub-elements with non-primitive data types such as structures or aggregated objects.
* Base Base - a 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. Architecture with Number of Horizontal Layers Outside of Expected Range - (1044)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1044 (Architecture with Number of Horizontal Layers Outside of Expected Range)
The product's architecture contains too many - or too few - horizontal layers.
* Base Base - a 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. Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor - (1045)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1045 (Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor)
A parent class has a virtual destructor method, but the parent has a child class that does not have a virtual destructor.
* Base Base - a 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. Modules with Circular Dependencies - (1047)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1047 (Modules with Circular Dependencies)
The product contains modules in which one module has references that cycle back to itself, i.e., there are circular dependencies.
* Base Base - a 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. Invokable Control Element with Large Number of Outward Calls - (1048)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1048 (Invokable Control Element with Large Number of Outward Calls)
The code contains callable control elements that contain an excessively large number of references to other application objects external to the context of the callable, i.e. a Fan-Out value that is excessively large.
* Base Base - a 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. Missing Documentation for Design - (1053)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1053 (Missing Documentation for Design)
The product does not have documentation that represents how it is designed.
* Base Base - a 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. Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer - (1054)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1054 (Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer)
The code at one architectural layer invokes code that resides at a deeper layer than the adjacent layer, i.e., the invocation skips at least one layer, and the invoked code is not part of a vertical utility layer that can be referenced from any horizontal layer.
* Base Base - a 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. Multiple Inheritance from Concrete Classes - (1055)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1055 (Multiple Inheritance from Concrete Classes)
The product contains a class with inheritance from more than one concrete class.
* Base Base - a 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. Invokable Control Element with Variadic Parameters - (1056)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1056 (Invokable Control Element with Variadic Parameters)
A named-callable or method control element has a signature that supports a variable (variadic) number of parameters or arguments.
* Base Base - a 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. Data Access Operations Outside of Expected Data Manager Component - (1057)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1057 (Data Access Operations Outside of Expected Data Manager Component)
The product uses a dedicated, central data manager component as required by design, but it contains code that performs data-access operations that do not use this data manager.
* Class Class - a weakness that is 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. Insufficient Technical Documentation - (1059)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1059 (Insufficient Technical Documentation)
The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all the relevant software/hardware elements of the product, such as its usage, structure, architectural components, interfaces, design, implementation, configuration, operation, etc.
* Base Base - a 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. Excessive Number of Inefficient Server-Side Data Accesses - (1060)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1060 (Excessive Number of Inefficient Server-Side Data Accesses)
The product performs too many data queries without using efficient data processing functionality such as stored procedures.
* Class Class - a weakness that is 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. Insufficient Encapsulation - (1061)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1061 (Insufficient Encapsulation)
The product does not sufficiently hide the internal representation and implementation details of data or methods, which might allow external components or modules to modify data unexpectedly, invoke unexpected functionality, or introduce dependencies that the programmer did not intend.
* Base Base - a 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. Parent Class with References to Child Class - (1062)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1062 (Parent Class with References to Child Class)
The code has a parent class that contains references to a child class, its methods, or its members.
* Base Base - a 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. Invokable Control Element with Signature Containing an Excessive Number of Parameters - (1064)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1064 (Invokable Control Element with Signature Containing an Excessive Number of Parameters)
The product contains a function, subroutine, or method whose signature has an unnecessarily large number of parameters/arguments.
* Base Base - a 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. Runtime Resource Management Control Element in a Component Built to Run on Application Servers - (1065)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1065 (Runtime Resource Management Control Element in a Component Built to Run on Application Servers)
The product uses deployed components from application servers, but it also uses low-level functions/methods for management of resources, instead of the API provided by the application server.
* Base Base - a 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. Missing Serialization Control Element - (1066)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1066 (Missing Serialization Control Element)
The product contains a serializable data element that does not have an associated serialization method.
* Base Base - a 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. Inconsistency Between Implementation and Documented Design - (1068)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1068 (Inconsistency Between Implementation and Documented Design)
The implementation of the product is not consistent with the design as described within the relevant documentation.
* Variant Variant - 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. Empty Exception Block - (1069)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1069 (Empty Exception Block)
An invokable code block contains an exception handling block that does not contain any code, i.e. is empty.
* Base Base - a 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. Serializable Data Element Containing non-Serializable Item Elements - (1070)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1070 (Serializable Data Element Containing non-Serializable Item Elements)
The product contains a serializable, storable data element such as a field or member, but the data element contains member elements that are not serializable.
* Base Base - a 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. Empty Code Block - (1071)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1071 (Empty Code Block)
The source code contains a block that does not contain any code, i.e., the block is empty.
* Base Base - a 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. Class with Excessively Deep Inheritance - (1074)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1074 (Class with Excessively Deep Inheritance)
A class has an inheritance level that is too high, i.e., it has a large number of parent classes.
* Base Base - a 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. Unconditional Control Flow Transfer outside of Switch Block - (1075)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1075 (Unconditional Control Flow Transfer outside of Switch Block)
The product performs unconditional control transfer (such as a "goto") in code outside of a branching structure such as a switch block.
* Class Class - a weakness that is 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. Insufficient Adherence to Expected Conventions - (1076)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1076 (Insufficient Adherence to Expected Conventions)
The product's architecture, source code, design, documentation, or other artifact does not follow required conventions.
* Class Class - a weakness that is 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. Inappropriate Source Code Style or Formatting - (1078)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1078 (Inappropriate Source Code Style or Formatting)
The source code does not follow desired style or formatting for indentation, white space, comments, etc.
* Base Base - a 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. Parent Class without Virtual Destructor Method - (1079)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1079 (Parent Class without Virtual Destructor Method)
A parent class contains one or more child classes, but the parent class does not have a virtual destructor method.
* Base Base - a 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. Source Code File with Excessive Number of Lines of Code - (1080)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1080 (Source Code File with Excessive Number of Lines of Code)
A source code file has too many lines of code.
* Base Base - a 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. Class Instance Self Destruction Control Element - (1082)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1082 (Class Instance Self Destruction Control Element)
The code contains a class instance that calls the method or function to delete or destroy itself.
* Base Base - a 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. Data Access from Outside Expected Data Manager Component - (1083)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1083 (Data Access from Outside Expected Data Manager Component)
The product is intended to manage data access through a particular data manager component such as a relational or non-SQL database, but it contains code that performs data access operations without using that component.
* Base Base - a 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. Invokable Control Element with Excessive Volume of Commented-out Code - (1085)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1085 (Invokable Control Element with Excessive Volume of Commented-out Code)
A function, method, procedure, etc. contains an excessive amount of code that has been commented out within its body.
* Base Base - a 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. Class with Excessive Number of Child Classes - (1086)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1086 (Class with Excessive Number of Child Classes)
A class contains an unnecessarily large number of children.
* Base Base - a 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. Class with Virtual Method without a Virtual Destructor - (1087)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1087 (Class with Virtual Method without a Virtual Destructor)
A class contains a virtual method, but the method does not have an associated virtual destructor.
* Base Base - a 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. Method Containing Access of a Member Element from Another Class - (1090)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1090 (Method Containing Access of a Member Element from Another Class)
A method for a class performs an operation that directly accesses a member element from another class.
* Base Base - a 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. Use of Same Invokable Control Element in Multiple Architectural Layers - (1092)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1092 (Use of Same Invokable Control Element in Multiple Architectural Layers)
The product uses the same control element across multiple architectural layers.
* Class Class - a weakness that is 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. Excessively Complex Data Representation - (1093)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1093 (Excessively Complex Data Representation)
The product uses an unnecessarily complex internal representation for its data structures or interrelationships between those structures.
* Base Base - a 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. Loop Condition Value Update within the Loop - (1095)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1095 (Loop Condition Value Update within the Loop)
The product uses a loop with a control flow condition based on a value that is updated within the body of the loop.
* Base Base - a 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. Persistent Storable Data Element without Associated Comparison Control Element - (1097)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1097 (Persistent Storable Data Element without Associated Comparison Control Element)
The product uses a storable data element that does not have all of the associated functions or methods that are necessary to support comparison.
* Base Base - a 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. Data Element containing Pointer Item without Proper Copy Control Element - (1098)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1098 (Data Element containing Pointer Item without Proper Copy Control Element)
The code contains a data element with a pointer that does not have an associated copy or constructor method.
* Base Base - a 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. Inconsistent Naming Conventions for Identifiers - (1099)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1099 (Inconsistent Naming Conventions for Identifiers)
The product's code, documentation, or other artifacts do not consistently use the same naming conventions for variables, callables, groups of related callables, I/O capabilities, data types, file names, or similar types of elements.
* Base Base - a 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. Insufficient Isolation of System-Dependent Functions - (1100)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1100 (Insufficient Isolation of System-Dependent Functions)
The product or code does not isolate system-dependent functionality into separate standalone modules.
* Base Base - a 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. Reliance on Runtime Component in Generated Code - (1101)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1101 (Reliance on Runtime Component in Generated Code)
The product uses automatically-generated code that cannot be executed without a specific runtime support component.
* Base Base - a 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. Reliance on Machine-Dependent Data Representation - (1102)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1102 (Reliance on Machine-Dependent Data Representation)
The code uses a data representation that relies on low-level data representation or constructs that may vary across different processors, physical machines, OSes, or other physical components.
* Base Base - a 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. Use of Platform-Dependent Third Party Components - (1103)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1103 (Use of Platform-Dependent Third Party Components)
The product relies on third-party components that do not provide equivalent functionality across all desirable platforms.
* Base Base - a 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. Insufficient Encapsulation of Machine-Dependent Functionality - (1105)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1105 (Insufficient Encapsulation of Machine-Dependent Functionality)
The product or code uses machine-dependent functionality, but it does not sufficiently encapsulate or isolate this functionality from the rest of the code.
* Base Base - a 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. Insufficient Use of Symbolic Constants - (1106)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1106 (Insufficient Use of Symbolic Constants)
The source code uses literal constants that may need to change or evolve over time, instead of using symbolic constants.
* Base Base - a 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. Insufficient Isolation of Symbolic Constant Definitions - (1107)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1107 (Insufficient Isolation of Symbolic Constant Definitions)
The source code uses symbolic constants, but it does not sufficiently place the definitions of these constants into a more centralized or isolated location.
* Base Base - a 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. Excessive Reliance on Global Variables - (1108)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1108 (Excessive Reliance on Global Variables)
The code is structured in a way that relies too much on using or setting global variables throughout various points in the code, instead of preserving the associated information in a narrower, more local context.
* Base Base - a 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. Use of Same Variable for Multiple Purposes - (1109)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1109 (Use of Same Variable for Multiple Purposes)
The code contains a callable, block, or other code element in which the same variable is used to control more than one unique task or store more than one instance of data.
* Base Base - a 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. Incomplete Design Documentation - (1110)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1110 (Incomplete Design Documentation)
The product's design documentation does not adequately describe control flow, data flow, system initialization, relationships between tasks, components, rationales, or other important aspects of the design.
* Base Base - a 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. Incomplete I/O Documentation - (1111)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1111 (Incomplete I/O Documentation)
The product's documentation does not adequately define inputs, outputs, or system/software interfaces.
* Base Base - a 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. Incomplete Documentation of Program Execution - (1112)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1112 (Incomplete Documentation of Program Execution)
The document does not fully define all mechanisms that are used to control or influence how product-specific programs are executed.
* Base Base - a 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. Inappropriate Comment Style - (1113)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1113 (Inappropriate Comment Style)
The source code uses comment styles or formats that are inconsistent or do not follow expected standards for the product.
* Base Base - a 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. Inappropriate Whitespace Style - (1114)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1114 (Inappropriate Whitespace Style)
The source code contains whitespace that is inconsistent across the code or does not follow expected standards for the product.
* Base Base - a 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. Source Code Element without Standard Prologue - (1115)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1115 (Source Code Element without Standard Prologue)
The source code contains elements such as source files that do not consistently provide a prologue or header that has been standardized for the project.
* Base Base - a 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. Inaccurate Comments - (1116)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1116 (Inaccurate Comments)
The source code contains comments that do not accurately describe or explain aspects of the portion of the code with which the comment is associated.
* Base Base - a 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. Callable with Insufficient Behavioral Summary - (1117)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1117 (Callable with Insufficient Behavioral Summary)
The code contains a function or method whose signature and/or associated inline documentation does not sufficiently describe the callable's inputs, outputs, side effects, assumptions, or return codes.
* Base Base - a 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. Insufficient Documentation of Error Handling Techniques - (1118)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1118 (Insufficient Documentation of Error Handling Techniques)
The documentation does not sufficiently describe the techniques that are used for error handling, exception processing, or similar mechanisms.
* Base Base - a 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. Excessive Use of Unconditional Branching - (1119)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1119 (Excessive Use of Unconditional Branching)
The code uses too many unconditional branches (such as "goto").
* Class Class - a weakness that is 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. Excessive Code Complexity - (1120)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1120 (Excessive Code Complexity)
The code is too complex, as calculated using a well-defined, quantitative measure.
* Base Base - a 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. Excessive McCabe Cyclomatic Complexity - (1121)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1121 (Excessive McCabe Cyclomatic Complexity)
The code contains McCabe cyclomatic complexity that exceeds a desirable maximum.
* Base Base - a 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. Excessive Halstead Complexity - (1122)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1122 (Excessive Halstead Complexity)
The code is structured in a way that a Halstead complexity measure exceeds a desirable maximum.
* Base Base - a 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. Excessive Use of Self-Modifying Code - (1123)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1123 (Excessive Use of Self-Modifying Code)
The product uses too much self-modifying code.
* Base Base - a 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. Excessively Deep Nesting - (1124)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1124 (Excessively Deep Nesting)
The code contains a callable or other code grouping in which the nesting / branching is too deep.
* Base Base - a 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. Excessive Attack Surface - (1125)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1125 (Excessive Attack Surface)
The product has an attack surface whose quantitative measurement exceeds a desirable maximum.
* Base Base - a 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. Declaration of Variable with Unnecessarily Wide Scope - (1126)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1126 (Declaration of Variable with Unnecessarily Wide Scope)
The source code declares a variable in one scope, but the variable is only used within a narrower scope.
* Base Base - a 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. Compilation with Insufficient Warnings or Errors - (1127)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1127 (Compilation with Insufficient Warnings or Errors)
The code is compiled without sufficient warnings enabled, which may prevent the detection of subtle bugs or quality issues.
* Class Class - a weakness that is 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. Irrelevant Code - (1164)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1164 (Irrelevant Code)
The product contains code that is not essential for execution, i.e. makes no state changes and has no side effects that alter data or control flow, such that removal of the code would have no impact to functionality or correctness.
* Class Class - a weakness that is 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. Use of Prohibited Code - (1177)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1177 (Use of Prohibited Code)
The product uses a function, library, or third party component that has been explicitly prohibited, whether by the developer or the customer.
* Base Base - a 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. Failure to Disable Reserved Bits - (1209)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1209 (Failure to Disable Reserved Bits)
The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.
* Base Base - a 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. Improper Finite State Machines (FSMs) in Hardware Logic - (1245)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1245 (Improper Finite State Machines (FSMs) in Hardware Logic)
Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system.
* Base Base - a 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. Multiple Releases of Same Resource or Handle - (1341)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1341 (Multiple Releases of Same Resource or Handle)
The product attempts to close or release a resource or handle more than once, without any successful open between the close operations.
* Class Class - a weakness that is 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. Reliance on Insufficiently Trustworthy Component - (1357)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1412 (Comprehensive Categorization: Poor Coding Practices) > 1357 (Reliance on Insufficiently Trustworthy Component)
The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Protection Mechanism Failure - (1413)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure)
Weaknesses in this category are related to protection mechanism failure.
* Base Base - a 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. Collapse of Data into Unsafe Value - (182)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 182 (Collapse of Data into Unsafe Value)
The product filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
* Base Base - a 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. Incomplete List of Disallowed Inputs - (184)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 184 (Incomplete List of Disallowed Inputs)
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete. Denylist / Deny List Blocklist / Block List Blacklist / Black List
* Base Base - a 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. Truncation of Security-relevant Information - (222)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 222 (Truncation of Security-relevant Information)
The product truncates the display, recording, or processing of security-relevant information in a way that can obscure the source or nature of an attack.
* Base Base - a 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. Omission of Security-relevant Information - (223)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 223 (Omission of Security-relevant Information)
The product does not record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe.
* Base Base - a 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. Obscured Security-relevant Information by Alternate Name - (224)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 224 (Obscured Security-relevant Information by Alternate Name)
The product records security-relevant information according to an alternate name of the affected entity, instead of the canonical name.
* Base Base - a 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. Product UI does not Warn User of Unsafe Actions - (356)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 356 (Product UI does not Warn User of Unsafe Actions)
The product's user interface does not warn the user before undertaking an unsafe action on behalf of that user. This makes it easier for attackers to trick users into inflicting damage to their system.
* Base Base - a 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. Insufficient UI Warning of Dangerous Operations - (357)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 357 (Insufficient UI Warning of Dangerous Operations)
The user interface provides a warning to a user regarding dangerous or sensitive operations, but the warning is not noticeable enough to warrant attention.
* Base Base - a 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. Multiple Interpretations of UI Input - (450)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 450 (Multiple Interpretations of UI Input)
The UI has multiple interpretations of user input but does not prompt the user when it selects the less secure interpretation.
* Class Class - a weakness that is 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. Client-Side Enforcement of Server-Side Security - (602)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 602 (Client-Side Enforcement of Server-Side Security)
The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
* Pillar Pillar - a weakness that 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. Protection Mechanism Failure - (693)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 693 (Protection Mechanism Failure)
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
* Base Base - a 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. Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') - (757)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 757 (Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade'))
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.
* Base Base - a 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. Insufficient Logging - (778)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 778 (Insufficient Logging)
When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.
* Base Base - a 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. Reliance on Untrusted Inputs in a Security Decision - (807)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 807 (Reliance on Untrusted Inputs in a Security Decision)
The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.
* Class Class - a weakness that is 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. Inadequate Detection or Handling of Adversarial Input Perturbations in Automated Recognition Mechanism - (1039)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1039 (Inadequate Detection or Handling of Adversarial Input Perturbations in Automated Recognition Mechanism)
The product uses an automated mechanism such as machine learning to recognize complex data inputs (e.g. image or audio) as a particular concept or category, but it does not properly detect or handle inputs that have been modified or constructed in a way that causes the mechanism to detect a different, incorrect concept.
* Base Base - a 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. Semiconductor Defects in Hardware Logic with Security-Sensitive Implications - (1248)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1248 (Semiconductor Defects in Hardware Logic with Security-Sensitive Implications)
The security-sensitive hardware module contains semiconductor defects.
* Base Base - a 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. Incorrect Selection of Fuse Values - (1253)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1253 (Incorrect Selection of Fuse Values)
The logic level used to set a system to a secure state relies on a fuse being unblown. An attacker can set the system to an insecure state merely by blowing the fuse.
* Base Base - a 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. Product Released in Non-Release Configuration - (1269)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1269 (Product Released in Non-Release Configuration)
The product released to market is released in pre-production or manufacturing configuration.
* Base Base - a 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. Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)
Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
* Base Base - a 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. Public Key Re-Use for Signing both Debug and Production Code - (1291)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1291 (Public Key Re-Use for Signing both Debug and Production Code)
The same public key is used for signing both debug and production code.
* Base Base - a 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. Missing Support for Security Features in On-chip Fabrics or Buses - (1318)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1318 (Missing Support for Security Features in On-chip Fabrics or Buses)
On-chip fabrics or buses either do not support or are not configured to support privilege separation or other security features, such as access control.
* Base Base - a 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. Improper Protection against Electromagnetic Fault Injection (EM-FI) - (1319)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1319 (Improper Protection against Electromagnetic Fault Injection (EM-FI))
The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.
* Base Base - a 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. Missing Immutable Root of Trust in Hardware - (1326)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1326 (Missing Immutable Root of Trust in Hardware)
A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.
* Base Base - a 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. Improper Protections Against Hardware Overheating - (1338)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1338 (Improper Protections Against Hardware Overheating)
A hardware device is missing or has inadequate protection features to prevent overheating.
* Base Base - a 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. Missing Security-Relevant Feedback for Unexecuted Operations in Hardware Interface - (1429)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1413 (Comprehensive Categorization: Protection Mechanism Failure) > 1429 (Missing Security-Relevant Feedback for Unexecuted Operations in Hardware Interface)
The product has a hardware interface that silently discards operations in situations for which feedback would be security-relevant, such as the timely detection of failures or attacks.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Randomness - (1414)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness)
Weaknesses in this category are related to randomness.
* Variant Variant - 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. J2EE Misconfiguration: Insufficient Session-ID Length - (6)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 6 (J2EE Misconfiguration: Insufficient Session-ID Length)
The J2EE application is configured to use an insufficient session ID length.
* Base Base - a 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. Reusing a Nonce, Key Pair in Encryption - (323)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 323 (Reusing a Nonce, Key Pair in Encryption)
Nonces should be used for the present occasion and only once.
* Variant Variant - 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. Generation of Predictable IV with CBC Mode - (329)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 329 (Generation of Predictable IV with CBC Mode)
The product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.
* Class Class - a weakness that is 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. Use of Insufficiently Random Values - (330)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 330 (Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
* Base Base - a 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. Insufficient Entropy - (331)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 331 (Insufficient Entropy)
The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
* Variant Variant - 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. Insufficient Entropy in PRNG - (332)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 332 (Insufficient Entropy in PRNG)
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
* Variant Variant - 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. Improper Handling of Insufficient Entropy in TRNG - (333)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 333 (Improper Handling of Insufficient Entropy in TRNG)
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.
* Base Base - a 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. Small Space of Random Values - (334)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 334 (Small Space of Random Values)
The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.
* Base Base - a 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. Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG) - (335)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 335 (Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.
* Variant Variant - 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. Same Seed in Pseudo-Random Number Generator (PRNG) - (336)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 336 (Same Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
* Variant Variant - 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. Predictable Seed in Pseudo-Random Number Generator (PRNG) - (337)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 337 (Predictable Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
* Base Base - a 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. Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) - (338)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 338 (Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
* Variant Variant - 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. Small Seed Space in PRNG - (339)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 339 (Small Seed Space in PRNG)
A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.
* Class Class - a weakness that is 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. Generation of Predictable Numbers or Identifiers - (340)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 340 (Generation of Predictable Numbers or Identifiers)
The product uses a scheme that generates numbers or identifiers that are more predictable than required.
* Base Base - a 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. Predictable from Observable State - (341)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 341 (Predictable from Observable State)
A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.
* Base Base - a 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. Predictable Exact Value from Previous Values - (342)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 342 (Predictable Exact Value from Previous Values)
An exact value or random number can be precisely predicted by observing previous values.
* Base Base - a 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. Predictable Value Range from Previous Values - (343)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 343 (Predictable Value Range from Previous Values)
The product's random number generator produces a series of values which, when observed, can be used to infer a relatively small range of possibilities for the next value that could be generated.
* Base Base - a 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. Use of Invariant Value in Dynamically Changing Context - (344)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 344 (Use of Invariant Value in Dynamically Changing Context)
The product uses a constant value, name, or reference, but this value can (or should) vary across different environments.
* Base Base - a 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. Generation of Weak Initialization Vector (IV) - (1204)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 1204 (Generation of Weak Initialization Vector (IV))
The product uses a cryptographic primitive that uses an Initialization Vector (IV), but the product does not generate IVs that are sufficiently unpredictable or unique according to the expected cryptographic requirements for that primitive.
* Base Base - a 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. Use of Predictable Algorithm in Random Number Generator - (1241)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1414 (Comprehensive Categorization: Randomness) > 1241 (Use of Predictable Algorithm in Random Number Generator)
The device uses an algorithm that is predictable and generates a pseudo-random number.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Resource Control - (1415)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control)
Weaknesses in this category are related to resource control.
* Base Base - a 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. Covert Timing Channel - (385)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 385 (Covert Timing Channel)
Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.
* Base Base - a 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. Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') - (470)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'))
The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code. Reflection Injection
* Variant Variant - 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. PHP External Variable Modification - (473)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 473 (PHP External Variable Modification)
A PHP application does not properly protect against the modification of variables from external sources, such as query parameters or cookies. This can expose the application to numerous weaknesses that would not exist otherwise.
* Base Base - a 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. Deserialization of Untrusted Data - (502)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 502 (Deserialization of Untrusted Data)
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. Marshaling, Unmarshaling Pickling, Unpickling PHP Object Injection
* Class Class - a weakness that is 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. Covert Channel - (514)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 514 (Covert Channel)
A covert channel is a path that can be used to transfer information in a way not intended by the system's designers.
* Base Base - a 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. Covert Storage Channel - (515)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 515 (Covert Storage Channel)
A covert storage channel transfers information through the setting of bits by one program and the reading of those bits by another. What distinguishes this case from that of ordinary operation is that the bits are used to convey encoded information.
* Class Class - a weakness that is 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. Operation on a Resource after Expiration or Release - (672)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 672 (Operation on a Resource after Expiration or Release)
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
* Base Base - a 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. Premature Release of Resource During Expected Lifetime - (826)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 826 (Premature Release of Resource During Expected Lifetime)
The product releases a resource that is still intended to be used by itself or another actor.
* Base Base - a 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. Use of Expired File Descriptor - (910)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 910 (Use of Expired File Descriptor)
The product uses or accesses a file descriptor after it has been closed. Stale file descriptor
* Base Base - a 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. Improperly Controlled Modification of Dynamically-Determined Object Attributes - (915)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes)
The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified. Mass Assignment AutoBinding PHP Object Injection
* Base Base - a 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. Use of Unmaintained Third Party Components - (1104)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 1104 (Use of Unmaintained Third Party Components)
The product relies on third-party components that are not actively supported or maintained by the original developer or a trusted proxy for the original developer.
* Base Base - a 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. Application-Level Admin Tool with Inconsistent View of Underlying Operating System - (1249)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 1249 (Application-Level Admin Tool with Inconsistent View of Underlying Operating System)
The product provides an application for administrators to manage parts of the underlying operating system, but the application does not accurately identify all of the relevant entities or resources that exist in the OS; that is, the application's model of the OS's state is inconsistent with the OS's actual state. Ghost in the Shell
* Base Base - a 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. Mirrored Regions with Different Values - (1251)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 1251 (Mirrored Regions with Different Values)
The product's architecture mirrors regions without ensuring that their contents always stay in sync.
* Base Base - a 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. Firmware Not Updateable - (1277)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 1277 (Firmware Not Updateable)
The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.
* Base Base - a 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. Missing Ability to Patch ROM Code - (1310)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 1310 (Missing Ability to Patch ROM Code)
Missing an ability to patch ROM code may leave a System or System-on-Chip (SoC) in a vulnerable state.
* Variant Variant - 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. Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') - (1321)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 1321 (Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'))
The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.
* Base Base - a 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. Reliance on Component That is Not Updateable - (1329)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1415 (Comprehensive Categorization: Resource Control) > 1329 (Reliance on Component That is Not Updateable)
The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Resource Lifecycle Management - (1416)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management)
Weaknesses in this category are related to resource lifecycle management.
* Variant Variant - 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. Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') - (98)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 98 (Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion'))
The PHP application receives input from an upstream component, but it does not restrict or incorrectly restricts the input before its usage in "require," "include," or similar functions. Remote file include RFI Local file inclusion
* Class Class - a weakness that is 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. Incorrect Access of Indexable Resource ('Range Error') - (118)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 118 (Incorrect Access of Indexable Resource ('Range Error'))
The product does not restrict or incorrectly restricts operations within the boundaries of a resource that is accessed using an index or pointer, such as memory or files.
* Base Base - a 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. Improper Handling of Case Sensitivity - (178)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 178 (Improper Handling of Case Sensitivity)
The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
* Variant Variant - 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. Integer Coercion Error - (192)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 192 (Integer Coercion Error)
Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types.
* Variant Variant - 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. Unexpected Sign Extension - (194)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 194 (Unexpected Sign Extension)
The product performs an operation on a number that causes it to be sign extended when it is transformed into a larger data type. When the original number is negative, this can produce unexpected values that lead to resultant weaknesses.
* Variant Variant - 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. Signed to Unsigned Conversion Error - (195)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 195 (Signed to Unsigned Conversion Error)
The product uses a signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive.
* Variant Variant - 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. Unsigned to Signed Conversion Error - (196)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 196 (Unsigned to Signed Conversion Error)
The product uses an unsigned primitive and performs a cast to a signed primitive, which can produce an unexpected value if the value of the unsigned primitive can not be represented using a signed primitive.
* Base Base - a 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. Numeric Truncation Error - (197)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 197 (Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
* Base Base - a 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. Improper Removal of Sensitive Information Before Storage or Transfer - (212)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 212 (Improper Removal of Sensitive Information Before Storage or Transfer)
The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
* Class Class - a weakness that is 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. Information Loss or Omission - (221)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 221 (Information Loss or Omission)
The product does not record, or improperly records, security-relevant information that leads to an incorrect decision or hampers later analysis.
* Base Base - a 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. Sensitive Information in Resource Not Removed Before Reuse - (226)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 226 (Sensitive Information in Resource Not Removed Before Reuse)
The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.
* Variant Variant - 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. Creation of chroot Jail Without Changing Working Directory - (243)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 243 (Creation of chroot Jail Without Changing Working Directory)
The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
* Base Base - a 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. Incomplete Internal State Distinction - (372)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 372 (Incomplete Internal State Distinction)
The product does not properly determine which state it is in, causing it to assume it is in state X when in fact it is in state Y, causing it to perform incorrect operations in a security-relevant manner.
* Base Base - a 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. Symbolic Name not Mapping to Correct Object - (386)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 386 (Symbolic Name not Mapping to Correct Object)
A constant symbolic reference to an object is used, even though the reference can resolve to a different object over time.
* Class Class - a weakness that is 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. Uncontrolled Resource Consumption - (400)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 400 (Uncontrolled Resource Consumption)
The product does not properly control the allocation and maintenance of a limited resource. Resource Exhaustion
* Class Class - a weakness that is 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. Improper Resource Shutdown or Release - (404)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 404 (Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
* Class Class - a weakness that is 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. Asymmetric Resource Consumption (Amplification) - (405)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 405 (Asymmetric Resource Consumption (Amplification))
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
* Class Class - a weakness that is 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. Insufficient Control of Network Message Volume (Network Amplification) - (406)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 406 (Insufficient Control of Network Message Volume (Network Amplification))
The product does not sufficiently monitor or control transmitted network traffic volume, so that an actor can cause the product to transmit more traffic than should be allowed for that actor.
* Class Class - a weakness that is 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. Inefficient Algorithmic Complexity - (407)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 407 (Inefficient Algorithmic Complexity)
An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached. Quadratic Complexity
* Base Base - a 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. Improper Handling of Highly Compressed Data (Data Amplification) - (409)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 409 (Improper Handling of Highly Compressed Data (Data Amplification))
The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
* Class Class - a weakness that is 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. Insufficient Resource Pool - (410)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 410 (Insufficient Resource Pool)
The product's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.
* Base Base - a 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. Unrestricted Upload of File with Dangerous Type - (434)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 434 (Unrestricted Upload of File with Dangerous Type)
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment. Unrestricted File Upload
* Variant Variant - 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. Insecure Default Variable Initialization - (453)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 453 (Insecure Default Variable Initialization)
The product, by default, initializes an internal variable with an insecure or less secure value than is possible.
* Base Base - a 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. External Initialization of Trusted Variables or Data Stores - (454)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 454 (External Initialization of Trusted Variables or Data Stores)
The product initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.
* Variant Variant - 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. Missing Initialization of a Variable - (456)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 456 (Missing Initialization of a Variable)
The product does not initialize critical variables, which causes the execution environment to use unexpected values.
* Variant Variant - 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. Use of Uninitialized Variable - (457)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 457 (Use of Uninitialized Variable)
The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
* Base Base - a 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. Incomplete Cleanup - (459)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 459 (Incomplete Cleanup)
The product does not properly "clean up" and remove temporary or supporting resources after they have been used. Insufficient Cleanup
* Base Base - a 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. Improper Cleanup on Thrown Exception - (460)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 460 (Improper Cleanup on Thrown Exception)
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
* Base Base - a 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. Modification of Assumed-Immutable Data (MAID) - (471)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 471 (Modification of Assumed-Immutable Data (MAID))
The product does not properly protect an assumed-immutable element from being modified by an attacker.
* Base Base - a 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. Reliance on Package-level Scope - (487)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 487 (Reliance on Package-level Scope)
Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.
* Variant Variant - 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. Private Data Structure Returned From A Public Method - (495)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 495 (Private Data Structure Returned From A Public Method)
The product has a method that is declared public, but returns a reference to a private data structure, which could then be modified in unexpected ways.
* Variant Variant - 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. Public Data Assigned to Private Array-Typed Field - (496)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 496 (Public Data Assigned to Private Array-Typed Field)
Assigning public data to a private array is equivalent to giving public access to the array.
* Base Base - a 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. Trust Boundary Violation - (501)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 501 (Trust Boundary Violation)
The product mixes trusted and untrusted data in the same data structure or structured message.
* Variant Variant - 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. finalize() Method Without super.finalize() - (568)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 568 (finalize() Method Without super.finalize())
The product contains a finalize() method that does not call super.finalize().
* Variant Variant - 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. clone() Method Without super.clone() - (580)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 580 (clone() Method Without super.clone())
The product contains a clone() method that does not call super.clone() to obtain the new object.
* Variant Variant - 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. Attempt to Access Child of a Non-structure Pointer - (588)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 588 (Attempt to Access Child of a Non-structure Pointer)
Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption.
* Variant Variant - 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. Public Static Final Field References Mutable Object - (607)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 607 (Public Static Final Field References Mutable Object)
A public or protected static final field references a mutable object, which allows the object to be changed by malicious code, or accidentally from another package.
* Class Class - a weakness that is 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. Externally Controlled Reference to a Resource in Another Sphere - (610)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 610 (Externally Controlled Reference to a Resource in Another Sphere)
The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
* Variant Variant - 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. Exposed Unsafe ActiveX Method - (618)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 618 (Exposed Unsafe ActiveX Method)
An ActiveX control is intended for use in a web browser, but it exposes dangerous methods that perform actions that are outside of the browser's security model (e.g. the zone or domain).
* Class Class - a weakness that is 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. Improper Synchronization - (662)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 662 (Improper Synchronization)
The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
* Pillar Pillar - a weakness that 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. Improper Control of a Resource Through its Lifetime - (664)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 664 (Improper Control of a Resource Through its Lifetime)
The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
* Class Class - a weakness that is 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. Improper Initialization - (665)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 665 (Improper Initialization)
The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
* Class Class - a weakness that is 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. Operation on Resource in Wrong Phase of Lifetime - (666)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 666 (Operation on Resource in Wrong Phase of Lifetime)
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
* Class Class - a weakness that is 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. Incorrect Resource Transfer Between Spheres - (669)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 669 (Incorrect Resource Transfer Between Spheres)
The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.
* Class Class - a weakness that is 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. External Influence of Sphere Definition - (673)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 673 (External Influence of Sphere Definition)
The product does not prevent the definition of control spheres from external actors.
* Base Base - a 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. Incorrect Conversion between Numeric Types - (681)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 681 (Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
* Class Class - a weakness that is 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. Incorrect Type Conversion or Cast - (704)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 704 (Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
* Class Class - a weakness that is 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. Use of Incorrectly-Resolved Name or Reference - (706)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 706 (Use of Incorrectly-Resolved Name or Reference)
The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
* Base Base - a 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. Exposed Dangerous Method or Function - (749)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 749 (Exposed Dangerous Method or Function)
The product provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.
* Base Base - a 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. Allocation of Resources Without Limits or Throttling - (770)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 770 (Allocation of Resources Without Limits or Throttling)
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
* Base Base - a 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. Missing Reference to Active Allocated Resource - (771)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 771 (Missing Reference to Active Allocated Resource)
The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.
* Base Base - a 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. Missing Release of Resource after Effective Lifetime - (772)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 772 (Missing Release of Resource after Effective Lifetime)
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
* Variant Variant - 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. Missing Reference to Active File Descriptor or Handle - (773)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 773 (Missing Reference to Active File Descriptor or Handle)
The product does not properly maintain references to a file descriptor or handle, which prevents that file descriptor/handle from being reclaimed.
* Variant Variant - 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. Allocation of File Descriptors or Handles Without Limits or Throttling - (774)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 774 (Allocation of File Descriptors or Handles Without Limits or Throttling)
The product allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor. File Descriptor Exhaustion
* Variant Variant - 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. Missing Release of File Descriptor or Handle after Effective Lifetime - (775)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 775 (Missing Release of File Descriptor or Handle after Effective Lifetime)
The product does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.
* Base Base - a 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. Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') - (776)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 776 (Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion'))
The product uses XML documents and allows their structure to be defined with a Document Type Definition (DTD), but it does not properly control the number of recursive definitions of entities. XEE Billion Laughs Attack XML Bomb
* Base Base - a 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. Logging of Excessive Data - (779)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 779 (Logging of Excessive Data)
The product logs too much information, making log files hard to process and possibly hindering recovery efforts or forensic analysis after an attack.
* Variant Variant - 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. Exposed IOCTL with Insufficient Access Control - (782)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 782 (Exposed IOCTL with Insufficient Access Control)
The product implements an IOCTL with functionality that should be restricted, but it does not properly enforce access control for the IOCTL.
* Variant Variant - 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. Improper Control of Document Type Definition - (827)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 827 (Improper Control of Document Type Definition)
The product does not restrict a reference to a Document Type Definition (DTD) to the intended control sphere. This might allow attackers to reference arbitrary DTDs, possibly causing the product to expose files, consume excessive system resources, or execute arbitrary http requests on behalf of the attacker.
* Base Base - a 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. Inclusion of Functionality from Untrusted Control Sphere - (829)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 829 (Inclusion of Functionality from Untrusted Control Sphere)
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
* Variant Variant - 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. Inclusion of Web Functionality from an Untrusted Source - (830)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 830 (Inclusion of Web Functionality from an Untrusted Source)
The product includes web functionality (such as a web widget) from another domain, which causes it to operate within the domain of the product, potentially granting total access and control of the product to the untrusted source.
* Base Base - a 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. Access of Resource Using Incompatible Type ('Type Confusion') - (843)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 843 (Access of Resource Using Incompatible Type ('Type Confusion'))
The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type. Object Type Confusion
* Base Base - a 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. Use of Uninitialized Resource - (908)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 908 (Use of Uninitialized Resource)
The product uses or accesses a resource that has not been initialized.
* Class Class - a weakness that is 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. Missing Initialization of Resource - (909)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 909 (Missing Initialization of Resource)
The product does not initialize a critical resource.
* Base Base - a 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. Improper Update of Reference Count - (911)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 911 (Improper Update of Reference Count)
The product uses a reference count to manage a resource, but it does not update or incorrectly updates the reference count.
* Class Class - a weakness that is 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. Improper Control of Dynamically-Managed Code Resources - (913)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 913 (Improper Control of Dynamically-Managed Code Resources)
The product does not properly restrict reading from or writing to dynamically-managed code resources such as variables, objects, classes, attributes, functions, or executable instructions or statements.
* Base Base - a 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. Improper Restriction of Power Consumption - (920)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 920 (Improper Restriction of Power Consumption)
The product operates in an environment in which power is a limited resource that cannot be automatically replenished, but the product does not properly restrict the amount of power that its operation consumes.
* Class Class - a weakness that is 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. Insecure Storage of Sensitive Information - (922)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 922 (Insecure Storage of Sensitive Information)
The product stores sensitive information without properly limiting read or write access by unauthorized actors.
* Variant Variant - 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. Static Member Data Element outside of a Singleton Class Element - (1042)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1042 (Static Member Data Element outside of a Singleton Class Element)
The code contains a member element that is declared as static (but not final), in which its parent class element is not a singleton class - that is, a class element that can be used only once in the 'to' association of a Create action.
* Base Base - a 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. Creation of Immutable Text Using String Concatenation - (1046)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1046 (Creation of Immutable Text Using String Concatenation)
The product creates an immutable text string using string concatenation operations.
* Base Base - a 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. Excessive Data Query Operations in a Large Data Table - (1049)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1049 (Excessive Data Query Operations in a Large Data Table)
The product performs a data query with a large number of joins and sub-queries on a large data table.
* Base Base - a 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. Excessive Platform Resource Consumption within a Loop - (1050)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1050 (Excessive Platform Resource Consumption within a Loop)
The product has a loop body or loop condition that contains a control element that directly or indirectly consumes platform resources, e.g. messaging, sessions, locks, or file descriptors.
* Base Base - a 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. Initialization with Hard-Coded Network Resource Configuration Data - (1051)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1051 (Initialization with Hard-Coded Network Resource Configuration Data)
The product initializes data using hard-coded values that act as network resource identifiers.
* Base Base - a 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. Excessive Use of Hard-Coded Literals in Initialization - (1052)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1052 (Excessive Use of Hard-Coded Literals in Initialization)
The product initializes a data element using a hard-coded literal that is not a simple integer or static constant element.
* Base Base - a 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. Creation of Class Instance within a Static Code Block - (1063)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1063 (Creation of Class Instance within a Static Code Block)
A static code block creates an instance of a class.
* Base Base - a 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. Excessive Execution of Sequential Searches of Data Resource - (1067)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1067 (Excessive Execution of Sequential Searches of Data Resource)
The product contains a data query against an SQL table or view that is configured in a way that does not utilize an index and may cause sequential searches to be performed.
* Base Base - a 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. Data Resource Access without Use of Connection Pooling - (1072)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1072 (Data Resource Access without Use of Connection Pooling)
The product accesses a data resource through a database without using a connection pooling capability.
* Base Base - a 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. Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses - (1073)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1073 (Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses)
The product contains a client with a function or method that contains a large number of data accesses/queries that are sent through a data manager, i.e., does not use efficient database capabilities.
* Base Base - a 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. Invokable Control Element with Excessive File or Data Access Operations - (1084)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1084 (Invokable Control Element with Excessive File or Data Access Operations)
A function or method contains too many operations that utilize a data manager or file resource.
* Base Base - a 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. Large Data Table with Excessive Number of Indices - (1089)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1089 (Large Data Table with Excessive Number of Indices)
The product uses a large data table that contains an excessively large number of indices.
* Base Base - a 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. Use of Object without Invoking Destructor Method - (1091)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1091 (Use of Object without Invoking Destructor Method)
The product contains a method that accesses an object but does not later invoke the element's associated finalize/destructor method.
* Base Base - a 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. Excessive Index Range Scan for a Data Resource - (1094)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1094 (Excessive Index Range Scan for a Data Resource)
The product contains an index range scan for a large data table, but the scan can cover a large number of rows.
* Class Class - a weakness that is 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. Inefficient CPU Computation - (1176)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1176 (Inefficient CPU Computation)
The product performs CPU computations using algorithms that are not as efficient as they could be for the needs of the developer, i.e., the computations can be optimized further.
* Base Base - a 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. Initialization of a Resource with an Insecure Default - (1188)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1188 (Initialization of a Resource with an Insecure Default)
The product initializes or sets a resource with a default that is intended to be changed by the administrator, but the default is not secure.
* Base Base - a 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. Incorrect Register Defaults or Module Parameters - (1221)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1221 (Incorrect Register Defaults or Module Parameters)
Hardware description language code incorrectly defines register defaults or hardware Intellectual Property (IP) parameters to insecure values.
* Class Class - a weakness that is 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. Creation of Emergent Resource - (1229)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1229 (Creation of Emergent Resource)
The product manages resources or behaves in a way that indirectly creates a new, distinct resource that can be used by attackers in violation of the intended policy.
* Base Base - a 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. Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations - (1235)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1235 (Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations)
The code uses boxed primitives, which may introduce inefficiencies into performance-critical operations.
* Variant Variant - 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. Improper Zeroization of Hardware Register - (1239)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1239 (Improper Zeroization of Hardware Register)
The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.
* Base Base - a 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. Improper Write Handling in Limited-write Non-Volatile Memories - (1246)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1246 (Improper Write Handling in Limited-write Non-Volatile Memories)
The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories.
* Base Base - a 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. Improper Preservation of Consistency Between Independent Representations of Shared State - (1250)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1250 (Improper Preservation of Consistency Between Independent Representations of Shared State)
The product has or supports multiple distributed components or sub-systems that are each required to keep their own local copy of shared data - such as state or cache - but the product does not ensure that all local copies remain consistent with each other.
* Base Base - a 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. Exposure of Sensitive System Information Due to Uncleared Debug Information - (1258)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1258 (Exposure of Sensitive System Information Due to Uncleared Debug Information)
The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.
* Base Base - a 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. Improper Scrubbing of Sensitive Data from Decommissioned Device - (1266)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1266 (Improper Scrubbing of Sensitive Data from Decommissioned Device)
The product does not properly provide a capability for the product administrator to remove sensitive data at the time the product is decommissioned. A scrubbing capability could be missing, insufficient, or incorrect.
* Base Base - a 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. Uninitialized Value on Reset for Registers Holding Security Settings - (1271)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1271 (Uninitialized Value on Reset for Registers Holding Security Settings)
Security-critical logic is not set to a known value on reset.
* Base Base - a 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. Sensitive Information Uncleared Before Debug/Power State Transition - (1272)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1272 (Sensitive Information Uncleared Before Debug/Power State Transition)
The product performs a power or debug state transition, but it does not clear sensitive information that should no longer be accessible due to changes to information access restrictions.
* Base Base - a 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. Cryptographic Operations are run Before Supporting Units are Ready - (1279)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1279 (Cryptographic Operations are run Before Supporting Units are Ready)
Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.
* Base Base - a 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. Insufficient or Incomplete Data Removal within Hardware Component - (1301)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1301 (Insufficient or Incomplete Data Removal within Hardware Component)
The product's data removal process does not completely delete all data and potentially sensitive information within hardware components.
* Base Base - a 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. Improperly Controlled Sequential Memory Allocation - (1325)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1325 (Improperly Controlled Sequential Memory Allocation)
The product manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects. Stack Exhaustion
* Variant Variant - 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. Remanent Data Readable after Memory Erase - (1330)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1330 (Remanent Data Readable after Memory Erase)
Confidential information stored in memory circuits is readable or recoverable after being cleared or erased.
* Base Base - a 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. Inefficient Regular Expression Complexity - (1333)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1333 (Inefficient Regular Expression Complexity)
The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles. ReDoS Regular Expression Denial of Service Catastrophic backtracking
* Base Base - a 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. Information Exposure through Microarchitectural State after Transient Execution - (1342)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1342 (Information Exposure through Microarchitectural State after Transient Execution)
The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.
* Base Base - a 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. Insecure Operation on Windows Junction / Mount Point - (1386)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1386 (Insecure Operation on Windows Junction / Mount Point)
The product opens a file or directory, but it does not properly prevent the name from being associated with a junction or mount point to a destination that is outside of the intended control sphere.
* Base Base - a 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. Incorrect Parsing of Numbers with Different Radices - (1389)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1389 (Incorrect Parsing of Numbers with Different Radices)
The product parses numeric input assuming base 10 (decimal) values, but it does not account for inputs that use a different base number (radix).
* Class Class - a weakness that is 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. Incorrect Initialization of Resource - (1419)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1419 (Incorrect Initialization of Resource)
The product attempts to initialize a resource but does not correctly do so, which might leave the resource in an unexpected, incorrect, or insecure state when it is accessed.
* Base Base - a 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. Exposure of Sensitive Information during Transient Execution - (1420)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1420 (Exposure of Sensitive Information during Transient Execution)
A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.
* Base Base - a 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. Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution - (1421)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1421 (Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution)
A processor event may allow transient operations to access architecturally restricted data (for example, in another address space) in a shared microarchitectural structure (for example, a CPU cache), potentially exposing the data over a covert channel.
* Base Base - a 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. Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution - (1422)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1422 (Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution)
A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.
* Base Base - a 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. Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution - (1423)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1416 (Comprehensive Categorization: Resource Lifecycle Management) > 1423 (Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution)
Shared microarchitectural predictor state may allow code to influence transient execution across a hardware boundary, potentially exposing data that is accessible beyond the boundary over a covert channel.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Sensitive Information Exposure - (1417)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure)
Weaknesses in this category are related to sensitive information exposure.
* Class Class - a weakness that is 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. Exposure of Sensitive Information to an Unauthorized Actor - (200)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 200 (Exposure of Sensitive Information to an Unauthorized Actor)
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. Information Disclosure Information Leak
* Base Base - a 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. Insertion of Sensitive Information Into Sent Data - (201)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 201 (Insertion of Sensitive Information Into Sent Data)
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
* Base Base - a 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. Observable Discrepancy - (203)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 203 (Observable Discrepancy)
The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not. Side Channel Attack
* Base Base - a 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. Observable Response Discrepancy - (204)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 204 (Observable Response Discrepancy)
The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.
* Base Base - a 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. Observable Behavioral Discrepancy - (205)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 205 (Observable Behavioral Discrepancy)
The product's behaviors indicate important differences that may be observed by unauthorized actors in a way that reveals (1) its internal state or decision process, or (2) differences from other products with equivalent functionality.
* Variant Variant - 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. Observable Internal Behavioral Discrepancy - (206)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 206 (Observable Internal Behavioral Discrepancy)
The product performs multiple behaviors that are combined to produce a single result, but the individual behaviors are observable separately in a way that allows attackers to reveal internal state or internal decision points.
* Variant Variant - 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. Observable Behavioral Discrepancy With Equivalent Products - (207)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 207 (Observable Behavioral Discrepancy With Equivalent Products)
The product operates in an environment in which its existence or specific identity should not be known, but it behaves differently than other products with equivalent functionality, in a way that is observable to an attacker.
* Base Base - a 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. Observable Timing Discrepancy - (208)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 208 (Observable Timing Discrepancy)
Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.
* Base Base - a 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. Generation of Error Message Containing Sensitive Information - (209)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 209 (Generation of Error Message Containing Sensitive Information)
The product generates an error message that includes sensitive information about its environment, users, or associated data.
* Base Base - a 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. Self-generated Error Message Containing Sensitive Information - (210)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 210 (Self-generated Error Message Containing Sensitive Information)
The product identifies an error condition and creates its own diagnostic or error messages that contain sensitive information.
* Base Base - a 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. Externally-Generated Error Message Containing Sensitive Information - (211)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 211 (Externally-Generated Error Message Containing Sensitive Information)
The product performs an operation that triggers an external diagnostic or error message that is not directly generated or controlled by the product, such as an error generated by the programming language interpreter that a software application uses. The error can contain sensitive system information.
* Base Base - a 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. Exposure of Sensitive Information Due to Incompatible Policies - (213)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 213 (Exposure of Sensitive Information Due to Incompatible Policies)
The product's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.
* Base Base - a 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. Invocation of Process Using Visible Sensitive Information - (214)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 214 (Invocation of Process Using Visible Sensitive Information)
A process is invoked with sensitive command-line arguments, environment variables, or other elements that can be seen by other processes on the operating system.
* Base Base - a 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. Insertion of Sensitive Information Into Debugging Code - (215)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 215 (Insertion of Sensitive Information Into Debugging Code)
The product inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.
* Base Base - a 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. Exposure of Private Personal Information to an Unauthorized Actor - (359)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 359 (Exposure of Private Personal Information to an Unauthorized Actor)
The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected. Privacy violation Privacy leak Privacy leakage
* Base Base - a 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. Exposure of Sensitive System Information to an Unauthorized Control Sphere - (497)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 497 (Exposure of Sensitive System Information to an Unauthorized Control Sphere)
The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.
* Variant Variant - 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. Cleartext Storage of Sensitive Information in an Environment Variable - (526)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 526 (Cleartext Storage of Sensitive Information in an Environment Variable)
The product uses an environment variable to store unencrypted sensitive information.
* Variant Variant - 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. Inclusion of Sensitive Information in Test Code - (531)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 531 (Inclusion of Sensitive Information in Test Code)
Accessible test applications can pose a variety of security risks. Since developers or administrators rarely consider that someone besides themselves would even know about the existence of these applications, it is common for them to contain sensitive information or functions.
* Base Base - a 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. Insertion of Sensitive Information into Log File - (532)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 532 (Insertion of Sensitive Information into Log File)
The product writes sensitive information to a log file.
* Variant Variant - 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. Exposure of Information Through Shell Error Message - (535)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 535 (Exposure of Information Through Shell Error Message)
A command shell error message indicates that there exists an unhandled exception in the web application code. In many cases, an attacker can leverage the conditions that cause these errors in order to gain unauthorized access to the system.
* Variant Variant - 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. Servlet Runtime Error Message Containing Sensitive Information - (536)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 536 (Servlet Runtime Error Message Containing Sensitive Information)
A servlet error message indicates that there exists an unhandled exception in your web application code and may provide useful information to an attacker.
* Variant Variant - 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. Java Runtime Error Message Containing Sensitive Information - (537)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 537 (Java Runtime Error Message Containing Sensitive Information)
In many cases, an attacker can leverage the conditions that cause unhandled exception errors in order to gain unauthorized access to the system.
* Base Base - a 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. Insertion of Sensitive Information into Externally-Accessible File or Directory - (538)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 538 (Insertion of Sensitive Information into Externally-Accessible File or Directory)
The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.
* Base Base - a 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. Inclusion of Sensitive Information in Source Code - (540)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 540 (Inclusion of Sensitive Information in Source Code)
Source code on a web server or repository often contains sensitive information and should generally not be accessible to users.
* Variant Variant - 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. Inclusion of Sensitive Information in an Include File - (541)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 541 (Inclusion of Sensitive Information in an Include File)
If an include file source is accessible, the file can contain usernames and passwords, as well as sensitive information pertaining to the application and system.
* Variant Variant - 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. Exposure of Information Through Directory Listing - (548)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 548 (Exposure of Information Through Directory Listing)
The product inappropriately exposes a directory listing with an index of all the resources located inside of the directory.
* Variant Variant - 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. Server-generated Error Message Containing Sensitive Information - (550)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 550 (Server-generated Error Message Containing Sensitive Information)
Certain conditions, such as network failure, will cause a server error message to be displayed.
* Variant Variant - 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. Use of GET Request Method With Sensitive Query Strings - (598)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 598 (Use of GET Request Method With Sensitive Query Strings)
The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request.
* Variant Variant - 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. Inclusion of Sensitive Information in Source Code Comments - (615)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 615 (Inclusion of Sensitive Information in Source Code Comments)
While adding general comments is very useful, some programmers tend to leave important data, such as: filenames related to the web application, old links or links which were not meant to be browsed by users, old code fragments, etc.
* Variant Variant - 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. Exposure of WSDL File Containing Sensitive Information - (651)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 651 (Exposure of WSDL File Containing Sensitive Information)
The Web services architecture may require exposing a Web Service Definition Language (WSDL) file that contains information on the publicly accessible services and how callers of these services should interact with them (e.g. what parameters they expect and what types they return).
* Base Base - a 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. Incorrect Comparison Logic Granularity - (1254)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 1254 (Incorrect Comparison Logic Granularity)
The product's comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.
* Variant Variant - 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. Comparison Logic is Vulnerable to Power Side-Channel Attacks - (1255)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 1255 (Comparison Logic is Vulnerable to Power Side-Channel Attacks)
A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.
* Base Base - a 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. Device Unlock Credential Sharing - (1273)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 1273 (Device Unlock Credential Sharing)
The credentials necessary for unlocking a device are shared across multiple parties and may expose sensitive information.
* Base Base - a 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. Debug Messages Revealing Unnecessary Information - (1295)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 1295 (Debug Messages Revealing Unnecessary Information)
The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.
* Base Base - a 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. Improper Protection of Physical Side Channels - (1300)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 1300 (Improper Protection of Physical Side Channels)
The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.
* Base Base - a 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. Driving Intermediate Cryptographic State/Results to Hardware Module Outputs - (1431)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1417 (Comprehensive Categorization: Sensitive Information Exposure) > 1431 (Driving Intermediate Cryptographic State/Results to Hardware Module Outputs)
The product uses a hardware module implementing a cryptographic algorithm that writes sensitive information about the intermediate state or results of its cryptographic operations via one of its output wires (typically the output port containing the final result).
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Comprehensive Categorization: Violation of Secure Design Principles - (1418)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles)
Weaknesses in this category are related to violation of secure design principles.
* Base Base - a 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. Execution with Unnecessary Privileges - (250)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 250 (Execution with Unnecessary Privileges)
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
* Class Class - a weakness that is 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. Improper Protection of Alternate Path - (424)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 424 (Improper Protection of Alternate Path)
The product does not sufficiently protect all possible paths that a user can take to access restricted functionality or resources.
* Base Base - a 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. Unimplemented or Unsupported Feature in UI - (447)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 447 (Unimplemented or Unsupported Feature in UI)
A UI function for a security feature appears to be supported and gives feedback to the user that suggests that it is supported, but the underlying functionality is not implemented.
* Class Class - a weakness that is 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. Not Failing Securely ('Failing Open') - (636)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 636 (Not Failing Securely ('Failing Open'))
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions. Failing Open
* Class Class - a weakness that is 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. Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism') - (637)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 637 (Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism'))
The product uses a more complex mechanism than necessary, which could lead to resultant weaknesses when the mechanism is not correctly understood, modeled, configured, implemented, or used. Unnecessary Complexity
* Class Class - a weakness that is 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. Not Using Complete Mediation - (638)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 638 (Not Using Complete Mediation)
The product does not perform access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity's rights or privileges change over time.
* Class Class - a weakness that is 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. Improper Isolation or Compartmentalization - (653)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 653 (Improper Isolation or Compartmentalization)
The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions. Separation of Privilege
* Base Base - a 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. Reliance on a Single Factor in a Security Decision - (654)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 654 (Reliance on a Single Factor in a Security Decision)
A protection mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality. Separation of Privilege
* Class Class - a weakness that is 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. Insufficient Psychological Acceptability - (655)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 655 (Insufficient Psychological Acceptability)
The product has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.
* Class Class - a weakness that is 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. Reliance on Security Through Obscurity - (656)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 656 (Reliance on Security Through Obscurity)
The product uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism. Never Assuming your secrets are safe
* Class Class - a weakness that is 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. Violation of Secure Design Principles - (657)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 657 (Violation of Secure Design Principles)
The product violates well-established principles for secure design.
* Class Class - a weakness that is 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. Lack of Administrator Control over Security - (671)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 671 (Lack of Administrator Control over Security)
The product uses security features in a way that prevents the product's administrator from tailoring security settings to reflect the environment in which the product is being used. This introduces resultant weaknesses or prevents it from operating at a level of security that is desired by the administrator.
* Base Base - a 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. Improper Isolation of Shared Resources on System-on-a-Chip (SoC) - (1189)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 1189 (Improper Isolation of Shared Resources on System-on-a-Chip (SoC))
The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.
* Base Base - a 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. Improper Identifier for IP Block used in System-On-Chip (SOC) - (1192)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 1192 (Improper Identifier for IP Block used in System-On-Chip (SOC))
The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.
* Base Base - a 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. Non-Transparent Sharing of Microarchitectural Resources - (1303)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 1303 (Non-Transparent Sharing of Microarchitectural Resources)
Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.
* Base Base - a 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. Improper Isolation of Shared Resources in Network On Chip (NoC) - (1331)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 1331 (Improper Isolation of Shared Resources in Network On Chip (NoC))
The Network On Chip (NoC) does not isolate or incorrectly isolates its on-chip-fabric and internal resources such that they are shared between trusted and untrusted agents, creating timing channels.
* Class Class - a weakness that is 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. Dependency on Vulnerable Third-Party Component - (1395)
1400 (Comprehensive Categorization for Software Assurance Trends) > 1418 (Comprehensive Categorization: Violation of Secure Design Principles) > 1395 (Dependency on Vulnerable Third-Party Component)
The product has a dependency on a third-party component that contains one or more known vulnerabilities.
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: View

Rationale:

This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.

Comments:

Use this View or other Views to search and navigate for the appropriate weakness.
+ Notes

Relationship

This view is different than the software development view (CWE-699) because this view is expected to include all weaknesses regardless of abstraction, while view 699 uses a largely-fixed Base level of abstraction related only to software weaknesses. It is different from the Research view (CWE-1000) because while comprehensive for all weaknesses, the view uses a deep hierarchical structure and excludes categories.
+ View Metrics
CWEs in this view Total CWEs
Weaknesses 943 out of 943
Categories 22 out of 374
Views 0 out of 51
Total 965 out of 1368
+ Content History
+ Submissions
Submission Date Submitter Organization
2023-04-25
(CWE 4.11, 2023-04-23)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

View Components

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-36: Absolute Path Traversal

Weakness ID: 36
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory.
+ Extended Description
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Execute Unauthorized Code or Commands

Scope: Integrity, Confidentiality, Availability

The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.

Modify Files or Directories

Scope: Integrity

The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.

Read Files or Directories

Scope: Confidentiality

The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.

DoS: Crash, Exit, or Restart

Scope: Availability

The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the product.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
ParentOf Variant Variant - 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. 37 Path Traversal: '/absolute/pathname/here'
ParentOf Variant Variant - 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. 38 Path Traversal: '\absolute\pathname\here'
ParentOf Variant Variant - 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. 39 Path Traversal: 'C:dirname'
ParentOf Variant Variant - 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. 40 Path Traversal: '\\UNC\share\name\' (Windows UNC Share)
+ Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Nature Type ID Name
ChildOf Base Base - a 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. 22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
+ Relevant to the view "CISQ Data Protection Measures" (View-1340)
Nature Type ID Name
ChildOf Base Base - a 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. 22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


In the example below, the path to a dictionary file is read from a system property and used to initialize a File object.

(bad code)
Example Language: Java 
String filename = System.getProperty("com.domain.application.dictionaryFile");
File dictionaryFile = new File(filename);

However, the path is not validated or modified to prevent it from containing relative or absolute path sequences before creating the File object. This allows anyone who can control the system property to determine what file is used. Ideally, the path should be resolved relative to some kind of application or user home directory.



Example 2


This script intends to read a user-supplied file from the current directory. The user inputs the relative path to the file and the script uses Python's os.path.join() function to combine the path to the current working directory with the provided path to the specified file. This results in an absolute path to the desired file. If the file does not exist when the script attempts to read it, an error is printed to the user.

(bad code)
Example Language: Python 
import os
import sys
def main():
filename = sys.argv[1]
path = os.path.join(os.getcwd(), filename)
try:
with open(path, 'r') as f:
file_data = f.read()
except FileNotFoundError as e:
print("Error - file not found")
main()

However, if the user supplies an absolute path, the os.path.join() function will discard the path to the current working directory and use only the absolute path provided. For example, if the current working directory is /home/user/documents, but the user inputs /etc/passwd, os.path.join() will use only /etc/passwd, as it is considered an absolute path. In the above scenario, this would cause the script to access and read the /etc/passwd file.

(good code)
Example Language: Python 
import os
import sys
def main():
filename = sys.argv[1]
path = os.path.normpath(f"{os.getcwd()}{os.sep}{filename}")
if path.startswith("/home/cwe/documents/"):
try:
with open(path, 'r') as f:
file_data = f.read()
except FileNotFoundError as e:
print("Error - file not found")
main()

The constructed path string uses os.sep to add the appropriate separation character for the given operating system (e.g. '\' or '/') and the call to os.path.normpath() removes any additional slashes that may have been entered - this may occur particularly when using a Windows path. The path is checked against an expected directory (/home/cwe/documents); otherwise, an attacker could provide relative path sequences like ".." to cause normpath() to generate paths that are outside the intended directory (CWE-23). By putting the pieces of the path string together in this fashion, the script avoids a call to os.path.join() and any potential issues that might arise if an absolute path is entered. With this version of the script, if the current working directory is /home/cwe/documents, and the user inputs /etc/passwd, the resulting path will be /home/cwe/documents/etc/passwd. The user is therefore contained within the current working directory as intended.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Python package constructs filenames using an unsafe os.path.join call on untrusted input, allowing absolute path traversal because os.path.join resets the pathname to an absolute path that is specified as part of the input.
Multiple FTP clients write arbitrary files via absolute paths in server responses
ZIP file extractor allows full path
Path traversal using absolute pathname
Path traversal using absolute pathname
Path traversal using absolute pathname
Arbitrary files may be overwritten via compressed attachments that specify absolute path names for the decompressed output.
Mail client allows remote attackers to overwrite arbitrary files via an e-mail message containing a uuencoded attachment that specifies the full pathname for the file to be modified.
Remote attackers can read arbitrary files via a full pathname to the target file in config parameter.
Remote attackers can read arbitrary files via an absolute pathname.
Remote attackers can read arbitrary files by specifying the drive letter in the requested URL.
FTP server allows remote attackers to list arbitrary directories by using the "ls" command and including the drive letter name (e.g. C:) in the requested pathname.
FTP server allows remote attackers to list the contents of arbitrary drives via a ls command that includes the drive letter as an argument.
Server allows remote attackers to browse arbitrary directories via a full pathname in the arguments to certain dynamic pages.
Remote attackers can read arbitrary files via an HTTP request whose argument is a filename of the form "C:" (Drive letter), "//absolute/path", or ".." .
FTP server read/access arbitrary files using "C:\" filenames
FTP server allows a remote attacker to retrieve privileged web server system information by specifying arbitrary paths in the UNC format (\\computername\sharename).
+ Detection Methods
Method Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 981 SFP Secondary Cluster: Path Traversal
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1404 Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Absolute Path Traversal
Software Fault Patterns SFP16 Path Traversal
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Filenames and Paths", Page 503. 1st Edition. Addison Wesley. 2006.
[REF-1448] Cybersecurity and Infrastructure Security Agency. "Secure by Design Alert: Eliminating Directory Traversal Vulnerabilities in Software". 2024-05-02.
<https://www.cisa.gov/resources-tools/resources/secure-design-alert-eliminating-directory-traversal-vulnerabilities-software>. (URL validated: 2024-07-14)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Demonstrative_Examples
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated References
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Demonstrative_Examples, Detection_Factors, Relationships, Time_of_Introduction
2023-01-31 CWE Content Team MITRE
updated Common_Consequences, Description
2022-10-13 CWE Content Team MITRE
updated Observed_Examples
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms
2017-01-19 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-06-21 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2010-02-16 CWE Content Team MITRE
updated Demonstrative_Examples
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples

CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data

Weakness ID: 349
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism; Modify Application Data

Scope: Access Control, Integrity

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 345 Insufficient Verification of Data Authenticity
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1214 Data Integrity Issues
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Does not verify that trusted entity is authoritative for all entities in its response.
use of extra data in a signature allows certificate signature forging
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 860 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1150 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1365 ICS Communications: Unreliability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1373 ICS Engineering (Construction/Deployment): Trust Model Problems
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1411 Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Untrusted Data Appended with Trusted Data
The CERT Oracle Secure Coding Standard for Java (2011) ENV01-J Place all security-sensitive code in a single JAR and sign and seal it
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-01-31 CWE Content Team MITRE
updated Description
2022-04-28 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Observed_Examples, Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Untrusted Data Appended with Trusted Data

CWE-1280: Access Control Check Implemented After Asset is Accessed

Weakness ID: 1280
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A product's hardware-based access control check occurs after the asset has been accessed.
+ Extended Description

The product implements a hardware-based access control check. The asset should be accessible only after the check is successful. If, however, this operation is not atomic and the asset is accessed before the check is complete, the security of the system may be compromised.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Modify Memory; Read Memory; Modify Application Data; Read Application Data; Gain Privileges or Assume Identity; Bypass Protection Mechanism

Scope: Access Control, Confidentiality, Integrity

+ Potential Mitigations
Phase(s) Mitigation

Implementation

Implement the access control check first. Access should only be given to asset if agent is authorized.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that 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. 284 Improper Access Control
ChildOf Class Class - a weakness that is 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. 696 Incorrect Behavior Order
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1198 Privilege Separation and Access Control Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access.

(bad code)
Example Language: Verilog 
module foo_bar(data_out, usr_id, data_in, clk, rst_n);
output reg [7:0] data_out;
input wire [2:0] usr_id;
input wire [7:0] data_in;
input wire clk, rst_n;
wire grant_access;
always @ (posedge clk or negedge rst_n)
begin
if (!rst_n)
data_out = 0;
else
data_out = (grant_access) ? data_in : data_out;
assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;
end
endmodule

This code uses Verilog blocking assignments for data_out and grant_access. Therefore, these assignments happen sequentially (i.e., data_out is updated to new value first, and grant_access is updated the next cycle) and not in parallel. Therefore, the asset data_out is allowed to be modified even before the access control check is complete and grant_access signal is set. Since grant_access does not have a reset value, it will be meta-stable and will randomly go to either 0 or 1.

Flipping the order of the assignment of data_out and grant_access should solve the problem. The correct snippet of code is shown below.

(good code)
Example Language: Verilog 
always @ (posedge clk or negedge rst_n)
begin
if (!rst_n)
data_out = 0;
else
assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;
data_out = (grant_access) ? data_in : data_out;
end
endmodule


+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1410 Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-02-12
(CWE 4.1, 2020-02-24)
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples
2020-08-20 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Related_Attack_Patterns

CWE-788: Access of Memory Location After End of Buffer

Weakness ID: 788
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.
+ Extended Description
This typically occurs when a pointer or its index is incremented to a position after the buffer; or when pointer arithmetic results in a position after the buffer.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Read Memory

Scope: Confidentiality

For an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffer's position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.

Modify Memory; DoS: Crash, Exit, or Restart

Scope: Integrity, Availability

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Modify Memory; Execute Unauthorized Code or Commands

Scope: Integrity

If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf Variant Variant - 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. 121 Stack-based Buffer Overflow
ParentOf Variant Variant - 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. 122 Heap-based Buffer Overflow
ParentOf Variant Variant - 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. 126 Buffer Over-read
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1218 Memory Buffer Errors
+ Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Relevant to the view "CISQ Data Protection Measures" (View-1340)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

C (Often Prevalent)

C++ (Often Prevalent)

+ Demonstrative Examples

Example 1


This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)
Example Language:
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);
}

This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476).



Example 2


In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

(bad code)
Example Language:
int returnChunkSize(void *) {

/* if chunk info is valid, return the size of usable memory,

* else, return -1 to indicate an error

*/
...
}
int main() {
...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...
}

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).



Example 3


This example applies an encoding procedure to an input string and stores it into a buffer.

(bad code)
Example Language:
char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);
if ( MAX_SIZE <= strlen(user_supplied_string) ){
die("user string too long, die evil hacker!");
}
dst_index = 0;
for ( i = 0; i < strlen(user_supplied_string); i++ ){
if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&';
dst_buf[dst_index++] = 'a';
dst_buf[dst_index++] = 'm';
dst_buf[dst_index++] = 'p';
dst_buf[dst_index++] = ';';
}
else if ('<' == user_supplied_string[i] ){

/* encode to &lt; */
}
else dst_buf[dst_index++] = user_supplied_string[i];
}
return dst_buf;
}

The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.



Example 4


In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.

(bad code)
Example Language:
int processMessageFromSocket(int socket) {
int success;

char buffer[BUFFER_SIZE];
char message[MESSAGE_SIZE];

// get message from socket and store into buffer

//Ignoring possibliity that buffer > BUFFER_SIZE
if (getMessage(socket, buffer, BUFFER_SIZE) > 0) {

// place contents of the buffer into message structure
ExMessage *msg = recastBuffer(buffer);

// copy message body into string for processing
int index;
for (index = 0; index < msg->msgLength; index++) {
message[index] = msg->msgBody[index];
}
message[index] = '\0';

// process message
success = processMessage(message);
}
return success;
}

However, the message length variable from the structure is used as the condition for ending the for loop without validating that the message length variable accurately reflects the length of the message body (CWE-606). This can result in a buffer over-read (CWE-125) by reading from memory beyond the bounds of the buffer if the message length variable indicates a length that is longer than the size of a message body (CWE-130).



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Classic stack-based buffer overflow in media player using a long entry in a playlist
Heap-based buffer overflow in media player using a long entry in a playlist
large precision value in a format string triggers overflow
attacker-controlled array index leads to code execution
OS kernel trusts userland-supplied length value, allowing reading of sensitive information
Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
+ Detection Methods
Method Details

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1129 CISQ Quality Measures (2016) - Reliability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1399 Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes
Usage DISCOURAGED
(this CWE ID should not be used to map to real-world vulnerabilities)
Reasons Potential Deprecation, Frequent Misuse

Rationale

The CWE entry might be misused when lower-level CWE entries might be available. It also overlaps existing CWE entries and might be deprecated in the future.

Comments

If the "Access" operation is known to be a read or a write, then investigate children of entries such as CWE-787: Out-of-bounds Write and CWE-125: Out-of-bounds Read.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
OMG ASCRM ASCRM-CWE-788
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-788. 2016-01.
<http://www.omg.org/spec/ASCRM/1.0/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2009-10-21
(CWE 1.6, 2009-10-29)
CWE Content Team MITRE
+ Contributions
Contribution Date Contributor Organization
2022-02-23 Eric Constantin Brinz GENIA-SEC IT-Sicherheitsmanagement GmbH
Suggested corrections to extended description.
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Applicable_Platforms
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Common_Consequences
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2022-04-28 CWE Content Team MITRE
updated Description
2021-07-20 CWE Content Team MITRE
updated Demonstrative_Examples
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Demonstrative_Examples
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples
2017-05-03 CWE Content Team MITRE
updated Description
2015-12-07 CWE Content Team MITRE
updated Description
2014-06-23 CWE Content Team MITRE
updated Demonstrative_Examples
2013-02-21 CWE Content Team MITRE
updated Demonstrative_Examples
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences

CWE-786: Access of Memory Location Before Start of Buffer

Weakness ID: 786
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
+ Extended Description
This typically occurs when a pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Read Memory

Scope: Confidentiality

For an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffer's position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.

Modify Memory; DoS: Crash, Exit, or Restart

Scope: Integrity, Availability

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash.

Modify Memory; Execute Unauthorized Code or Commands

Scope: Integrity

If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code. If the corrupted memory is data rather than instructions, the system will continue to function with improper changes, possibly in violation of an implicit or explicit policy.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf Base Base - a 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. 124 Buffer Underwrite ('Buffer Underflow')
ParentOf Variant Variant - 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. 127 Buffer Under-read
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1218 Memory Buffer Errors
+ Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Relevant to the view "CISQ Data Protection Measures" (View-1340)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

C (Often Prevalent)

C++ (Often Prevalent)

+ Demonstrative Examples

Example 1


In the following C/C++ example, a utility function is used to trim trailing whitespace from a character string. The function copies the input string to a local character string and uses a while statement to remove the trailing whitespace by moving backward through the string and overwriting whitespace with a NUL character.

(bad code)
Example Language:
char* trimTrailingWhitespace(char *strMessage, int length) {
char *retMessage;
char *message = malloc(sizeof(char)*(length+1));

// copy input string to a temporary string
char message[length+1];
int index;
for (index = 0; index < length; index++) {
message[index] = strMessage[index];
}
message[index] = '\0';

// trim trailing whitespace
int len = index-1;
while (isspace(message[len])) {
message[len] = '\0';
len--;
}

// return string without trailing whitespace
retMessage = message;
return retMessage;
}

However, this function can cause a buffer underwrite if the input character string contains all whitespace. On some systems the while statement will move backwards past the beginning of a character string and will call the isspace() function on an address outside of the bounds of the local buffer.



Example 2


The following example asks a user for an offset into an array to select an item.

(bad code)
Example Language:

int main (int argc, char **argv) {
char *items[] = {"boat", "car", "truck", "train"};
int index = GetUntrustedOffset();
printf("You selected %s\n", items[index-1]);
}

The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read (CWE-126).



Example 3


The following is an example of code that may result in a buffer underwrite. This code is attempting to replace the substring "Replace Me" in destBuf with the string stored in srcBuf. It does so by using the function strstr(), which returns a pointer to the found substring in destBuf. Using pointer arithmetic, the starting index of the substring is found.

(bad code)
Example Language:
int main() {
...
char *result = strstr(destBuf, "Replace Me");
int idx = result - destBuf;
strcpy(&destBuf[idx], srcBuf);
...
}

In the case where the substring is not found in destBuf, strstr() will return NULL, causing the pointer arithmetic to be undefined, potentially setting the value of idx to a negative number. If idx is negative, this will result in a buffer underwrite of destBuf.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Unchecked length of SSLv2 challenge value leads to buffer underflow.
Buffer underflow from a small size value with a large buffer (length parameter inconsistency, CWE-130)
Buffer underflow from an all-whitespace string, which causes a counter to be decremented before the buffer while looking for a non-whitespace character.
Buffer underflow resultant from encoded data that triggers an integer overflow.
Product sets an incorrect buffer size limit, leading to "off-by-two" buffer underflow.
Negative value is used in a memcpy() operation, leading to buffer underflow.
Buffer underflow due to mishandled special characters
+ Detection Methods
Method Details

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1160 SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1399 Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes
Usage DISCOURAGED
(this CWE ID should not be used to map to real-world vulnerabilities)
Reasons Potential Deprecation, Frequent Misuse

Rationale

The CWE entry might be misused when lower-level CWE entries might be available. It also overlaps existing CWE entries and might be deprecated in the future.

Comments

If the "Access" operation is known to be a read or a write, then investigate children of entries such as CWE-787: Out-of-bounds Write and CWE-125: Out-of-bounds Read.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CERT C Secure Coding ARR30-C CWE More Specific Do not form or use out-of-bounds pointers or array subscripts
+ Content History
+ Submissions
Submission Date Submitter Organization
2009-10-21
(CWE 1.6, 2009-10-29)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Applicable_Platforms
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Common_Consequences
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences

CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')

Weakness ID: 843
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.
+ Extended Description

When the product accesses the resource using an incompatible type, this could trigger logical errors because the resource does not have expected properties. In languages without memory safety, such as C and C++, type confusion can lead to out-of-bounds memory access.

While this weakness is frequently associated with unions when parsing data with many different embedded object types in C, it can be present in any application that can interpret the same variable or memory location in multiple ways.

This weakness is not unique to C and C++. For example, errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues.

+ Alternate Terms
Object Type Confusion
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Read Memory; Modify Memory; Execute Unauthorized Code or Commands; DoS: Crash, Exit, or Restart

Scope: Availability, Integrity, Confidentiality

When a memory buffer is accessed using the wrong type, it could read or write memory out of the bounds of the buffer, if the allocated buffer is smaller than the type that the code is attempting to access, leading to a crash and possibly code execution.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 704 Incorrect Type Conversion or Cast
PeerOf Base Base - a 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. 1287 Improper Validation of Specified Type of Input
CanPrecede Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 136 Type Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 704 Incorrect Type Conversion or Cast
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type.

(bad code)
Example Language:
#define NAME_TYPE 1
#define ID_TYPE 2

struct MessageBuffer
{
int msgType;
union {
char *name;
int nameID;
};
};


int main (int argc, char **argv) {
struct MessageBuffer buf;
char *defaultMessage = "Hello World";

buf.msgType = NAME_TYPE;
buf.name = defaultMessage;
printf("Pointer of buf.name is %p\n", buf.name);
/* This particular value for nameID is used to make the code architecture-independent. If coming from untrusted input, it could be any value. */

buf.nameID = (int)(defaultMessage + 1);
printf("Pointer of buf.name is now %p\n", buf.name);
if (buf.msgType == NAME_TYPE) {
printf("Message: %s\n", buf.name);
}
else {
printf("Message: Use ID %d\n", buf.nameID);
}
}

The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation.

As a result, modification of buf.nameID - an int - can effectively modify the pointer that is stored in buf.name - a string.

Execution of the program might generate output such as:

Pointer of name is 10830
Pointer of name is now 10831
Message: ello World

Notice how the pointer for buf.name was changed, even though buf.name was not explicitly modified.

In this case, the first "H" character of the message is omitted. However, if an attacker is able to fully control the value of buf.nameID, then buf.name could contain an arbitrary pointer, leading to out-of-bounds reads or writes.



Example 2


The following PHP code accepts a value, adds 5, and prints the sum.

(bad code)
Example Language: PHP 
$value = $_GET['value'];
$sum = $value + 5;
echo "value parameter is '$value'<p>";
echo "SUM is $sum";

When called with the following query string:

value=123

the program calculates the sum and prints out:

SUM is 128

However, the attacker could supply a query string such as:

value[]=123

The "[]" array syntax causes $value to be treated as an array type, which then generates a fatal error when calculating $sum:

Fatal error: Unsupported operand types in program.php on line 2



Example 3


The following Perl code is intended to look up the privileges for user ID's between 0 and 3, by performing an access of the $UserPrivilegeArray reference. It is expected that only userID 3 is an admin (since this is listed in the third element of the array).

(bad code)
Example Language: Perl 
my $UserPrivilegeArray = ["user", "user", "admin", "user"];

my $userID = get_current_user_ID();

if ($UserPrivilegeArray eq "user") {
print "Regular user!\n";
}
else {
print "Admin!\n";
}

print "\$UserPrivilegeArray = $UserPrivilegeArray\n";

In this case, the programmer intended to use "$UserPrivilegeArray->{$userID}" to access the proper position in the array. But because the subscript was omitted, the "user" string was compared to the scalar representation of the $UserPrivilegeArray reference, which might be of the form "ARRAY(0x229e8)" or similar.

Since the logic also "fails open" (CWE-636), the result of this bug is that all users are assigned administrator privileges.

While this is a forced example, it demonstrates how type confusion can have security consequences, even in memory-safe languages.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Type confusion in CSS sequence leads to out-of-bounds read.
Size inconsistency allows code execution, first discovered when it was actively exploited in-the-wild.
Improperly-parsed file containing records of different types leads to code execution when a memory location is interpreted as a different object than intended.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1157 SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Applicable Platform

This weakness is possible in any type-unsafe programming language.

Research Gap

Type confusion weaknesses have received some attention by applied researchers and major software vendors for C and C++ code. Some publicly-reported vulnerabilities probably have type confusion as a root-cause weakness, but these may be described as "memory corruption" instead.

For other languages, there are very few public reports of type confusion weaknesses. These are probably under-studied. Since many programs rely directly or indirectly on loose typing, a potential "type confusion" behavior might be intentional, possibly requiring more manual analysis.

+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CERT C Secure Coding EXP39-C Exact Do not access a variable through a pointer of an incompatible type
+ References
[REF-811] Mark Dowd, Ryan Smith and David Dewey. "Attacking Interoperability". "Type Confusion Vulnerabilities," page 59. 2009.
<http://hustlelabs.com/stuff/bh2009_dowd_smith_dewey.pdf>. (URL validated: 2023-04-07)
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Type Confusion", Page 319. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2011-05-15
(CWE 1.13, 2011-06-01)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2022-04-28 CWE Content Team MITRE
updated Research_Gaps
2020-06-25 CWE Content Team MITRE
updated Common_Consequences, Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated References

CWE-824: Access of Uninitialized Pointer

Weakness ID: 824
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product accesses or uses a pointer that has not been initialized.
+ Extended Description

If the pointer contains an uninitialized value, then the value might not point to a valid memory location. This could cause the product to read from or write to unexpected memory locations, leading to a denial of service. If the uninitialized pointer is used as a function call, then arbitrary functions could be invoked. If an attacker can influence the portion of uninitialized memory that is contained in the pointer, this weakness could be leveraged to execute code or perform other attacks.

Depending on memory layout, associated memory management behaviors, and product operation, the attacker might be able to influence the contents of the uninitialized pointer, thus gaining more fine-grained control of the memory location to be accessed.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Read Memory

Scope: Confidentiality

If the uninitialized pointer is used in a read operation, an attacker might be able to read sensitive portions of memory.

DoS: Crash, Exit, or Restart

Scope: Availability

If the uninitialized pointer references a memory location that is not accessible to the product, or points to a location that is "malformed" (such as NULL) or larger than expected by a read or write operation, then a crash may occur.

Execute Unauthorized Code or Commands

Scope: Integrity, Confidentiality, Availability

If the uninitialized pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
CanPrecede Base Base - a 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. 125 Out-of-bounds Read
CanPrecede Base Base - a 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. 787 Out-of-bounds Write
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 465 Pointer Issues
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Relevant to the view "CISQ Data Protection Measures" (View-1340)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
LLM product has a free of an uninitialized pointer
Chain: secure communications library does not initialize a local variable for a data structure (CWE-456), leading to access of an uninitialized pointer (CWE-824).
Chain: C union member is not initialized (CWE-456), leading to access of invalid pointer (CWE-824)
chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
Pointer in structure is not initialized, leading to NULL pointer dereference (CWE-476) and system crash.
Free of an uninitialized pointer.
Improper handling of invalid signatures leads to free of invalid pointer.
Invalid encoding triggers free of uninitialized pointer.
Crafted PNG image leads to free of uninitialized pointer.
Crafted GIF image leads to free of uninitialized pointer.
Access of uninitialized pointer might lead to code execution.
Step-based manipulation: invocation of debugging function before the primary initialization function leads to access of an uninitialized pointer and code execution.
Unchecked return values can lead to a write to an uninitialized pointer.
zero-length input leads to free of uninitialized pointer.
Crafted font leads to uninitialized function pointer.
Uninitialized function pointer in freed memory is invoked
LDAP server mishandles malformed BER queries, leading to free of uninitialized memory
Firewall can crash with certain ICMP packets that trigger access of an uninitialized pointer.
LDAP server does not initialize members of structs, which leads to free of uninitialized pointer if an LDAP request fails.
+ Detection Methods
Method Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1399 Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Terminology

Many weaknesses related to pointer dereferences fall under the general term of "memory corruption" or "memory safety." As of September 2010, there is no commonly-used terminology that covers the lower-level variants.

Maintenance

There are close relationships between incorrect pointer dereferences and other weaknesses related to buffer operations. There may not be sufficient community agreement regarding these relationships. Further study is needed to determine when these relationships are chains, composites, perspective/layering, or other types of relationships. As of September 2010, most of the relationships are being captured as chains.
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-09-22
(CWE 1.10, 2010-09-27)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Applicable_Platforms, Observed_Examples
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-01-31 CWE Content Team MITRE
updated Common_Consequences, Description
2022-04-28 CWE Content Team MITRE
updated Research_Gaps
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated References

CWE-767: Access to Critical Private Variable via Public Method

Weakness ID: 767
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product defines a public method that reads or modifies a private variable.
+ Extended Description
If an attacker modifies the variable to contain unexpected values, this could violate assumptions from other parts of the code. Additionally, if an attacker can read the private variable, it may expose sensitive information or make it easier to launch further attacks.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Modify Application Data; Other

Scope: Integrity, Other

+ Potential Mitigations
Phase(s) Mitigation

Implementation

Use class accessor and mutator methods appropriately. Perform validation when accepting data from a public method that is intended to modify a critical private variable. Also be sure that appropriate access controls are being applied when a public method interfaces with critical data.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 668 Exposure of Resource to Wrong Sphere
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 275 Permission Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Java (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The following example declares a critical variable to be private, and then allows the variable to be modified by public methods.

(bad code)
Example Language: C++ 
private: float price;
public: void changePrice(float newPrice) {
price = newPrice;
}


Example 2


The following example could be used to implement a user forum where a single user (UID) can switch between multiple profiles (PID).

(bad code)
Example Language: Java 
public class Client {
private int UID;
public int PID;
private String userName;
public Client(String userName){
PID = getDefaultProfileID();
UID = mapUserNametoUID( userName );
this.userName = userName;
}
public void setPID(int ID) {
UID = ID;
}
}

The programmer implemented setPID with the intention of modifying the PID variable, but due to a typo. accidentally specified the critical variable UID instead. If the program allows profile IDs to be between 1 and 10, but a UID of 1 means the user is treated as an admin, then a user could gain administrative privileges as a result of this typo.



+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1184 SEI CERT Perl Coding Standard - Guidelines 06. Object-Oriented Programming (OOP)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Maintenance

This entry is closely associated with access control for public methods. If the public methods are restricted with proper access controls, then the information in the private variable will not be exposed to unexpected parties. There may be chaining or composite relationships between improper access controls and this weakness.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Failure to protect stored data from modification
Software Fault Patterns SFP23 Exposed Data
SEI CERT Perl Coding Standard OOP31-PL Imprecise Do not access private variables or subroutines in other packages
+ Content History
+ Submissions
Submission Date Submitter Organization
2009-03-03
(CWE 1.4, 2009-05-27)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction, Type
2023-01-31 CWE Content Team MITRE
updated Description
2021-03-15 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences

CWE-489: Active Debug Code

Weakness ID: 489
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.
+ Extended Description
A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the product. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the product.
+ Alternate Terms
Leftover debug code
This term originates from Seven Pernicious Kingdoms
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism; Read Application Data; Gain Privileges or Assume Identity; Varies by Context

Scope: Confidentiality, Integrity, Availability, Access Control, Other

The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access.
+ Potential Mitigations
Phase(s) Mitigation

Build and Compilation; Distribution

Remove debug code before deploying the application.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that 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. 710 Improper Adherence to Coding Standards
ParentOf Variant Variant - 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. 11 ASP.NET Misconfiguration: Creating Debug Binary
CanPrecede Base Base - a 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. 215 Insertion of Sensitive Information Into Debugging Code
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1006 Bad Coding Practices
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation In web-based applications, debug code is used to test and modify web application properties, configuration information, and functions. If a debug application is left on a production server, this oversight during the "software process" allows attackers access to debug functionality.
Build and Compilation
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is:

(bad code)
Example Language: HTML 
<FORM ACTION="/authenticate_login.cgi">
<INPUT TYPE=TEXT name=username>
<INPUT TYPE=PASSWORD name=password>
<INPUT TYPE=SUBMIT>
</FORM>

Then a conforming link will look like:

(informative)
 
http://TARGET/authenticate_login.cgi?username=...&password=...

An attacker can change this to:

(attack code)
 
http://TARGET/authenticate_login.cgi?username=&password=&debug=1

Which will grant the attacker access to the site, bypassing the authentication process.



+ Weakness Ordinalities
Ordinality Description
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods
Method Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 485 7PK - Encapsulation
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1002 SFP Secondary Cluster: Unexpected Entry Points
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1371 ICS Supply Chain: Poorly Documented or Undocumented Features
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1412 Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Other

In J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms Leftover Debug Code
OWASP Top Ten 2004 A10 CWE More Specific Insecure Configuration Management
Software Fault Patterns SFP28 Unexpected access points
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07.
<https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Description, Relationships
2021-07-20 CWE Content Team MITRE
updated Alternate_Terms
2021-03-15 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-02-24 CWE Content Team MITRE
updated Description, Name, References, Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-01-03 CWE Content Team MITRE
updated Weakness_Ordinalities
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Relationships, White_Box_Definitions
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2014-06-23 CWE Content Team MITRE
updated Description, Modes_of_Introduction, Other_Notes, Time_of_Introduction
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-10-29 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Demonstrative_Examples
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-08-01 KDM Analytics
added/updated white box definitions
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2020-02-24 Leftover Debug Code

CWE-464: Addition of Data Structure Sentinel

Weakness ID: 464
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
+ Extended Description
Data-structure sentinels are often used to mark the structure of data. A common example of this is the null character at the end of strings or a special sentinel to mark the end of a linked list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the addition or modification of sentinels.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Modify Application Data

Scope: Integrity

Generally this error will cause the data structure to not work properly by truncating the data.
+ Potential Mitigations
Phase(s) Mitigation

Implementation; Architecture and Design

Encapsulate the user from interacting with data sentinels. Validate user input to verify that sentinels are not present.

Implementation

Proper error checking can reduce the risk of inadvertently introducing sentinel values into data. For example, if a parsing function fails or encounters an error, it might return a value that is the same as the sentinel.

Architecture and Design

Use an abstraction library to abstract away risky APIs. This is not a complete solution.

Operation

Use OS-level preventative functionality. This is not a complete solution.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 138 Improper Neutralization of Special Elements
PeerOf Base Base - a 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. 170 Improper Null Termination
PeerOf Base Base - a 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. 463 Deletion of Data Structure Sentinel
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 137 Data Neutralization Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


The following example assigns some character values to a list of characters and prints them each individually, and then as a string. The third character value is intended to be an integer taken from user input and converted to an int.

(bad code)
Example Language:
char *foo;
foo=malloc(sizeof(char)*5);
foo[0]='a';
foo[1]='a';
foo[2]=fgetc(stdin);
foo[3]='c';
foo[4]='\0';
printf("%c %c %c %c %c \n",foo[0],foo[1],foo[2],foo[3],foo[4]);
printf("%s\n",foo);

The first print statement will print each character separated by a space. However, if a NULL byte is read from stdin by fgetc, then it will return 0. When foo is printed as a string, the 0 at character foo[2] will act as a NULL terminator and foo[3] will never be printed.



+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 741 CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 875 CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1407 Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Addition of data-structure sentinel
CERT C Secure Coding STR03-C Do not inadvertently truncate a null-terminated byte string
CERT C Secure Coding STR06-C Do not assume that strtok() leaves the parse string unchanged
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution Date Contributor Organization
2024-07-20
(CWE 4.17, 2025-04-03)
Jason Xu
Reported compilation error with demonstrative example.
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Taxonomy_Mappings
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Relationships
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Addition of Data-structure Sentinel

CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling

Weakness ID: 774
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.
+ Extended Description
This can cause the product to consume all available file descriptors or handles, which can prevent other processes from performing critical file processing operations.
+ Alternate Terms
File Descriptor Exhaustion
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

DoS: Resource Consumption (Other)

Scope: Availability

When allocating resources without limits, an attacker could prevent all other processes from accessing the same type of resource.
+ Potential Mitigations
Phase(s) Mitigation

Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 770 Allocation of Resources Without Limits or Throttling
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation
+ Likelihood Of Exploit
Low
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 985 SFP Secondary Cluster: Unrestricted Consumption
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
Software Fault Patterns SFP13 Unrestricted Consumption
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Alternate_Terms, Relationships, Theoretical_Notes
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2010-04-05 CWE Content Team MITRE
updated Potential_Mitigations

CWE-770: Allocation of Resources Without Limits or Throttling

Weakness ID: 770
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+ Extended Description

Code frequently has to work with limited resources, so programmers must be careful to ensure that resources are not consumed too quickly, or too easily. Without use of quotas, resource limits, or other protection mechanisms, it can be easy for an attacker to consume many resources by rapidly making many requests, or causing larger resources to be used than is needed. When too many resources are allocated, or if a single resource is too large, then it can prevent the code from working correctly, possibly leading to a denial of service.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

Scope: Availability

When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.
+ Potential Mitigations
Phase(s) Mitigation

Requirements

Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

Architecture and Design

Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Note: This will only be applicable to cases where user input can influence the size or frequency of resource allocations.

Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either:

  • recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.

The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.

Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Ensure that all failures in resource allocation place the system into a safe posture.

Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 400 Uncontrolled Resource Consumption
ChildOf Class Class - a weakness that is 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. 665 Improper Initialization
ParentOf Variant Variant - 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. 774 Allocation of File Descriptors or Handles Without Limits or Throttling
ParentOf Variant Variant - 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. 789 Memory Allocation with Excessive Size Value
ParentOf Base Base - a 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. 1325 Improperly Controlled Sequential Memory Allocation
CanFollow Class Class - a weakness that is 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. 20 Improper Input Validation
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 399 Resource Management Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 840 Business Logic Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 400 Uncontrolled Resource Consumption
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


This code allocates a socket and forks each time it receives a new connection.

(bad code)
Example Language:
sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {
newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();
}

The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.



Example 2


In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket.

(bad code)
Example Language:
int writeDataFromSocketToFile(char *host, int port)
{

char filename[FILENAME_SIZE];
char buffer[BUFFER_SIZE];
int socket = openSocketConnection(host, port);

if (socket < 0) {
printf("Unable to open socket connection");
return(FAIL);
}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {
if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0))
break;
}
}
closeFile();
}
closeSocket(socket);
}

This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.



Example 3


In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array.

(bad code)
Example Language:

/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
int processMessage(char **message)
{
char *body;

int length = getMessageLength(message[0]);

if (length > 0) {
body = &message[1][0];
processMessageBody(body);
return(SUCCESS);
}
else {
printf("Unable to process message; invalid message length");
return(FAIL);
}
}

This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check

Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.

(good code)
Example Language:
unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...}


Example 4


In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket.

(bad code)
Example Language: Java 
public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
t.start();
}
serverSocket.close();


} catch (IOException ex) {...}
}

In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources.

The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated.

(good code)
Example Language: Java 
public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
hasConnections = checkForMoreConnections();
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);
pool.execute(t);
}
serverSocket.close();


} catch (IOException ex) {...}
}


Example 5


An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.

Example 5 References:
[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.


Example 6


Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory.

(bad code)
Example Language:
bar connection() {
foo = malloc(1024);
return foo;
}

endConnection(bar foo) {
free(foo);
}

int main() {
while(1) {
foo=connection();
}

endConnection(foo)
}


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
web application scanner attempts to read an excessively large file created by a user, causing process termination
Go-based workload orchestrator does not limit resource usage with unauthenticated connections, allowing a DoS by flooding the service
+ Detection Methods
Method Details

Manual Static Analysis

Manual static analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. If denial-of-service is not considered a significant risk, or if there is strong emphasis on consequences such as code execution, then manual analysis may not focus on this weakness at all.

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find uncontrolled resource allocation problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to limit resource allocation may be the cause.

When the allocation is directly affected by numeric inputs, then fuzzing may produce indications of this weakness.

Effectiveness: Opportunistic

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in producing side effects of uncontrolled resource allocation problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame. Manual analysis is likely required to interpret the results.

Automated Static Analysis

Specialized configuration or tuning may be required to train automated tools to recognize this weakness.

Automated static analysis typically has limited utility in recognizing unlimited allocation problems, except for the missing release of program-independent system resources such as files, sockets, and processes, or unchecked arguments to memory. For system resources, automated static analysis may be able to detect circumstances in which resources are not released after they have expired, or if too much of a resource is requested at once, as can occur with memory. Automated analysis of configuration files may be able to detect settings that do not specify a maximum value.

Automated static analysis tools will not be appropriate for detecting exhaustion of custom resources, such as an intended security policy in which a bulletin board user is only allowed to make a limited number of posts per day.

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 802 2010 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 861 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 867 2011 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 876 CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 877 CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 985 SFP Secondary Cluster: Unrestricted Consumption
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1148 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1152 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

This entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771).

Theoretical

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011) FIO04-J Close resources when they are no longer needed
The CERT Oracle Secure Coding Standard for Java (2011) SER12-J Avoid memory and resource leaks during serialization
The CERT Oracle Secure Coding Standard for Java (2011) MSC05-J Do not exhaust heap space
ISA/IEC 62443 Part 4-2 Req CR 7.2
ISA/IEC 62443 Part 4-2 Req CR 2.7
ISA/IEC 62443 Part 4-1 Req SI-1
ISA/IEC 62443 Part 4-1 Req SI-2
ISA/IEC 62443 Part 3-3 Req SR 7.2
ISA/IEC 62443 Part 3-3 Req SR 2.7
+ References
[REF-386] Joao Antunes, Nuno Ferreira Neves and Paulo Verissimo. "Detection and Prediction of Resource-Exhaustion Vulnerabilities". Proceedings of the IEEE International Symposium on Software Reliability Engineering (ISSRE). 2008-11.
<http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.
[REF-387] D.J. Bernstein. "Resource exhaustion".
<http://cr.yp.to/docs/resources.html>.
[REF-388] Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004.
<http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04.
<https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011.
<http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.
[REF-672] Frank Kim. "Top 25 Series - Rank 22 - Allocation of Resources Without Limits or Throttling". SANS Software Security Institute. 2010-03-23.
<https://web.archive.org/web/20170113055136/https://software-security.sans.org/blog/2010/03/23/top-25-series-rank-22-allocation-of-resources-without-limits-or-throttling/>. (URL validated: 2023-04-07)
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content Team MITRE
+ Contributions
Contribution Date Contributor Organization
2023-11-14
(CWE 4.14, 2024-02-29)
participants in the CWE ICS/OT SIG 62443 Mapping Fall Workshop
Contributed or reviewed taxonomy mappings for ISA/IEC 62443
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Taxonomy_Mappings
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Detection_Factors
2022-10-13 CWE Content Team MITRE
updated Observed_Examples, References
2021-07-20 CWE Content Team MITRE
updated Observed_Examples
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Applicable_Platforms, Description, Maintenance_Notes, Potential_Mitigations, Relationship_Notes, Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2019-01-03 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2015-12-07 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-07-30 CWE Content Team MITRE
updated Relationships
2014-06-23 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, Detection_Factors, Relationships
2010-09-27 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations, References
2010-04-05 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2009-10-29 CWE Content Team MITRE
updated Relationships
2009-07-27 CWE Content Team MITRE
updated Related_Attack_Patterns

CWE-670: Always-Incorrect Control Flow Implementation

Weakness ID: 670
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.
+ Extended Description
This weakness captures cases in which a particular code segment is always incorrect with respect to the algorithm that it is implementing. For example, if a C programmer intends to include multiple statements in a single block but does not include the enclosing braces (CWE-483), then the logic is always incorrect. This issue is in contrast to most weaknesses in which the code usually behaves correctly, except when it is externally manipulated in malicious ways.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Other; Alter Execution Logic

Scope: Other

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that 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. 691 Insufficient Control Flow Management
ParentOf Base Base - a 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. 480 Use of Incorrect Operator
ParentOf Base Base - a 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. 483 Incorrect Block Delimitation
ParentOf Base Base - a 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. 484 Omitted Break Statement in Switch
ParentOf Base Base - a 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. 617 Reachable Assertion
ParentOf Base Base - a 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. 698 Execution After Redirect (EAR)
ParentOf Base Base - a 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. 783 Operator Precedence Logic Error
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a 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. 617 Reachable Assertion
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation This issue typically appears in rarely-tested code, since the "always-incorrect" nature will be detected as a bug during normal usage.
+ Demonstrative Examples

Example 1


This code queries a server and displays its status when a request comes from an authorized IP address.

(bad code)
Example Language: PHP 
$requestingIP = $_SERVER['REMOTE_ADDR'];
if(!in_array($requestingIP,$ipAllowList)){
echo "You are not authorized to view this page";
http_redirect($errorPageURL);
}
$status = getServerStatus();
echo $status;
...

This code redirects unauthorized users, but continues to execute code after calling http_redirect(). This means even unauthorized users may be able to access the contents of the page or perform a DoS attack on the server being queried. Also, note that this code is vulnerable to an IP address spoofing attack (CWE-212).



Example 2


In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

(bad code)
Example Language:
if (condition==true)
Do_X();
Do_Y();

This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.



Example 3


In both of these examples, a message is printed based on the month passed into the function:

(bad code)
Example Language: Java 
public void printMessage(int month){
switch (month) {

case 1: print("January");
case 2: print("February");
case 3: print("March");
case 4: print("April");
case 5: print("May");
case 6: print("June");
case 7: print("July");
case 8: print("August");
case 9: print("September");
case 10: print("October");
case 11: print("November");
case 12: print("December");
}
println(" is a great month");
}
(bad code)
Example Language:
void printMessage(int month){
switch (month) {

case 1: printf("January");
case 2: printf("February");
case 3: printf("March");
case 4: printf("April");
case 5: printff("May");
case 6: printf("June");
case 7: printf("July");
case 8: printf("August");
case 9: printf("September");
case 10: printf("October");
case 11: printf("November");
case 12: printf("December");
}
printf(" is a great month");
}

Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed.



Example 4


In the excerpt below, an AssertionError (an unchecked exception) is thrown if the user hasn't entered an email address in an HTML form.

(bad code)
Example Language: Java 
String email = request.getParameter("email_address");
assert email != null;


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1410 Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason Abstraction

Rationale

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments

Examine children of this entry to see if there is a better fit
+ Notes

Maintenance

This node could possibly be split into lower-level nodes. "Early Return" is for returning control to the caller too soon (e.g., CWE-584). "Excess Return" is when control is returned too far up the call stack (CWE-600, CWE-395). "Improper control limitation" occurs when the product maintains control at a lower level of execution, when control should be returned "further" up the call stack (CWE-455). "Incorrect syntax" covers code that's "just plain wrong" such as CWE-484 and CWE-483.
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction
2021-10-28 CWE Content Team MITRE
updated Observed_Examples
2020-02-24 CWE Content Team MITRE
updated Relationships, Time_of_Introduction
2019-06-20 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Relationships
2017-01-19 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-07-27 CWE Content Team MITRE
updated Maintenance_Notes, Modes_of_Introduction, Other_Notes, Relationships
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-1249: Application-Level Admin Tool with Inconsistent View of Underlying Operating System

Weakness ID: 1249
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product provides an application for administrators to manage parts of the underlying operating system, but the application does not accurately identify all of the relevant entities or resources that exist in the OS; that is, the application's model of the OS's state is inconsistent with the OS's actual state.
+ Extended Description

Many products provide web-based applications or other interfaces for managing the underlying operating system. This is common with cloud, network access devices, home networking, and other systems. When the management tool does not accurately represent what is in the OS - such as user accounts - then the administrator might not see suspicious activities that would be noticed otherwise.

For example, numerous systems utilize a web front-end for administrative control. They also offer the ability to add, alter, and drop users with various privileges as it relates to the functionality of the system. A potential architectural weakness may exist where the user information reflected in the web interface does not mirror the users in the underlying operating system. Many web UI or REST APIs use the underlying operating system for authentication; the system's logic may also track an additional set of user capabilities within configuration files and datasets for authorization capabilities. When there is a discrepancy between the user information in the UI or REST API's interface system and the underlying operating system's user listing, this may introduce a weakness into the system. For example, if an attacker compromises the OS and adds a new user account - a "ghost" account - then the attacker could escape detection if the management tool does not list the newly-added account.

This discrepancy could be exploited in several ways:

  • A rogue admin could insert a new account into a system that will persist if they are terminated or wish to take action on a system that cannot be directly associated with them.
  • An attacker can leverage a separate command injection attack available through the web interface to insert a ghost account with shell privileges such as ssh.
  • An attacker can leverage existing web interface APIs, manipulated in such a way that a new user is inserted into the operating system, and the user web account is either partially created or not at all.
  • An attacker could create an admin account which is viewable by an administrator, use this account to create the ghost account, delete logs and delete the first created admin account.

Many of these attacker scenarios can be realized by leveraging separate vulnerabilities related to XSS, command injection, authentication bypass, or logic flaws on the various systems.

+ Alternate Terms
Ghost in the Shell
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Varies by Context

Scope: Access Control

Hide Activities

Scope: Accountability

Unexpected State

Scope: Other

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Ensure that the admin tool refreshes its model of the underlying OS on a regular basis, and note any inconsistencies with configuration files or other data sources that are expected to have the same data.

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 1250 Improper Preservation of Consistency Between Independent Representations of Shared State
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design The design might assume that the underlying OS does not change.
Implementation Assumptions about the underlying OS might be hard-coded into the application or otherwise in external data stores in a way that is not updated when the OS's state changes.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Technologies

Class: Web Based (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Suppose that an attacker successfully gains root privileges on a Linux system and adds a new 'user2' account:

(attack code)
Example Language: Other 
echo "user2:x:0:0::/root:/" >> /etc/passwd;
echo "user2:\$6\$IdvyrM6VJnG8Su5U\$1gmW3Nm.IO4vxTQDQ1C8urm72JCadOHZQwqiH/nRtL8dPY80xS4Ovsv5bPCMWnXKKWwmsocSWXupUf17LB3oS.:17256:0:99999:7:::" >> /etc/shadow;

This new user2 account would not be noticed on the web interface, if the interface does not refresh its data of available users.

It could be argued that for this specific example, an attacker with root privileges would be likely to compromise the admin tool or otherwise feed it with false data. However, this example shows how the discrepancy in critical data can help attackers to escape detection.



+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1415 Comprehensive Categorization: Resource Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-1070] Tony Martin. "Ghost in the Shell Weakness". 2020-02-13.
<https://friendsglobal.com/ghost-in-the-shell/ghost-in-the-shell-weakness/>. (URL validated: 2023-04-07)
+ Content History
+ Submissions
Submission Date Submitter Organization
2019-06-06
(CWE 4.0, 2020-02-24)
Tony Martin
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2020-06-25 CWE Content Team MITRE
updated Demonstrative_Examples

CWE-1044: Architecture with Number of Horizontal Layers Outside of Expected Range

Weakness ID: 1044
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product's architecture contains too many - or too few - horizontal layers.
+ Extended Description

This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. It also might make it easier to introduce vulnerabilities.

While the interpretation of "expected range" may vary for each product or developer, CISQ recommends a default minimum of 4 layers and maximum of 8 layers.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Reduce Maintainability

Scope: Other

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that 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. 710 Improper Adherence to Coding Standards
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1006 Bad Coding Practices
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
+ Weakness Ordinalities
Ordinality Description
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1130 CISQ Quality Measures (2016) - Maintainability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1412 Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes
Usage PROHIBITED
(this CWE ID must not be used to map to real-world vulnerabilities)
Reason Other

Rationale

This entry is primarily a quality issue with no direct security implications.

Comments

Look for weaknesses that are focused specifically on insecure behaviors that have more direct security implications.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
OMG ASCMM ASCMM-MNT-9
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-9. 2016-01.
<https://www.omg.org/spec/ASCMM/>. (URL validated: 2023-04-07)
+ Content History
+ Submissions
Submission Date Submitter Organization
2018-07-02
(CWE 3.2, 2019-01-03)
CWE Content Team MITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description

CWE-582: Array Declared Public, Final, and Static

Weakness ID: 582
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.
+ Extended Description
Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. As such, in most cases an array declared public, final and static is a bug.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Modify Application Data

Scope: Integrity

+ Potential Mitigations
Phase(s) Mitigation

Implementation

In most situations the array should be made private.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 668 Exposure of Resource to Wrong Sphere
+ Background Details
Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your product is running.
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Java (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The following Java Applet code mistakenly declares an array public, final and static.

(bad code)
Example Language: Java 
public final class urlTool extends Applet {
public final static URL[] urls;
...
}


+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 849 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1002 SFP Secondary Cluster: Unexpected Entry Points
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011) OBJ10-J Do not use public static nonfinal variables
Software Fault Patterns SFP28 Unexpected Access Points
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Background_Details, Description
2022-10-13 CWE Content Team MITRE
updated Taxonomy_Mappings
2020-02-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-05-27 CWE Content Team MITRE
updated Demonstrative_Examples
2008-10-14 CWE Content Team MITRE
updated Background_Details, Demonstrative_Examples, Description, Other_Notes
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Mobile Code: Unsafe Array Declaration

CWE-11: ASP.NET Misconfiguration: Creating Debug Binary

Weakness ID: 11
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
Debugging messages help attackers learn about the system and plan a form of attack.
+ Extended Description
ASP .NET applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Read Application Data

Scope: Confidentiality

Attackers can leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application.
+ Potential Mitigations
Phase(s) Mitigation

System Configuration

Avoid releasing debug binaries into the production environment. Change the debug mode to false when the application is deployed into production.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 489 Active Debug Code
+ Background Details
The debug attribute of the <compilation> tag defines whether compiled binaries should include debugging information. The use of debug binaries causes an application to provide as much information about itself as possible to the user.
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
Build and Compilation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

ASP.NET (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The file web.config contains the debug mode setting. Setting debug to "true" will let the browser display debugging information.

(bad code)
Example Language: XML 
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation
defaultLanguage="c#"
debug="true"
/>
...
</system.web>
</configuration>

Change the debug mode to false when the application is deployed into production.



+ Detection Methods
Method Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 2 7PK - Environment
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1349 OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1412 Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms ASP.NET Misconfiguration: Creating Debug Binary
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07.
<https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated References, Relationships, Time_of_Introduction
2017-11-08 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Other_Notes
2008-11-24 CWE Content Team MITRE
updated Description, Other_Notes
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Demonstrative_Example, Potential_Mitigations, Time_of_Introduction

CWE-1174: ASP.NET Misconfiguration: Improper Model Validation

Weakness ID: 1174
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The ASP.NET application does not use, or incorrectly uses, the model validation framework.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Unexpected State

Scope: Integrity

Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 1173 Improper Use of Validation Framework
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

ASP.NET (Undetermined Prevalence)

+ Weakness Ordinalities
Ordinality Description
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1349 OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1406 Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2018-12-21
(CWE 3.2, 2019-01-03)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships

CWE-12: ASP.NET Misconfiguration: Missing Custom Error Page

Weakness ID: 12
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Read Application Data

Scope: Confidentiality

Default error pages gives detailed information about the error that occurred, and should not be used in production environments. Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.
+ Potential Mitigations
Phase(s) Mitigation

System Configuration

Handle exceptions appropriately in source code. ASP .NET applications should be configured to use custom error pages instead of the framework default page.

Architecture and Design

Do not attempt to process an error or attempt to mask it.

Implementation

Verify return values are correct and do not supply sensitive information about the system.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 756 Missing Custom Error Page
+ Background Details
The mode attribute of the <customErrors> tag defines whether custom or default error pages are used.
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

ASP.NET (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used.

In the following insecure ASP.NET application setting, custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned.

(bad code)
Example Language: ASP.NET 
<customErrors mode="Off" />

A more secure setting is to set the custom error message mode for remote users only. No defaultRedirect error page is specified. The local user on the web server will see a detailed stack trace. For remote users, an ASP.NET error message with the server customError configuration setting and the platform version will be returned.

(good code)
Example Language: ASP.NET 
<customErrors mode="RemoteOnly" />

Another secure option is to set the mode attribute of the <customErrors> tag to use a custom page as follows:

(good code)
Example Language: ASP.NET 
<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />


+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 2 7PK - Environment
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1405 Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms ASP.NET Misconfiguration: Missing Custom Error Handling
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07.
<https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
[REF-65] M. Howard, D. LeBlanc and J. Viega. "19 Deadly Sins of Software Security". McGraw-Hill/Osborne. 2005-07-26.
[REF-66] OWASP, Fortify Software. "ASP.NET Misconfiguration: Missing Custom Error Handling".
<http://www.owasp.org/index.php/ASP.NET_Misconfiguration:_Missing_Custom_Error_Handling>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Potential_Mitigations
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Background_Details, Common_Consequences, Other_Notes
2009-03-10 CWE Content Team MITRE
updated Name, Relationships
2008-11-24 CWE Content Team MITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations
2008-10-14 CWE Content Team MITRE
updated Relationships
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, References, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated References, Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2009-03-10 ASP.NET Misconfiguration: Missing Custom Error Handling

CWE-554: ASP.NET Misconfiguration: Not Using Input Validation Framework

Weakness ID: 554
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The ASP.NET application does not use an input validation framework.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Unexpected State

Scope: Integrity

Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Use the ASP.NET validation framework to check all program input before it is processed by the application. Example uses of the validation framework include checking to ensure that:

  • Phone number fields contain only valid characters in phone numbers
  • Boolean values are only "T" or "F"
  • Free-form strings are of a reasonable length and composition
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 1173 Improper Use of Validation Framework
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

ASP.NET (Undetermined Prevalence)

+ Weakness Ordinalities
Ordinality Description
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1406 Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
Software Fault Patterns SFP24 Tainted input to command
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Weakness_Ordinalities
2017-11-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-01-19 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Common_Consequences, Description, Potential_Mitigations
2009-07-27 CWE Content Team MITRE
updated Other_Notes
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings, Type
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 ASP.NET Misconfiguration: Input Validation

CWE-13: ASP.NET Misconfiguration: Password in Configuration File

Weakness ID: 13
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Gain Privileges or Assume Identity

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Implementation

Credentials stored in configuration files should be encrypted, Use standard APIs and industry accepted algorithms to encrypt the credentials stored in configuration files.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 260 Password in Configuration File
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation
+ Demonstrative Examples

Example 1


The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database, but the pair is stored in plaintext.

(bad code)
Example Language: ASP.NET 
...
<connectionStrings>
<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />
</connectionStrings>
...

Username and password information should not be included in a configuration file or a properties file in plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.



+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 2 7PK - Environment
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1349 OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms ASP.NET Misconfiguration: Password in Configuration File
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07.
<https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
[REF-103] Microsoft Corporation. "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI".
<https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff647398(v=pandp.10)?redirectedfrom=MSDN>. (URL validated: 2023-04-07)
[REF-104] Microsoft Corporation. "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA".
<https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff650304(v=pandp.10)?redirectedfrom=MSDN>. (URL validated: 2023-04-07)
[REF-105] Microsoft Corporation. ".NET Framework Developer's Guide - Securing Connection Strings".
<http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2018-03-27 CWE Content Team MITRE
updated Demonstrative_Examples
2017-11-08 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2013-02-21 CWE Content Team MITRE
updated Potential_Mitigations
2012-10-30 CWE Content Team MITRE
updated Demonstrative_Examples
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Demonstrative_Examples
2008-09-08 CWE Content Team MITRE
updated Relationships, References, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated References, Demonstrative_Example, Potential_Mitigations, Time_of_Introduction

CWE-556: ASP.NET Misconfiguration: Use of Identity Impersonation

Weakness ID: 556
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.
+ Extended Description
The use of impersonated credentials allows an ASP.NET application to run with either the privileges of the client on whose behalf it is executing or with arbitrary privileges granted in its configuration.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Gain Privileges or Assume Identity

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Use the least privilege principle.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 266 Incorrect Privilege Assignment
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
Operation
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 723 OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 951 SFP Secondary Cluster: Insecure Authentication Policy
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-03-10 CWE Content Team MITRE
updated Relationships
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 ASP.NET Misconfiguration: Identity Impersonation

CWE-481: Assigning instead of Comparing

Weakness ID: 481
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The code uses an operator for assignment when the intention was to perform a comparison.
+ Extended Description
In many languages the compare statement is very close in appearance to the assignment statement and are often confused. This bug is generally the result of a typo and usually causes obvious problems with program execution. If the comparison is in an if statement, the if statement will usually evaluate the value of the right-hand side of the predicate.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Alter Execution Logic

Scope: Other

+ Potential Mitigations
Phase(s) Mitigation

Testing

Many IDEs and static analysis products will detect this problem.

Implementation

Place constants on the left. If one attempts to assign a constant with a variable, the compiler will produce an error.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 480 Use of Incorrect Operator
CanPrecede Pillar Pillar - a weakness that 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. 697 Incorrect Comparison
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1


The following C/C++ and C# examples attempt to validate an int input parameter against the integer value 100.

(bad code)
Example Language:
int isValid(int value) {
if (value=100) {
printf("Value is valid\n");
return(1);
}
printf("Value is not valid\n");
return(0);
}
(bad code)
Example Language: C# 
bool isValid(int value) {
if (value=100) {
Console.WriteLine("Value is valid.");
return true;
}
Console.WriteLine("Value is not valid.");
return false;
}

However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". The result of using the assignment operator instead of the comparison operator causes the int variable to be reassigned locally and the expression in the if statement will always evaluate to the value on the right hand side of the expression. This will result in the input value not being properly validated, which can cause unexpected results.



Example 2


In this example, we show how assigning instead of comparing can impact code when values are being passed by reference instead of by value. Consider a scenario in which a string is being processed from user input. Assume the string has already been formatted such that different user inputs are concatenated with the colon character. When the processString function is called, the test for the colon character will result in an insertion of the colon character instead, adding new input separators. Since the string was passed by reference, the data sentinels will be inserted in the original string (CWE-464), and further processing of the inputs will be altered, possibly malformed..

(bad code)
Example Language:
void processString (char *str) {
int i;

for(i=0; i<strlen(str); i++) {
if (isalnum(str[i])){
processChar(str[i]);
}
else if (str[i] = ':') {
movingToNewInput();}
}
}
}


Example 3


The following Java example attempts to perform some processing based on the boolean value of the input parameter. However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". As with the previous examples, the variable will be reassigned locally and the expression in the if statement will evaluate to true and unintended processing may occur.

(bad code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (isValid = true) {
System.out.println("Performing processing");
doSomethingImportant();
}
else {
System.out.println("Not Valid, do not perform processing");
return;
}
}

While most Java compilers will catch the use of an assignment operator when a comparison operator is required, for boolean variables in Java the use of the assignment operator within an expression is allowed. If possible, try to avoid using comparison operators on boolean variables in java. Instead, let the values of the variables stand for themselves, as in the following code.

(good code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (isValid) {
System.out.println("Performing processing");
doSomethingImportant();
}
else {
System.out.println("Not Valid, do not perform processing");
return;
}
}

Alternatively, to test for false, just use the boolean NOT operator.

(good code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (!isValid) {
System.out.println("Not Valid, do not perform processing");
return;
}
System.out.println("Performing processing");
doSomethingImportant();
}


Example 4


The following example demonstrates the weakness.

(bad code)
Example Language:
void called(int foo){
if (foo=1) printf("foo\n");
}
int main() {

called(2);
return 0;
}


+ Detection Methods
Method Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 998 SFP Secondary Cluster: Glitch in Computation
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1157 SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1410 Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Assigning instead of comparing
Software Fault Patterns SFP1 Glitch in computation
CERT C Secure Coding EXP45-C CWE More Abstract Do not perform assignments in selection statements
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2017-01-19 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Description, Other_Notes
2009-05-27 CWE Content Team MITRE
updated Demonstrative_Examples
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-587: Assignment of a Fixed Address to a Pointer

Weakness ID: 587
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product sets a pointer to a specific address other than NULL or 0.
+ Extended Description
Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Execute Unauthorized Code or Commands

Scope: Integrity, Confidentiality, Availability

If one executes code at a known location, an attacker might be able to inject code there beforehand.

DoS: Crash, Exit, or Restart; Reduce Maintainability; Reduce Reliability

Scope: Availability

If the code is ported to another platform or environment, the pointer is likely to be invalid and cause a crash.

Read Memory; Modify Memory

Scope: Confidentiality, Integrity

The data at a known pointer location can be easily read or influenced by an attacker.
+ Potential Mitigations
Phase(s) Mitigation

Implementation

Never set a pointer to a fixed address.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 344 Use of Invariant Value in Dynamically Changing Context
ChildOf Class Class - a weakness that is 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. 758 Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 465 Pointer Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Class: Assembly (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.

(bad code)
Example Language:
int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b');
// Here we can inject code to execute.

The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.



+ Weakness Ordinalities
Ordinality Description
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 738 CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 872 CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 998 SFP Secondary Cluster: Glitch in Computation
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1158 SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1399 Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CERT C Secure Coding INT36-C Imprecise Converting a pointer to integer or integer to pointer
Software Fault Patterns SFP1 Glitch in computation
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction, Type
2023-01-31 CWE Content Team MITRE
updated Description
2021-03-15 CWE Content Team MITRE
updated Common_Consequences, Weakness_Ordinalities
2019-01-03 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Taxonomy_Mappings, White_Box_Definitions
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Common_Consequences, Description, Other_Notes
2009-03-10 CWE Content Team MITRE
updated Relationships
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-08-01 KDM Analytics
added/updated white box definitions
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-563: Assignment to Variable without Use

Weakness ID: 563
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The variable's value is assigned but never used, making it a dead store.
+ Extended Description
After the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.
+ Alternate Terms
Unused Variable
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Quality Degradation; Varies by Context

Scope: Other

This weakness could be an indication of a bug in the program or a deprecated variable that was not removed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.
+ Potential Mitigations
Phase(s) Mitigation

Implementation

Remove unused variables from the code.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 1164 Irrelevant Code
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1006 Bad Coding Practices
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Demonstrative Examples

Example 1


The following code excerpt assigns to the variable r and then overwrites the value without using it.

(bad code)
Example Language:
r = getName();
r = getNewBuffer(buf);


+ Weakness Ordinalities
Ordinality Description
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods
Method Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 747 CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 883 CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 886 SFP Primary Cluster: Unused entities
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1186 SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1412 Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CERT C Secure Coding MSC00-C Compile cleanly at high warning levels
SEI CERT Perl Coding Standard MSC01-PL Imprecise Detect and remove unused variables
Software Fault Patterns SFP2 Unused Entities
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships, Type
2021-03-15 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2017-11-08 CWE Content Team MITRE
updated Alternate_Terms, Name, Relationships, Taxonomy_Mappings
2014-07-30 CWE Content Team MITRE
updated Taxonomy_Mappings
2014-06-23 CWE Content Team MITRE
updated Common_Consequences, Description, Name, Other_Notes
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-05-27 CWE Content Team MITRE
updated Demonstrative_Examples
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2014-06-23 Unused Variable
2017-11-08 Assignment to Variable without Use ('Unused Variable')

CWE-1282: Assumed-Immutable Data is Stored in Writable Memory

Weakness ID: 1282
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
Immutable data, such as a first-stage bootloader, device identifiers, and "write-once" configuration settings are stored in writable memory that can be re-programmed or updated in the field.
+ Extended Description

Security services such as secure boot, authentication of code and data, and device attestation all require assets such as the first stage bootloader, public keys, golden hash digests, etc. which are implicitly trusted. Storing these assets in read-only memory (ROM), fuses, or one-time programmable (OTP) memory provides strong integrity guarantees and provides a root of trust for securing the rest of the system. Security is lost if assets assumed to be immutable can be modified.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Varies by Context

Scope: Integrity

+ Potential Mitigations
Phase(s) Mitigation

Implementation

All immutable code or data should be programmed into ROM or write-once memory.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 668 Exposure of Resource to Wrong Sphere
CanPrecede Base Base - a 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. 471 Modification of Assumed-Immutable Data (MAID)
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1202 Memory and Storage Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation Keys, code, configuration settings, and other data should be programmed in write-once or read-only memory instead of writable memory.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Cryptographic hash functions are commonly used to create unique fixed-length digests used to ensure the integrity of code and keys. A golden digest is stored on the device and compared to the digest computed from the data to be verified. If the digests match, the data has not been maliciously modified. If an attacker can modify the golden digest they then have the ability to store arbitrary data that passes the verification check. Hash digests used to verify public keys and early stage boot code should be immutable, with the strongest protection offered by hardware immutability.



+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.

Maintenance

As of CWE 4.3, CWE-1282 and CWE-1233 are being investigated for potential duplication or overlap.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-05-15
(CWE 4.1, 2020-02-24)
Nicole Fern Cycuity (originally submitted as Tortuga Logic)
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Related_Attack_Patterns
2022-04-28 CWE Content Team MITRE
updated Related_Attack_Patterns
2021-07-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2021-03-15 CWE Content Team MITRE
updated Maintenance_Notes
2020-08-20 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Name
+ Previous Entry Names
Change Date Previous Entry Name
2020-08-20 Assumed-Immutable Data Stored in Writable Memory

CWE-405: Asymmetric Resource Consumption (Amplification)

Weakness ID: 405
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
+ Extended Description
This can lead to poor performance due to "amplification" of resource consumption, typically in a non-linear fashion. This situation is worsened if the product allows malicious users or attackers to consume more resources than their access level permits.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

DoS: Amplification; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

Scope: Availability

Likelihood: High

Sometimes this is a factor in "flood" attacks, but other types of amplification exist.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

An application must make resources available to a client commensurate with the client's access level.

Architecture and Design

An application must, at all times, keep track of allocated resources and meter their usage appropriately.

System Configuration

Consider disabling resource-intensive algorithms on the server side, such as Diffie-Hellman key exchange.

Effectiveness: High

Note: Business requirements may prevent disabling resource-intensive algorithms.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 400 Uncontrolled Resource Consumption
ParentOf Class Class - a weakness that is 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. 406 Insufficient Control of Network Message Volume (Network Amplification)
ParentOf Class Class - a weakness that is 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. 407 Inefficient Algorithmic Complexity
ParentOf Base Base - a 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. 408 Incorrect Behavior Order: Early Amplification
ParentOf Base Base - a 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. 409 Improper Handling of Highly Compressed Data (Data Amplification)
ParentOf Base Base - a 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. 776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
ParentOf Base Base - a 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. 1050 Excessive Platform Resource Consumption within a Loop
ParentOf Base Base - a 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. 1072 Data Resource Access without Use of Connection Pooling
ParentOf Base Base - a 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. 1073 Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
ParentOf Base Base - a 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. 1084 Invokable Control Element with Excessive File or Data Access Operations
ParentOf Base Base - a 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. 1089 Large Data Table with Excessive Number of Indices
ParentOf Base Base - a 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. 1094 Excessive Index Range Scan for a Data Resource
ParentOf Class Class - a weakness that is 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. 1176 Inefficient CPU Computation
PeerOf Class Class - a weakness that is 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. 404 Improper Resource Shutdown or Release
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: Client Server (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


This code listens on a port for DNS requests and sends the result to the requesting address.

(bad code)
Example Language: Python 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind( (UDP_IP,UDP_PORT) )
while true:
data = sock.recvfrom(1024)
if not data:
break

(requestIP, nameToResolve) = parseUDPpacket(data)
record = resolveName(nameToResolve)
sendResponse(requestIP,record)

This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic.



Example 2


This function prints the contents of a specified file requested by a user.

(bad code)
Example Language: PHP 
function printFile($username,$filename){

//read file into string
$file = file_get_contents($filename);
if ($file && isOwnerOf($username,$filename)){
echo $file;
return true;
}
else{
echo 'You are not authorized to view this file';
}
return false;
}

This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway.



Example 3


The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected.

(attack code)
Example Language: XML 
<?xml version="1.0"?>
<!DOCTYPE MaliciousDTD [
<!ENTITY ZERO "A">
<!ENTITY ONE "&ZERO;&ZERO;">
<!ENTITY TWO "&ONE;&ONE;">
...
<!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;">
]>
<data>&THIRTYTWO;</data>


Example 4


This example attempts to check if an input string is a "sentence" [REF-1164].

(bad code)
Example Language: JavaScript 
var test_string = "Bad characters: $@#";
var bad_pattern = /^(\w+\s?)*$/i;
var result = test_string.search(bad_pattern);

The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases.

To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

(good code)
Example Language: JavaScript 
var test_string = "Bad characters: $@#";
var good_pattern = /^((?=(\w+))\2\s?)*$/i;
var result = test_string.search(good_pattern);

Note that [REF-1164] has a more thorough (and lengthy) explanation of everything going on within the RegEx.



Example 5


An adversary can cause significant resource consumption on a server by filtering the cryptographic algorithms offered by the client to the ones that are the most resource-intensive on the server side. After discovering which cryptographic algorithms are supported by the server, a malicious client can send the initial cryptographic handshake messages that contains only the resource-intensive algorithms. For some cryptographic protocols, these messages can be completely prefabricated, as the resource-intensive part of the handshake happens on the server-side first (such as TLS), rather than on the client side. In the case of cryptographic protocols where the resource-intensive part should happen on the client-side first (such as SSH), a malicious client can send a forged/precalculated computation result, which seems correct to the server, so the resource-intensive part of the handshake is going to happen on the server side. A malicious client is required to send only the initial messages of a cryptographic handshake to initiate the resource-consuming part of the cryptographic handshake. These messages are usually small, and generating them requires minimal computational effort, enabling a denial-of-service attack. An additional risk is the fact that higher key size increases the effectiveness of the attack. Cryptographic protocols where the clients have influence over the size of the used key (such as TLS 1.3 or SSH) are most at risk, as the client can enforce the highest key size supported by the server.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Classic "Smurf" attack, using spoofed ICMP packets to broadcast addresses.
Parsing library allows XML bomb
Tool creates directories before authenticating user.
Python has "quadratic complexity" issue when converting string to int with many digits in unexpected bases
server allows ReDOS with crafted User-Agent strings, due to overlapping capture groups that cause excessive backtracking.
composite: NTP feature generates large responses (high amplification factor) with spoofed UDP source addresses.
Diffie-Hellman (DHE) Key Agreement Protocol allows attackers to send arbitrary numbers that are not public keys, which causes the server to perform expensive, unnecessary computation of modular exponentiation.
The Diffie-Hellman Key Agreement Protocol allows use of long exponents, which are more computationally expensive than using certain "short exponents" with particular properties.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 730 OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 855 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1145 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason Abstraction

Rationale

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments

Examine children of this entry to see if there is a better fit
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Asymmetric resource consumption (amplification)
OWASP Top Ten 2004 A9 CWE More Specific Denial of Service
WASC 41 XML Attribute Blowup
The CERT Oracle Secure Coding Standard for Java (2011) TPS00-J Use thread pools to enable graceful degradation of service during traffic bursts
The CERT Oracle Secure Coding Standard for Java (2011) FIO04-J Release resources when they are no longer needed
+ References
[REF-1164] Ilya Kantor. "Catastrophic backtracking". 2020-12-13.
<https://javascript.info/regexp-catastrophic-backtracking>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2021-11-11 Szilárd Pfeiffer Balasys IT Security
Submitted content that led to modifications in applicable platforms, common consequences, potential mitigations, demonstrative examples, observed examples.
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Time_of_Introduction
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Functional_Areas
2015-12-07 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-12-13 CWE Content Team MITRE
updated Description
2010-02-16 CWE Content Team MITRE
updated Taxonomy_Mappings
2009-07-27 CWE Content Team MITRE
updated Common_Consequences, Other_Notes
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-588: Attempt to Access Child of a Non-structure Pointer

Weakness ID: 588
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Modify Memory

Scope: Integrity

Adjacent variables in memory may be corrupted by assignments performed on fields after the cast.

DoS: Crash, Exit, or Restart

Scope: Availability

Execution may end due to a memory access error.
+ Potential Mitigations
Phase(s) Mitigation

Requirements

The choice could be made to use a language that is not susceptible to these issues.

Implementation

Review of type casting operations can identify locations where incompatible types are cast.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 704 Incorrect Type Conversion or Cast
ChildOf Class Class - a weakness that is 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. 758 Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Demonstrative Examples

Example 1


The following example demonstrates the weakness.

(bad code)
Example Language:
struct foo
{
int i;
}
...
int main(int argc, char **argv)
{
*foo = (struct foo *)main;
foo->i = 2;
return foo->i;
}


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
JSON decoder accesses a C union using an invalid offset to an object
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 971 SFP Secondary Cluster: Faulty Pointer Use
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
Software Fault Patterns SFP7 Faulty Pointer Use
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Common_Consequences, Other_Notes
2009-03-10 CWE Content Team MITRE
updated Relationships
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-289: Authentication Bypass by Alternate Name

Weakness ID: 289
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 1390 Weak Authentication
CanFollow Variant Variant - 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. 46 Path Equivalence: 'filename ' (Trailing Space)
CanFollow Variant Variant - 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. 52 Path Equivalence: '/multiple/trailing/slash//'
CanFollow Variant Variant - 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. 173 Improper Handling of Alternate Encoding
CanFollow Base Base - a 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. 178 Improper Handling of Case Sensitivity
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Protection mechanism that restricts URL access can be bypassed using URL encoding.
Bypass of authentication for files using "\" (backslash) or "%5C" (encoded backslash).
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 845 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 947 SFP Secondary Cluster: Authentication Bypass
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1134 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues.

Theoretical

Alternate names are useful in data driven manipulation attacks, not just for authentication.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication bypass by alternate name
The CERT Oracle Secure Coding Standard for Java (2011) IDS01-J CWE More Specific Normalize strings before validating them
SEI CERT Oracle Coding Standard for Java IDS01-J CWE More Specific Normalize strings before validating them
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Type
2022-10-13 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Potential_Mitigations
2009-07-27 CWE Content Team MITRE
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction

CWE-302: Authentication Bypass by Assumed-Immutable Data

Weakness ID: 302
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design; Operation; Implementation

Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 807 Reliance on Untrusted Inputs in a Security Decision
ChildOf Class Class - a weakness that is 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. 1390 Weak Authentication
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system.

(bad code)
Example Language: Java 
boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) {
...
}

Modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
DebPloit
Web auth
Authentication bypass by setting certain cookies to "true".
Authentication bypass by setting certain cookies to "true".
Admin access by setting a cookie.
Gain privileges by setting cookie.
Product trusts authentication information in cookie.
Authentication bypass by setting admin-testing variable to true.
Bypass auth and gain privileges by setting a variable.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 724 OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 859 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 949 SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication Bypass via Assumed-Immutable Data
OWASP Top Ten 2004 A1 CWE More Specific Unvalidated Input
The CERT Oracle Secure Coding Standard for Java (2011) SEC02-J Do not base security checks on untrusted sources
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Type
2022-10-13 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2009-03-10 CWE Content Team MITRE
updated Relationships
2008-10-14 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples

CWE-294: Authentication Bypass by Capture-replay

Weakness ID: 294
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
+ Extended Description
Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely on observing previously-sent valid commands, then changing them slightly if necessary and resending the same commands to the server.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Gain Privileges or Assume Identity

Scope: Access Control

Messages sent with a capture-relay attack allow access to resources which are not otherwise accessible without proper authentication.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.

Architecture and Design

Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 1390 Weak Authentication
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 287 Improper Authentication
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
Chain: cleartext transmission of the MD5 hash of password (CWE-319) enables attacks against a server that is susceptible to replay (CWE-294).
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 956 SFP Secondary Cluster: Channel Attack
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication bypass by replay
CLASP Capture-replay
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Related_Attack_Patterns
2022-10-13 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Observed_Examples, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples
2009-10-29 CWE Content Team MITRE
updated Observed_Examples
2009-07-27 CWE Content Team MITRE
updated Description, Other_Notes, Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings

CWE-305: Authentication Bypass by Primary Weakness

Weakness ID: 305
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 1390 Weak Authentication
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
The provided password is only compared against the first character of the real password.
The password is not properly checked, which allows remote attackers to bypass access controls by sending a 1-byte password that matches the first character of the real password.
Chain: Forum software does not properly initialize an array, which inadvertently sets the password to a single character, allowing remote attackers to easily guess the password and gain administrative privileges.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 947 SFP Secondary Cluster: Authentication Bypass
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

Most "authentication bypass" errors are resultant, not primary.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication Bypass by Primary Weakness
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction
2022-10-13 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Observed_Examples, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2008-09-08 CWE Content Team MITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-290: Authentication Bypass by Spoofing

Weakness ID: 290
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism; Gain Privileges or Assume Identity

Scope: Access Control

This weakness can allow an attacker to access resources which are not otherwise accessible without proper authentication.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 1390 Weak Authentication
ParentOf Variant Variant - 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. 291 Reliance on IP Address for Authentication
ParentOf Variant Variant - 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. 293 Using Referer Field for Authentication
ParentOf Variant Variant - 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. 350 Reliance on Reverse DNS Resolution for a Security-Critical Action
PeerOf Class Class - a weakness that is 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. 602 Client-Side Enforcement of Server-Side Security
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 287 Improper Authentication
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Demonstrative Examples

Example 1


The following code authenticates users.

(bad code)
Example Language: Java 
String sourceIP = request.getRemoteAddr();
if (sourceIP != null && sourceIP.equals(APPROVED_IP)) {
authenticated = true;
}

The authentication mechanism implemented relies on an IP address for source validation. If an attacker is able to spoof the IP, they may be able to bypass the authentication mechanism.



Example 2


Both of these examples check if a request is from a trusted address before responding to the request.

(bad code)
Example Language:
sd = socket(AF_INET, SOCK_DGRAM, 0);
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
servr.sin_port = htons(1008);
bind(sd, (struct sockaddr *) & serv, sizeof(serv));

while (1) {
memset(msg, 0x0, MAX_MSG);
clilen = sizeof(cli);
if (inet_ntoa(cli.sin_addr)==getTrustedAddress()) {
n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen);
}
}
(bad code)
Example Language: Java 
while(true) {
DatagramPacket rp=new DatagramPacket(rData,rData.length);
outSock.receive(rp);
String in = new String(p.getData(),0, rp.getLength());
InetAddress clientIPAddress = rp.getAddress();
int port = rp.getPort();

if (isTrustedAddress(clientIPAddress) & secretKey.equals(in)) {
out = secret.getBytes();
DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port); outSock.send(sp);
}
}

The code only verifies the address as stored in the request packet. An attacker can spoof this address, thus impersonating a trusted client.



Example 3


The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

(bad code)
Example Language:
struct hostent *hp;struct in_addr myaddr;
char* tHost = "trustme.example.com";
myaddr.s_addr=inet_addr(ip_addr_string);

hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {
trusted = true;
} else {
trusted = false;
}
(bad code)
Example Language: Java 
String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {
trusted = true;
}
(bad code)
Example Language: C# 
IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
if (hostInfo.HostName.EndsWith("trustme.com")) {
trusted = true;
}

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
S-bus functionality in a home automation product performs access control using an IP allowlist, which can be bypassed by a forged IP address.
VOIP product allows authentication bypass using 127.0.0.1 in the Host header.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 956 SFP Secondary Cluster: Channel Attack
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

This can be resultant from insufficient verification.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication bypass by spoofing
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Spoofing and Identification", Page 72. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-01-31 CWE Content Team MITRE
updated Description
2022-10-13 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2013-07-17 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Relationship_Notes
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Relationship_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples

CWE-288: Authentication Bypass Using an Alternate Path or Channel

Weakness ID: 288
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product requires authentication, but the product has an alternate path or channel that does not require authentication. Diagram for CWE-288
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 306 Missing Authentication for Critical Function
ParentOf Base Base - a 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. 425 Direct Request ('Forced Browsing')
ParentOf Base Base - a 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. 1299 Missing Protection Mechanism for Alternate Hardware Interface
PeerOf Base Base - a 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. 420 Unprotected Alternate Channel
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Relevant to the view "CISQ Data Protection Measures" (View-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that 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. 284 Improper Access Control
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Architecture and Design This is often seen in web applications that assume that access to a particular CGI program can only be obtained through a "front" screen, when the supporting programs are directly accessible. But this problem is not just in web apps.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Register SECURE_ME is located at address 0xF00. A mirror of this register called COPY_OF_SECURE_ME is at location 0x800F00. The register SECURE_ME is protected from malicious agents and only allows access to select, while COPY_OF_SECURE_ME is not.

Access control is implemented using an allowlist (as indicated by acl_oh_allowlist). The identity of the initiator of the transaction is indicated by the one hot input, incoming_id. This is checked against the acl_oh_allowlist (which contains a list of initiators that are allowed to access the asset).

Though this example is shown in Verilog, it will apply to VHDL as well.

(informative)
Example Language: Verilog 
module foo_bar(data_out, data_in, incoming_id, address, clk, rst_n);
output [31:0] data_out;
input [31:0] data_in, incoming_id, address;
input clk, rst_n;
wire write_auth, addr_auth;
reg [31:0] data_out, acl_oh_allowlist, q;
assign write_auth = | (incoming_id & acl_oh_allowlist) ? 1 : 0;
always @*
acl_oh_allowlist <= 32'h8312;
assign addr_auth = (address == 32'hF00) ? 1: 0;
always @ (posedge clk or negedge rst_n)
if (!rst_n)
begin
q <= 32'h0;
data_out <= 32'h0;
end
else
begin
q <= (addr_auth & write_auth) ? data_in: q;
data_out <= q;
end
end
endmodule
(bad code)
Example Language: Verilog 
assign addr_auth = (address == 32'hF00) ? 1: 0;

The bugged line of code is repeated in the Bad example above. Weakness arises from the fact that the SECURE_ME register can be modified by writing to the shadow register COPY_OF_SECURE_ME, the address of COPY_OF_SECURE_ME should also be included in the check. That buggy line of code should instead be replaced as shown in the Good Code Snippet below.

(good code)
Example Language: Verilog 
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Router allows remote attackers to read system logs without authentication by directly connecting to the login screen and typing certain control characters.
Attackers with physical access to the machine may bypass the password prompt by pressing the ESC (Escape) key.
OS allows local attackers to bypass the password protection of idled sessions via the programmer's switch or CMD-PWR keyboard sequence, which brings up a debugger that the attacker can use to disable the lock.
Direct request of installation file allows attacker to create administrator accounts.
Attackers may gain additional privileges by directly requesting the web management URL.
Bypass authentication via direct request to named pipe.
User can avoid lockouts by using an API instead of the GUI to conduct brute force password guessing.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 721 OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 947 SFP Secondary Cluster: Authentication Bypass
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

overlaps Unprotected Alternate Channel
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication Bypass by Alternate Path/Channel
OWASP Top Ten 2007 A10 CWE More Specific Failure to Restrict URL Access
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2024-09-29
(CWE 4.16, 2024-11-19)
Abhi Balakrishnan
Contributed usability diagram concepts used by the CWE team
+ Modifications
Modification Date Modifier Organization
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Description, Diagram
2023-10-26 CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Relationships
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2008-09-08 CWE Content Team MITRE
updated Description, Modes_of_Introduction, Name, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings, Type
+ Previous Entry Names
Change Date Previous Entry Name
2008-09-09 Authentication Bypass by Alternate Path/Channel

CWE-593: Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created

Weakness ID: 593
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product modifies the SSL context after connection creation has begun.
+ Extended Description
If the program modifies the SSL_CTX object after creating SSL objects from it, there is the possibility that older SSL objects created from the original context could all be affected by that change.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

No authentication takes place in this process, bypassing an assumed protection of encryption.

Read Application Data

Scope: Confidentiality

The encrypted communication between a user and a trusted host may be subject to a sniffing attack.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Use a language or a library that provides a cryptography framework at a higher level of abstraction.

Implementation

Most SSL_CTX functions have SSL counterparts that act on SSL-type objects.

Implementation

Applications should set up an SSL_CTX completely, before creating SSL objects from it.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 666 Operation on Resource in Wrong Phase of Lifetime
ChildOf Class Class - a weakness that is 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. 1390 Weak Authentication
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Demonstrative Examples

Example 1


The following example demonstrates the weakness.

(bad code)
Example Language:
#define CERT "secret.pem"
#define CERT2 "secret2.pem"

int main(){
SSL_CTX *ctx;
SSL *ssl;
init_OpenSSL();
seed_prng();

ctx = SSL_CTX_new(SSLv23_method());

if (SSL_CTX_use_certificate_chain_file(ctx, CERT) != 1)
int_error("Error loading certificate from file");


if (SSL_CTX_use_PrivateKey_file(ctx, CERT, SSL_FILETYPE_PEM) != 1)
int_error("Error loading private key from file");


if (!(ssl = SSL_new(ctx)))
int_error("Error creating an SSL context");


if ( SSL_CTX_set_default_passwd_cb(ctx, "new default password" != 1))
int_error("Doing something which is dangerous to do anyways");


if (!(ssl2 = SSL_new(ctx)))
int_error("Error creating an SSL context");
}


+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 948 SFP Secondary Cluster: Digital Certificate
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction
2023-01-31 CWE Content Team MITRE
updated Description
2022-10-13 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Common_Consequences, Relationships
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-07-27 CWE Content Team MITRE
updated Description, Other_Notes, Potential_Mitigations
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Other_Notes
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-639: Authorization Bypass Through User-Controlled Key

Weakness ID: 639
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
+ Extended Description

Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.

For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.

One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.

+ Alternate Terms
Insecure Direct Object Reference / IDOR
The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.
Broken Object Level Authorization / BOLA
BOLA is used in the 2019 OWASP API Security Top 10 and is said to be the same as IDOR.
Horizontal Authorization
"Horizontal Authorization" is used to describe situations in which two users have the same privilege level, but must be prevented from accessing each other's resources. This is fairly common when using key-based access to resources in a multi-user context.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

Access control checks for specific user data or functionality can be bypassed.

Gain Privileges or Assume Identity

Scope: Access Control

Horizontal escalation of privilege is possible (one user can view/modify information of another user).

Gain Privileges or Assume Identity

Scope: Access Control

Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Architecture and Design; Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 863 Incorrect Authorization
ParentOf Variant Variant - 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. 566 Authorization Bypass Through User-Controlled SQL Primary Key
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 840 Business Logic Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1212 Authorization Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is 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. 863 Incorrect Authorization
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Relevant to the view "CISQ Data Protection Measures" (View-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that 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. 284 Improper Access Control
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user.

(bad code)
Example Language: C# 
...
conn = new SqlConnection(_ConnectionString);
conn.Open();
int16 id = System.Convert.ToInt16(invoiceID.Text);
SqlCommand query = new SqlCommand( "SELECT * FROM invoices WHERE id = @id", conn);
query.Parameters.AddWithValue("@id", id);
SqlDataReader objReader = objCommand.ExecuteReader();
...

The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
An educational application does not appropriately restrict file IDs to a particular user. The attacker can brute-force guess IDs, indicating IDOR.
+ Detection Methods
Method Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 715 OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 723 OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 932 OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 945 SFP Secondary Cluster: Insecure Resource Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1031 OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny Lebanidze Cigital
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Alternate_Terms
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Alternate_Terms
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2018-03-27 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2013-07-17 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Alternate_Terms, Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships
2011-03-29 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
2010-06-21 CWE Content Team MITRE
updated Relationships
2009-10-29 CWE Content Team MITRE
updated Common_Consequences
2009-05-27 CWE Content Team MITRE
updated Relationships
2009-03-10 CWE Content Team MITRE
updated Relationships
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Type
+ Previous Entry Names
Change Date Previous Entry Name
2011-03-29 Access Control Bypass Through User-Controlled Key

CWE-566: Authorization Bypass Through User-Controlled SQL Primary Key

Weakness ID: 566
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
+ Extended Description

When a user can set a primary key to any value, then the user can modify the key to point to unauthorized records.

Database access control errors occur when:

  • Data enters a program from an untrusted source.
  • The data is used to specify the value of a primary key in a SQL query.
  • The untrusted source does not have the permissions to be able to access all rows in the associated table.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Read Application Data; Modify Application Data; Bypass Protection Mechanism

Scope: Confidentiality, Integrity, Access Control

+ Potential Mitigations
Phase(s) Mitigation

Implementation

Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" validation strategy.

Implementation

Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Base Base - a 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. 639 Authorization Bypass Through User-Controlled Key
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

SQL (Often Prevalent)

Technologies

Database Server (Often Prevalent)

+ Demonstrative Examples

Example 1


The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user.

(bad code)
Example Language: C# 
...
conn = new SqlConnection(_ConnectionString);
conn.Open();
int16 id = System.Convert.ToInt16(invoiceID.Text);
SqlCommand query = new SqlCommand( "SELECT * FROM invoices WHERE id = @id", conn);
query.Parameters.AddWithValue("@id", id);
SqlDataReader objReader = objCommand.ExecuteReader();
...

The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.



+ Detection Methods
Method Details

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 994 SFP Secondary Cluster: Tainted Input to Variable
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
Software Fault Patterns SFP25 Tainted input to variable
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Applicable_Platforms
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Name
2010-06-21 CWE Content Team MITRE
updated Description
2009-07-27 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Taxonomy_Mappings
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2011-03-29 Access Control Bypass Through User-Controlled SQL Primary Key

CWE-439: Behavioral Change in New Version or Environment

Weakness ID: 439
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A's behavior or functionality changes with a new version of A, or a new environment, which is not known (or manageable) by B.
+ Alternate Terms
Functional change
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. 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.
Impact Details

Quality Degradation; Varies by Context

Scope: Other

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that 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. 435 Improper Interaction Between Multiple Correctly-Behaving Entities