CWE - VIEW SLICE: CWE-868: Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version) (4.17)

CWE VIEW: Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)

View ID: 868

Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Type: Graph

Downloads: Booklet | CSV | XML

Objective

CWE entries in this view (graph) are fully or partially eliminated by following the SEI CERT C++ Coding Standard, as published in 2016. This view is no longer being actively maintained, since it statically represents the coding rules as they were in 2016.

Audience

Stakeholder	Description
Software Developers	By following the CERT C++ Secure Coding Standard, developers will be able to fully or partially prevent the weaknesses that are identified in this view. In addition, developers can use a CWE coverage graph to determine which weaknesses are not directly addressed by the standard, which will help identify and resolve remaining gaps in training, tool acquisition, or other approaches for reducing weaknesses.
Product Customers	If a software developer claims to be following the CERT C++ Secure Coding Standard, then customers can search for the weaknesses in this view in order to formulate independent evidence of that claim.
Educators	Educators can use this view in multiple ways. For example, if there is a focus on teaching weaknesses, the educator could link them to the relevant Secure Coding Standard.

Relationships

div.collapseblock { display:inline }

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:

Expand All | Collapse All

868 - Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 01 - Preprocessor (PRE) - (869)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 869 (CERT C++ Secure Coding Section 01 - Preprocessor (PRE))

Weaknesses in this category are related to rules in the Preprocessor (PRE) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 02 - Declarations and Initialization (DCL) - (870)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 870 (CERT C++ Secure Coding Section 02 - Declarations and Initialization (DCL))

Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 03 - Expressions (EXP) - (871)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 871 (CERT C++ Secure Coding Section 03 - Expressions (EXP))

Weaknesses in this category are related to rules in the Expressions (EXP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 871 (CERT C++ Secure Coding Section 03 - Expressions (EXP)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 871 (CERT C++ Secure Coding Section 03 - Expressions (EXP)) > 480 (Use of Incorrect Operator)

The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 871 (CERT C++ Secure Coding Section 03 - Expressions (EXP)) > 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 04 - Integers (INT) - (872)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT))

Weaknesses in this category are related to rules in the Integers (INT) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 192 (Integer Coercion Error)

Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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.

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)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 369 (Divide By Zero)

The product divides a value by zero.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 587 (Assignment of a Fixed Address to a Pointer)

The product sets a pointer to a specific address other than NULL or 0.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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.

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)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 872 (CERT C++ Secure Coding Section 04 - Integers (INT)) > 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP) - (873)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP))

Weaknesses in this category are related to rules in the Floating Point Arithmetic (FLP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) > 369 (Divide By Zero)

The product divides a value by zero.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) > 681 (Incorrect Conversion between Numeric Types)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 873 (CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)) > 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR) - (874)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR))

Weaknesses in this category are related to rules in the Arrays and the STL (ARR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 129 (Improper Validation of Array Index)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 874 (CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)) > 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 07 - Characters and Strings (STR) - (875)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR))

Weaknesses in this category are related to rules in the Characters and Strings (STR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 170 (Improper Null Termination)

The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 464 (Addition of Data Structure Sentinel)

The accidental addition of a data-structure sentinel can cause serious programming logic problems.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 704 (Incorrect Type Conversion or Cast)

The product does not correctly convert an object, resource, or structure from one type to a different type.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 875 (CERT C++ Secure Coding Section 07 - Characters and Strings (STR)) > 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 08 - Memory Management (MEM) - (876)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM))

Weaknesses in this category are related to rules in the Memory Management (MEM) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 190 (Integer Overflow or Wraparound)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 404 (Improper Resource Shutdown or Release)

The product does not release or incorrectly releases a resource before it is made available for re-use.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 415 (Double Free)

The product calls free() twice on the same memory address. Double-free

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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().

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

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)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 876 (CERT C++ Secure Coding Section 08 - Memory Management (MEM)) > 822 (Untrusted Pointer Dereference)

The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 09 - Input Output (FIO) - (877)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO))

Weaknesses in this category are related to rules in the Input Output (FIO) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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).

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 276 (Incorrect Default Permissions)

During installation, installed file permissions are set to allow anyone to modify those files.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 391 (Unchecked Error Condition)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 404 (Improper Resource Shutdown or Release)

The product does not release or incorrectly releases a resource before it is made available for re-use.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 552 (Files or Directories Accessible to External Parties)

The product makes files or directories accessible to unauthorized actors, even though they should not be.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 877 (CERT C++ Secure Coding Section 09 - Input Output (FIO)) > 770 (Allocation of Resources Without Limits or Throttling)

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 10 - Environment (ENV) - (878)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV))

Weaknesses in this category are related to rules in the Environment (ENV) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 462 (Duplicate Key in Associative List (Alist))

Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 878 (CERT C++ Secure Coding Section 10 - Environment (ENV)) > 88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 11 - Signals (SIG) - (879)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 879 (CERT C++ Secure Coding Section 11 - Signals (SIG))

Weaknesses in this category are related to rules in the Signals (SIG) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 879 (CERT C++ Secure Coding Section 11 - Signals (SIG)) > 479 (Signal Handler Use of a Non-reentrant Function)

The product defines a signal handler that calls a non-reentrant function.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 879 (CERT C++ Secure Coding Section 11 - Signals (SIG)) > 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR) - (880)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR))

Weaknesses in this category are related to rules in the Exceptions and Error Handling (ERR) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 390 (Detection of Error Condition Without Action)

The product detects a specific error, but takes no actions to handle the error.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 391 (Unchecked Error Condition)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 880 (CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)) > 755 (Improper Handling of Exceptional Conditions)

The product does not handle or incorrectly handles an exceptional condition.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 13 - Object Oriented Programming (OOP) - (881)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 881 (CERT C++ Secure Coding Section 13 - Object Oriented Programming (OOP))

Weaknesses in this category are related to rules in the Object Oriented Programming (OOP) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 14 - Concurrency (CON) - (882)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON))

Weaknesses in this category are related to rules in the Concurrency (CON) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 404 (Improper Resource Shutdown or Release)

The product does not release or incorrectly releases a resource before it is made available for re-use.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 882 (CERT C++ Secure Coding Section 14 - Concurrency (CON)) > 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.

Category - a CWE entry that contains a set of other entries that share a common characteristic. CERT C++ Secure Coding Section 49 - Miscellaneous (MSC) - (883)

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC))

Weaknesses in this category are related to rules in the Miscellaneous (MSC) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 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

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 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."

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 176 (Improper Handling of Unicode Encoding)

The product does not properly handle when an input contains Unicode encoding.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 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.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 327 (Use of a Broken or Risky Cryptographic Algorithm)

The product uses a broken or risky cryptographic algorithm or protocol.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 330 (Use of Insufficiently Random Values)

The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 480 (Use of Incorrect Operator)

The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 482 (Comparing instead of Assigning)

The code uses an operator for comparison when the intention was to perform an assignment.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 561 (Dead Code)

The product contains dead code, which can never be executed.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 563 (Assignment to Variable without Use)

The variable's value is assigned but never used, making it a dead store. Unused Variable

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 570 (Expression is Always False)

The product contains an expression that will always evaluate to false.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 571 (Expression is Always True)

The product contains an expression that will always evaluate to true.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 697 (Incorrect Comparison)

The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.

868 (Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)) > 883 (CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)) > 704 (Incorrect Type Conversion or Cast)

The product does not correctly convert an object, resource, or structure from one type to a different type.

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

The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.

References

[REF-847] The Software Engineering Institute. "SEI CERT C++ Coding Standard". <https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682>.

View Metrics

	CWEs in this view		Total CWEs
Weaknesses	95	out of	943
Categories	15	out of	374
Views	0	out of	51
Total	110	out of	1368

Content History

Submissions
Submission Date	Submitter	Organization
2011-08-04 (CWE 2.1, 2011-09-13)	CWE Content Team	MITRE
2011-08-04 (CWE 2.1, 2011-09-13)
Modifications
Modification Date	Modifier	Organization
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Description, Maintenance_Notes, Name, References
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated View_Audience
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Description, Maintenance_Notes
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2019-01-03	Weaknesses Addressed by the CERT C++ Secure Coding Standard

View Components

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.

Description

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

This 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

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 - 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 - 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 - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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 - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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 - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.	399	Resource Management Errors
MemberOf	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 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.	1011	Authorize Actors

Modes Of Introduction

The 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

This 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: C

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: C

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: C

/* 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: C

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: C

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
CVE-2022-21668	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).
CVE-2009-4017	Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
CVE-2009-2726	Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
CVE-2009-2540	Large integer value for a length property in an object causes a large amount of memory allocation.
CVE-2009-2054	Product allows exhaustion of file descriptors when processing a large number of TCP packets.
CVE-2008-5180	Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
CVE-2008-1700	Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CVE-2005-4650	CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
CVE-2020-15100	web application scanner attempts to read an excessively large file created by a user, causing process termination
CVE-2020-7218	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

This 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - 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	Category - 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	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - 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	Category - 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	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).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	985	SFP Secondary Cluster: Unrestricted Consumption
MemberOf	Category - 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	Category - 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	Category - 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	Category - 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	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

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-125	Flooding
CAPEC-130	Excessive Allocation
CAPEC-147	XML Ping of the Death
CAPEC-197	Exponential Data Expansion
CAPEC-229	Serialized Data Parameter Blowup
CAPEC-230	Serialized Data with Nested Payloads
CAPEC-231	Oversized Serialized Data Payloads
CAPEC-469	HTTP DoS
CAPEC-482	TCP Flood
CAPEC-486	UDP Flood
CAPEC-487	ICMP Flood
CAPEC-488	HTTP Flood
CAPEC-489	SSL Flood
CAPEC-490	Amplification
CAPEC-491	Quadratic Data Expansion
CAPEC-493	SOAP Array Blowup
CAPEC-494	TCP Fragmentation
CAPEC-495	UDP Fragmentation
CAPEC-496	ICMP Fragmentation
CAPEC-528	XML Flood

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
2009-05-13 (CWE 1.4, 2009-05-27)
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
2023-11-14 (CWE 4.14, 2024-02-29)	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
2024-02-29 (CWE 4.14, 2024-02-29)	updated Taxonomy_Mappings
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Detection_Factors
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples, References
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Applicable_Platforms, Description, Maintenance_Notes, Potential_Mitigations, Relationship_Notes, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Demonstrative_Examples, Description, Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Related_Attack_Patterns
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Related_Attack_Patterns
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples, Detection_Factors, Relationships
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Demonstrative_Examples, Potential_Mitigations
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Related_Attack_Patterns

Weakness ID: 805

View customized information:

Description

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.

Extended Description

When the length value exceeds the size of the destination, a buffer overflow could occur.

Common Consequences

Impact	Details
Read Memory; Modify Memory; Execute Unauthorized Code or Commands	Scope: Integrity, Confidentiality, Availability Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. This can often be used to subvert any other security service.
Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU)	Scope: Availability Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Potential Mitigations

Phase(s)	Mitigation
Requirements	Strategy: Language Selection Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
Architecture and Design	Strategy: Libraries or Frameworks Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions. Note: This is not a complete solution, since many buffer overflows are not related to strings.
Operation; Build and Compilation	Strategy: Environment Hardening Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail. Effectiveness: Defense in Depth Note: This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.
Implementation	Consider adhering to the following rules when allocating and managing an application's memory: Double check that the buffer is as large as specified. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space. If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
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.
Operation; Build and Compilation	Strategy: Environment Hardening Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335]. Effectiveness: Defense in Depth Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333].
Operation	Strategy: Environment Hardening Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336]. Effectiveness: Defense in Depth Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.
Architecture and Design; Operation	Strategy: Environment Hardening Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the product or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Architecture and Design; Operation	Strategy: Sandbox or Jail Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails. Effectiveness: Limited Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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 - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	806	Buffer Access Using Size of Source Buffer
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	130	Improper Handling of Length Parameter Inconsistency

Relevant to the view "Software Development" (View-699)

Nature	Type	ID	Name
MemberOf	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 - 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 - 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

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Often Prevalent)

C++ (Often Prevalent)

Class: Assembly (Undetermined Prevalence)

Likelihood Of Exploit

High

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: C

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 under the assumption that the maximum length value of hostname is 64 bytes, 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: C

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

In the following example, the source character string is copied to the dest character string using the method strncpy.

(bad code)

Example Language: C

...
char source[21] = "the character string";
char dest[12];
strncpy(dest, source, sizeof(source)-1);
...

However, in the call to strncpy the source character string is used within the sizeof call to determine the number of characters to copy. This will create a buffer overflow as the size of the source character string is greater than the dest character string. The dest character string should be used within the sizeof call to ensure that the correct number of characters are copied, as shown below.

(good code)

Example Language: C

...
char source[21] = "the character string";
char dest[12];
strncpy(dest, source, sizeof(dest)-1);
...

Example 4

In this example, the method outputFilenameToLog outputs a filename to a log file. The method arguments include a pointer to a character string containing the file name and an integer for the number of characters in the string. The filename is copied to a buffer where the buffer size is set to a maximum size for inputs to the log file. The method then calls another method to save the contents of the buffer to the log file.

(bad code)

Example Language: C

#define LOG_INPUT_SIZE 40

// saves the file name to a log file
int outputFilenameToLog(char *filename, int length) {

int success;

// buffer with size set to maximum size for input to log file
char buf[LOG_INPUT_SIZE];

// copy filename to buffer
strncpy(buf, filename, length);

// save to log file
success = saveToLogFile(buf);

return success;

}

However, in this case the string copy method, strncpy, mistakenly uses the length method argument to determine the number of characters to copy rather than using the size of the local character string, buf. This can lead to a buffer overflow if the number of characters contained in character string pointed to by filename is larger then the number of characters allowed for the local character string. The string copy method should use the buf character string within a sizeof call to ensure that only characters up to the size of the buf array are copied to avoid a buffer overflow, as shown below.

(good code)

Example Language: C

...
// copy filename to buffer
strncpy(buf, filename, sizeof(buf)-1);
...

Example 5

Windows provides the MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes(), and BytesToUnicode() functions to convert between arbitrary multibyte (usually ANSI) character strings and Unicode (wide character) strings. The size arguments to these functions are specified in different units, (one in bytes, the other in characters) making their use prone to error.

In a multibyte character string, each character occupies a varying number of bytes, and therefore the size of such strings is most easily specified as a total number of bytes. In Unicode, however, characters are always a fixed size, and string lengths are typically given by the number of characters they contain. Mistakenly specifying the wrong units in a size argument can lead to a buffer overflow.

The following function takes a username specified as a multibyte string and a pointer to a structure for user information and populates the structure with information about the specified user. Since Windows authentication uses Unicode for usernames, the username argument is first converted from a multibyte string to a Unicode string.

(bad code)

Example Language: C

void getUserInfo(char *username, struct _USER_INFO_2 info){

WCHAR unicodeUser[UNLEN+1];
MultiByteToWideChar(CP_ACP, 0, username, -1, unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);

}

This function incorrectly passes the size of unicodeUser in bytes instead of characters. The call to MultiByteToWideChar() can therefore write up to (UNLEN+1)*sizeof(WCHAR) wide characters, or (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, to the unicodeUser array, which has only (UNLEN+1)*sizeof(WCHAR) bytes allocated.

If the username string contains more than UNLEN characters, the call to MultiByteToWideChar() will overflow the buffer unicodeUser.

Selected Observed Examples

Reference	Description
CVE-2011-1959	Chain: large length value causes buffer over-read (CWE-126)
CVE-2011-1848	Use of packet length field to make a calculation, then copy into a fixed-size buffer
CVE-2011-0105	Chain: retrieval of length value from an uninitialized memory location
CVE-2011-0606	Crafted length value in document reader leads to buffer overflow
CVE-2011-0651	SSL server overflow when the sum of multiple length fields exceeds a given value
CVE-2010-4156	Language interpreter API function doesn't validate length argument, leading to information exposure

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses)
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Method	Details
Automated Static Analysis	This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges. Effectiveness: High Note:Detection techniques for buffer-related errors are more mature than for most other weakness types.
Automated Dynamic Analysis	This weakness can be detected using dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Effectiveness: Moderate Note:Without visibility into the code, black box methods may not be able to sufficiently distinguish this weakness from others, requiring manual methods to diagnose the underlying problem.
Manual Analysis	Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	740	CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	874	CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOf	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).	884	CWE Cross-section
MemberOf	Category - 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	Category - 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.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	ARR38-C	Imprecise	Guarantee that library functions do not form invalid pointers

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-100	Overflow Buffers
CAPEC-256	SOAP Array Overflow

References

[REF-7]	Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 6, "Why ACLs Are Important" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-58]	Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. (URL validated: 2023-04-07)
[REF-59]	Arjan van de Ven. "Limiting buffer overflows with ExecShield". <https://archive.is/saAFo>. (URL validated: 2023-04-07)
[REF-60]	"PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. (URL validated: 2023-04-07)
[REF-741]	Jason Lam. "Top 25 Series - Rank 12 - Buffer Access with Incorrect Length Value". SANS Software Security Institute. 2010-03-11. <https://web.archive.org/web/20100316043717/http://blogs.sans.org:80/appsecstreetfighter/2010/03/11/top-25-series-rank-12-buffer-access-with-incorrect-length-value/>. (URL validated: 2023-04-07)
[REF-57]	Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/devel/safestr/work/safestr-1.0.3/doc/safestr.html>. (URL validated: 2023-04-07)
[REF-56]	Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. (URL validated: 2023-04-07)
[REF-61]	Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. (URL validated: 2023-04-07)
[REF-76]	Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. (URL validated: 2023-04-07)
[REF-64]	Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. (URL validated: 2023-04-07)
[REF-1332]	John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. (URL validated: 2023-04-26)
[REF-1333]	Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. (URL validated: 2023-04-26)
[REF-1334]	D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. (URL validated: 2023-04-26)
[REF-1335]	D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. (URL validated: 2023-04-26)
[REF-1336]	D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. (URL validated: 2023-04-26)
[REF-1337]	Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. (URL validated: 2023-04-26)

Content History

Submissions
Submission Date	Submitter	Organization
2010-01-15 (CWE 1.8, 2010-02-16)	CWE Content Team	MITRE
2010-01-15 (CWE 1.8, 2010-02-16)
Modifications
Modification Date	Modifier	Organization
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Demonstrative_Examples
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Potential_Mitigations, References, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Detection_Factors, Potential_Mitigations
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Demonstrative_Examples, Potential_Mitigations
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Common_Consequences
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Taxonomy_Mappings
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Demonstrative_Examples
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Potential_Mitigations, References
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Potential_Mitigations, References, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Demonstrative_Examples, Observed_Examples, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Potential_Mitigations
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Related_Attack_Patterns

Weakness ID: 120

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: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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:

Description

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.

Extended Description

A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.

Alternate Terms

Classic Buffer Overflow	This term was frequently used by vulnerability researchers during approximately 1995 to 2005 to differentiate buffer copies without length checks (which had been known about for decades) from other emerging weaknesses that still involved invalid accesses of buffers, as vulnerability researchers began to develop advanced exploitation techniques.
Unbounded Transfer

Common Consequences

Impact	Details
Modify Memory; Execute Unauthorized Code or Commands	Scope: Integrity, Confidentiality, Availability Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of the product's implicit security policy. This can often be used to subvert any other security service.
Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU)	Scope: Availability Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the product into an infinite loop.

Potential Mitigations

Phase(s)	Mitigation
Requirements	Strategy: Language Selection Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
Architecture and Design	Strategy: Libraries or Frameworks Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions. Note: This is not a complete solution, since many buffer overflows are not related to strings.
Operation; Build and Compilation	Strategy: Environment Hardening Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail. Effectiveness: Defense in Depth Note: This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.
Implementation	Consider adhering to the following rules when allocating and managing an application's memory: Double check that your buffer is as large as you specify. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space. If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
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.
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.
Operation; Build and Compilation	Strategy: Environment Hardening Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335]. Effectiveness: Defense in Depth Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]
Operation	Strategy: Environment Hardening Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336]. Effectiveness: Defense in Depth Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.
Build and Compilation; Operation	Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution.
Implementation	Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available. Effectiveness: Moderate Note: This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).
Architecture and Design	Strategy: Enforcement by Conversion When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
Architecture and Design; Operation	Strategy: Environment Hardening Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Architecture and Design; Operation	Strategy: Sandbox or Jail Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails. Effectiveness: Limited Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	785	Use of Path Manipulation Function without Maximum-sized Buffer
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	231	Improper Handling of Extra Values
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	456	Missing Initialization of a Variable
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	123	Write-what-where Condition

Relevant to the view "Software Development" (View-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
ChildOf	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	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 "CISQ Data Protection Measures" (View-1340)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 "Seven Pernicious Kingdoms" (View-700)

Nature	Type	ID	Name
ChildOf	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

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Often Prevalent)

C++ (Often Prevalent)

Class: Assembly (Undetermined Prevalence)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array.

(bad code)

Example Language: C

char last_name[20];
printf ("Enter your last name: ");
scanf ("%s", last_name);

The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total.

Example 2

The following code attempts to create a local copy of a buffer to perform some manipulations to the data.

(bad code)

Example Language: C

void manipulate_string(char * string){

char buf[24];
strcpy(buf, string);
...

}

However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter.

Example 3

The code below calls the gets() function to read in data from the command line.

(bad code)

Example Language: C

char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...

}

However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.

Example 4

In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file.

(bad code)

Example Language: C

...

struct hostent *clienthp;
char hostname[MAX_LEN];

// create server socket, bind to server address and listen on socket
...

// accept client connections and process requests
int count = 0;
for (count = 0; count < MAX_CONNECTIONS; count++) {

int clientlen = sizeof(struct sockaddr_in);
int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen);

if (clientsocket >= 0) {

clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name);
logOutput("Accepted client connection from host ", hostname);

// process client request
...
close(clientsocket);

}

}
close(serversocket);

...

However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.

Selected Observed Examples

Reference	Description
CVE-2000-1094	buffer overflow using command with long argument
CVE-1999-0046	buffer overflow in local program using long environment variable
CVE-2002-1337	buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
CVE-2003-0595	By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
CVE-2001-0191	By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses)
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Method	Details
Automated Static Analysis	This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges. Effectiveness: High Note:Detection techniques for buffer-related errors are more mature than for most other weakness types.
Automated Dynamic Analysis	This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Manual Analysis	Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.
Automated Static Analysis - Binary or Bytecode	According to SOAR, the following detection techniques may be useful: Highly cost effective: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis Effectiveness: High
Manual Static Analysis - Binary or Bytecode	According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation	According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation	According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer Effectiveness: SOAR Partial
Manual Static Analysis - Source Code	According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections) Effectiveness: SOAR Partial
Automated Static Analysis - Source Code	According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer Effectiveness: High
Architecture or Design Review	According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Effectiveness: High

Functional Areas

Memory Management

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	722	OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	726	OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOf	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	865	2011 Top 25 - Risky Resource Management
MemberOf	Category - 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	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).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	970	SFP Secondary Cluster: Faulty Buffer Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1129	CISQ Quality Measures (2016) - Reliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1131	CISQ Quality Measures (2016) - Security
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1161	SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOf	Category - 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-WITH-REVIEW (this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason	Frequent Misuse
Rationale	There are some indications that this CWE ID might be misused and selected simply because it mentions "buffer overflow" - an increasingly vague term. This CWE entry is only appropriate for "Buffer Copy" operations (not buffer reads), in which where there is no "Checking [the] Size of Input", and (by implication of the copy) writing past the end of the buffer.
Comments	If the vulnerability being analyzed involves out-of-bounds reads, then consider CWE-125 or descendants. For root cause analysis: if there is any input validation, consider children of CWE-20 such as CWE-1284. If there is a calculation error for buffer sizes, consider CWE-131 or similar.

Notes

Relationship

At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them.

Terminology

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Unbounded Transfer ('classic overflow')
7 Pernicious Kingdoms			Buffer Overflow
CLASP			Buffer overflow
OWASP Top Ten 2004	A1	CWE More Specific	Unvalidated Input
OWASP Top Ten 2004	A5	CWE More Specific	Buffer Overflows
CERT C Secure Coding	STR31-C	Exact	Guarantee that storage for strings has sufficient space for character data and the null terminator
WASC	7		Buffer Overflow
Software Fault Patterns	SFP8		Faulty Buffer Access
OMG ASCSM	ASCSM-CWE-120
OMG ASCRM	ASCRM-CWE-120

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-10	Buffer Overflow via Environment Variables
CAPEC-100	Overflow Buffers
CAPEC-14	Client-side Injection-induced Buffer Overflow
CAPEC-24	Filter Failure through Buffer Overflow
CAPEC-42	MIME Conversion
CAPEC-44	Overflow Binary Resource File
CAPEC-45	Buffer Overflow via Symbolic Links
CAPEC-46	Overflow Variables and Tags
CAPEC-47	Buffer Overflow via Parameter Expansion
CAPEC-67	String Format Overflow in syslog()
CAPEC-8	Buffer Overflow in an API Call
CAPEC-9	Buffer Overflow in Local Command-Line Utilities
CAPEC-92	Forced Integer Overflow

References

[REF-7]	Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44]	Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-56]	Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. (URL validated: 2023-04-07)
[REF-57]	Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/devel/safestr/work/safestr-1.0.3/doc/safestr.html>. (URL validated: 2023-04-07)
[REF-58]	Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. (URL validated: 2023-04-07)
[REF-59]	Arjan van de Ven. "Limiting buffer overflows with ExecShield". <https://archive.is/saAFo>. (URL validated: 2023-04-07)
[REF-60]	"PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. (URL validated: 2023-04-07)
[REF-74]	Jason Lam. "Top 25 Series - Rank 3 - Classic Buffer Overflow". SANS Software Security Institute. 2010-03-02. <http://software-security.sans.org/blog/2010/03/02/top-25-series-rank-3-classic-buffer-overflow/>.
[REF-61]	Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. (URL validated: 2023-04-07)
[REF-76]	Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. (URL validated: 2023-04-07)
[REF-62]	Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.
[REF-62]	Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.
[REF-62]	Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C String Handling", Page 388. 1st Edition. Addison Wesley. 2006.
[REF-64]	Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. (URL validated: 2023-04-07)
[REF-961]	Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962]	Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-1332]	John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. (URL validated: 2023-04-26)
[REF-1333]	Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. (URL validated: 2023-04-26)
[REF-1334]	D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. (URL validated: 2023-04-26)
[REF-1335]	D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. (URL validated: 2023-04-26)
[REF-1336]	D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. (URL validated: 2023-04-26)
[REF-1337]	Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. (URL validated: 2023-04-26)

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2025-04-03 (CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
2025-04-03 (CWE 4.17, 2025-04-03)	updated Applicable_Platforms, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Potential_Mitigations, References, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Common_Consequences, Description
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Potential_Mitigations
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Demonstrative_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Alternate_Terms, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Common_Consequences, Potential_Mitigations
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated References, Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Potential_Mitigations, References
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples, Description
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Potential_Mitigations
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Demonstrative_Examples, Related_Attack_Patterns
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Other_Notes, Potential_Mitigations, Relationships
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Other_Notes, Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-10-10	CWE Content Team	MITRE
2008-10-10	Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2008-10-14	Unbounded Transfer ('Classic Buffer Overflow')

Weakness ID: 362

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:

Description

Extended Description

A race condition occurs within concurrent environments, and it is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc.

A race condition violates these properties, which are closely related:

Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.
Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity.

The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

Alternate Terms

Race Condition

Common Consequences

Impact	Details
DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)	Scope: Availability When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion.
DoS: Crash, Exit, or Restart; DoS: Instability	Scope: Availability When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
Read Files or Directories; Read Application Data	Scope: Confidentiality, Integrity When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).
Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism	Scope: Access Control This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Architecture and Design	Use thread-safe capabilities such as the data access abstraction in Spring.
Architecture and Design	Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Implementation	When using multithreading and operating on shared variables, only use thread-safe functions.
Implementation	Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Implementation	Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Implementation	Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Implementation	Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Implementation	Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Architecture and Design; Operation	Strategy: Environment Hardening Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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 - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	364	Signal Handler Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	366	Race Condition within a Thread
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	367	Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	368	Context Switching Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	421	Race Condition During Access to Alternate Channel
ParentOf	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.	689	Permission Race Condition During Resource Copy
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1223	Race Condition for Write-Once Attributes
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1298	Hardware Logic Contains Race Conditions
CanFollow	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.	662	Improper Synchronization
CanPrecede	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
MemberOf	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 - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	367	Time-of-check Time-of-use (TOCTOU) Race Condition

Modes Of Introduction

Phase

Note

Architecture and Design

Implementation

Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x).

Applicable Platforms

Languages	C (Sometimes Prevalent) C++ (Sometimes Prevalent) Java (Sometimes Prevalent)
Technologies	Class: Mobile (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account.

(bad code)

Example Language: Perl

$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {

FatalError("Bad Transfer Amount");

}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {

FatalError("Insufficient Funds");

}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Suppose the balance is initially 100.00. An attack could be constructed as follows:

(attack code)

Example Language: Other

In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2.
CALLER-1 makes a transfer request of 80.00.
PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00
PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase().
Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay.
CALLER-2 makes a transfer request of 1.00.
PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet.
PROGRAM-2 determines the new balance as 99.00.
After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00.
PROGRAM-2 sends a request to update the database, setting the balance to 99.00

At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database.

To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Example 2

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)

Example Language: C

void f(pthread_mutex_t *mutex) {

pthread_mutex_lock(mutex);

/* access shared resource */

pthread_mutex_unlock(mutex);

}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)

Example Language: C

int f(pthread_mutex_t *mutex) {

int result;

result = pthread_mutex_lock(mutex);
if (0 != result)

return result;

/* access shared resource */

return pthread_mutex_unlock(mutex);

}

Example 3

Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.

Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.

Selected Observed Examples

Reference	Description
CVE-2022-29527	Go application for cloud management creates a world-writable sudoers file that allows local attackers to inject sudo rules and escalate privileges to root by winning a race condition.
CVE-2021-1782	Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
CVE-2021-0920	Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
CVE-2020-6819	Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
CVE-2019-18827	chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
CVE-2019-1161	Chain: race condition (CWE-362) in anti-malware product allows deletion of files by creating a junction (CWE-1386) and using hard links during the time window in which a temporary file is created and deleted.
CVE-2015-1743	TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
CVE-2014-8273	Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].
CVE-2008-5044	Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
CVE-2008-2958	chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-1570	chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-0058	Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
CVE-2008-0379	Race condition during initialization triggers a buffer overflow.
CVE-2007-6599	Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
CVE-2007-6180	chain: race condition triggers NULL pointer dereference
CVE-2007-5794	Race condition in library function could cause data to be sent to the wrong process.
CVE-2007-3970	Race condition in file parser leads to heap corruption.
CVE-2008-5021	chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
CVE-2009-4895	chain: race condition for an argument value, possibly resulting in NULL dereference
CVE-2009-3547	chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
CVE-2006-5051	Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).

Detection Methods

Method	Details
Black Box	Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.
White Box	Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).
Automated Dynamic Analysis	This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Race conditions may be detected with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior. Insert breakpoints or delays in between relevant code statements to artificially expand the race window so that it will be easier to detect. Effectiveness: Moderate
Automated Static Analysis - Binary or Bytecode	According to SOAR, the following detection techniques may be useful: Highly cost effective: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Cost effective for partial coverage: Binary Weakness Analysis - including disassembler + source code weakness analysis Effectiveness: High
Dynamic Analysis with Automated Results Interpretation	According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation	According to SOAR, the following detection techniques may be useful: Highly cost effective: Framework-based Fuzzer Cost effective for partial coverage: Fuzz Tester Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious Effectiveness: High
Manual Static Analysis - Source Code	According to SOAR, the following detection techniques may be useful: Highly cost effective: Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source Effectiveness: High
Automated Static Analysis - Source Code	According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer Effectiveness: High
Architecture or Design Review	According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Effectiveness: High

Affected Resources

File or Directory

Memberships

Nature	Type	ID	Name
MemberOf	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).	635	Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	743	CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	801	2010 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	852	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	882	CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	988	SFP Secondary Cluster: Race Condition Window
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1142	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1365	ICS Communications: Unreliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1376	ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOf	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).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1401	Comprehensive Categorization: Concurrency
MemberOf	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).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses

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

Research Gap

Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area.

Research Gap

Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check.

Research Gap

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Race Conditions
The CERT Oracle Secure Coding Standard for Java (2011)	VNA03-J		Do not assume that a group of calls to independently atomic methods is atomic

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-26	Leveraging Race Conditions
CAPEC-29	Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

References

[REF-44]	Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-349]	Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <https://drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766>. (URL validated: 2023-04-07)
[REF-350]	Steven Devijver. "Thread-safe webapps using Spring". <https://web.archive.org/web/20170609174845/http://www.javalobby.org/articles/thread-safe/index.jsp>. (URL validated: 2023-04-07)
[REF-351]	David Wheeler. "Prevent race conditions". 2007-10-04. <https://www.ida.liu.se/~TDDC90/literature/papers/SP-race-conditions.pdf>. (URL validated: 2023-04-07)
[REF-352]	Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <https://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/ucd-ecs-95-08.pdf>. (URL validated: 2023-04-07)
[REF-353]	David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>. (URL validated: 2023-04-07)
[REF-354]	Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <https://www.blakewatts.com/blog/discovering-and-exploiting-named-pipe-security-flaws-for-fun-and-profit>. (URL validated: 2023-04-07)
[REF-355]	Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
[REF-356]	"Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <https://web.archive.org/web/20081010155022/http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>. (URL validated: 2023-04-07)
[REF-357]	Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <https://web.archive.org/web/20100530231203/http://blogs.sans.org:80/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>. (URL validated: 2023-04-07)
[REF-76]	Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. (URL validated: 2023-04-07)
[REF-1237]	CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2010-04-30	Martin Sebor	Cisco Systems, Inc.
2010-04-30	Provided Demonstrative Example
2024-02-29 (CWE 4.16, 2024-11-19)	Abhi Balakrishnan
2024-02-29 (CWE 4.16, 2024-11-19)	Provided diagram to improve CWE usability
Modifications
Modification Date	Modifier	Organization
2025-04-03 (CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
2025-04-03 (CWE 4.17, 2025-04-03)	updated Affected_Resources
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Alternate_Terms, Common_Consequences, Description, Diagram, Modes_of_Introduction
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Common_Consequences, Description
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples, References
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Observed_Examples, Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Observed_Examples, References
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Potential_Mitigations, References, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Observed_Examples, Potential_Mitigations, Relationships
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, References, Relationships
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Relationships
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Demonstrative_Examples, Potential_Mitigations
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Relationships
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Race Conditions
2010-12-13	Race Condition

Weakness ID: 390

View customized information:

Description

The product detects a specific error, but takes no actions to handle the error.

Common Consequences

Impact	Details
Varies by Context; Unexpected State; Alter Execution Logic	Scope: Integrity, Other An attacker could utilize an ignored error condition to place the system in an unexpected state that could lead to the execution of unintended logic and could cause other unintended behavior.

Potential Mitigations

Phase(s)	Mitigation
Implementation	Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.
Implementation	If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.
Testing	Subject the product to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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.	755	Improper Handling of Exceptional Conditions
PeerOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	600	Uncaught Exception in Servlet
CanPrecede	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	401	Missing Release of Memory after Effective Lifetime

Relevant to the view "Software Development" (View-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	389	Error Conditions, Return Values, Status Codes

Relevant to the view "Architectural Concepts" (View-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1020	Verify Message Integrity

Modes Of Introduction

Phase	Note
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

The following example attempts to allocate memory for a character. After the call to malloc, an if statement is used to check whether the malloc function failed.

(bad code)

Example Language: C

foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {

//We do nothing so we just ignore the error.

}

The conditional successfully detects a NULL return value from malloc indicating a failure, however it does not do anything to handle the problem. Unhandled errors may have unexpected results and may cause the program to crash or terminate.

Instead, the if block should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following example notifies the user that the malloc function did not allocate the required memory resources and returns an error code.

(good code)

Example Language: C

foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {

printf("Malloc failed to allocate memory resources");
return -1;

}

Example 2

In the following C++ example the method readFile() will read the file whose name is provided in the input parameter and will return the contents of the file in char string. The method calls open() and read() may result in errors if the file does not exist or does not contain any data to read. These errors will be thrown when the is_open() method and good() method indicate errors opening or reading the file. However, these errors are not handled within the catch statement. Catch statements that do not perform any processing will have unexpected results. In this case an empty char string will be returned, and the file will not be properly closed.

(bad code)

Example Language: C++

char* readfile (char *filename) {

try {

// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {

throw "Unable to open file " + filename;

}

// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);

// allocate memory
char *buffer = new char [length];

// read data from file
infile.read (buffer,length);

if (!infile.good()) {

throw "Unable to read from file " + filename;

}

infile.close();

return buffer;

}
catch (...) {

/* bug: insert code to handle this later */

}

The catch statement should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following C++ example contains two catch statements. The first of these will catch a specific error thrown within the try block, and the second catch statement will catch all other errors from within the catch block. Both catch statements will notify the user that an error has occurred, close the file, and rethrow to the block that called the readFile() method for further handling or possible termination of the program.

(good code)

Example Language: C++

char* readFile (char *filename) {

try {

// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {

throw "Unable to open file " + filename;

throw "Unable to read from file " + filename;

}
infile.close();

return buffer;

}
catch (char *str) {

printf("Error: %s \n", str);
infile.close();
throw str;

}
catch (...) {

printf("Error occurred trying to read from file \n");
infile.close();
throw;

}

Example 3

In the following Java example the method readFile will read the file whose name is provided in the input parameter and will return the contents of the file in a String object. The constructor of the FileReader object and the read method call may throw exceptions and therefore must be within a try/catch block. While the catch statement in this example will catch thrown exceptions in order for the method to compile, no processing is performed to handle the thrown exceptions. Catch statements that do not perform any processing will have unexpected results. In this case, this will result in the return of a null String.

(bad code)

Example Language: Java

public String readFile(String filename) {

String retString = null;
try {

// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char[] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);

} catch (Exception ex) {

/* do nothing, but catch so it'll compile... */

}
return retString;

}

The catch statement should contain statements that either attempt to fix the problem, notify the user that an exception has been raised and continue processing, or perform some cleanup and gracefully terminate the program. The following Java example contains three catch statements. The first of these will catch the FileNotFoundException that may be thrown by the FileReader constructor called within the try/catch block. The second catch statement will catch the IOException that may be thrown by the read method called within the try/catch block. The third catch statement will catch all other exceptions thrown within the try block. For all catch statements the user is notified that the exception has been thrown and the exception is rethrown to the block that called the readFile() method for further processing or possible termination of the program. Note that with Java it is usually good practice to use the getMessage() method of the exception class to provide more information to the user about the exception raised.

(good code)

Example Language: Java

public String readFile(String filename) throws FileNotFoundException, IOException, Exception {

String retString = null;
try {

// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char [] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);

} catch (FileNotFoundException ex) {

System.err.println ("Error: FileNotFoundException opening the input file: " + filename );
System.err.println ("" + ex.getMessage() );
throw new FileNotFoundException(ex.getMessage());

} catch (IOException ex) {

System.err.println("Error: IOException reading the input file.\n" + ex.getMessage() );
throw new IOException(ex);

} catch (Exception ex) {

System.err.println("Error: Exception reading the input file.\n" + ex.getMessage() );
throw new Exception(ex);

}
return retString;

}

Selected Observed Examples

Reference	Description
CVE-2022-21820	A GPU data center manager detects an error due to a malformed request but does not act on it, leading to memory corruption.

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	728	OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	851	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	880	CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOf	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).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	962	SFP Secondary Cluster: Unchecked Status Condition
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1306	CISQ Quality Measures - Reliability
MemberOf	Category - 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 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	Mapped Node Name
CLASP		Improper error handling
The CERT Oracle Secure Coding Standard for Java (2011)	ERR00-J	Do not suppress or ignore checked exceptions
Software Fault Patterns	SFP4	Unchecked Status Condition

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-44]	Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	CLASP
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Demonstrative_Examples
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships, Time_of_Introduction
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Potential_Mitigations
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Type
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, References, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Relationships
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Improper Error Handling

Weakness ID: 73

View customized information:

Description

The product allows user input to control or influence paths or file names that are used in filesystem operations.

Extended Description

This could allow an attacker to access or modify system files or other files that are critical to the application.

Path manipulation errors occur when the following two conditions are met:

1. An attacker can specify a path used in an operation on the filesystem.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.

Common Consequences

Impact	Details
Read Files or Directories; Modify Files or Directories	Scope: Integrity, Confidentiality The application can operate on unexpected files. Confidentiality is violated when the targeted filename is not directly readable by the attacker.
Modify Files or Directories; Execute Unauthorized Code or Commands	Scope: Integrity, Confidentiality, Availability The application can operate on unexpected files. This may violate integrity if the filename is written to, or if the filename is for a program or other form of executable code.
DoS: Crash, Exit, or Restart; DoS: Resource Consumption (Other)	Scope: Availability The application can operate on unexpected files. Availability can be violated if the attacker specifies an unexpected file that the application modifies. Availability can also be affected if the attacker specifies a filename for a large file, or points to a special device or a file that does not have the format that the application expects.

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.
Architecture and Design; Operation	Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
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.
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. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string. Effectiveness: High
Implementation	Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59).
Installation; Operation	Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.
Operation; Implementation	If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
Testing	Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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.	610	Externally Controlled Reference to a Resource in Another Sphere
ChildOf	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.	642	External Control of Critical State Data
ParentOf	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.	114	Process Control
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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')
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	41	Improper Resolution of Path Equivalence
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	59	Improper Link Resolution Before File Access ('Link Following')
CanPrecede	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	98	Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	434	Unrestricted Upload of File with Dangerous Type

Relevant to the view "Software Development" (View-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	399	Resource Management Errors

Relevant to the view "Architectural Concepts" (View-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1015	Limit Access

Relevant to the view "Seven Pernicious Kingdoms" (View-700)

Nature	Type	ID	Name
ChildOf	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

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Unix (Often Prevalent) Class: Windows (Often Prevalent) Class: macOS (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22).

(bad code)

Example Language: Java

String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();

Example 2

The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt.

(bad code)

Example Language: Java

fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr);
out.println(arr);

Selected Observed Examples

Reference	Description
CVE-2022-45918	Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using "../" sequences (CWE-24)
CVE-2008-5748	Chain: external control of values for user's desired language and theme enables path traversal.
CVE-2008-5764	Chain: external control of user's target language enables remote file inclusion.

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Method	Details
Automated Static Analysis	The external control or influence of filenames can often be detected using automated static analysis that models data flow within the product. Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.

Memberships

Nature	Type	ID	Name
MemberOf	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	752	2009 Top 25 - Risky Resource Management
MemberOf	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	981	SFP Secondary Cluster: Path Traversal
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1348	OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf	Category - 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

Relationship

The external control of filenames can be the primary link in chains with other file-related weaknesses, as seen in the CanPrecede relationships. This is because software systems use files for many different purposes: to execute programs, load code libraries, to store application data, to store configuration settings, record temporary data, act as signals or semaphores to other processes, etc.

However, those weaknesses do not always require external control. For example, link-following weaknesses (CWE-59) often involve pathnames that are not controllable by the attacker at all.

The external control can be resultant from other issues. For example, in PHP applications, the register_globals setting can allow an attacker to modify variables that the programmer thought were immutable, enabling file inclusion (CWE-98) and path traversal (CWE-22). Operating with excessive privileges (CWE-250) might allow an attacker to specify an input filename that is not directly readable by the attacker, but is accessible to the privileged program. A buffer overflow (CWE-119) might give an attacker control over nearby memory locations that are related to pathnames, but were not directly modifiable by the attacker.

Maintenance

CWE-114 is a Class, but it is listed a child of CWE-73 in view 1000. This suggests some abstraction problems that should be resolved in future versions.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Path Manipulation
Software Fault Patterns	SFP16		Path Traversal

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-13	Subverting Environment Variable Values
CAPEC-267	Leverage Alternate Encoding
CAPEC-64	Using Slashes and URL Encoding Combined to Bypass Validation Logic
CAPEC-72	URL Encoding
CAPEC-76	Manipulating Web Input to File System Calls
CAPEC-78	Using Escaped Slashes in Alternate Encoding
CAPEC-79	Using Slashes in Alternate Encoding
CAPEC-80	Using UTF-8 Encoding to Bypass Validation Logic

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-45]	OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	7 Pernicious Kingdoms
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Potential_Mitigations, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Detection_Factors, Potential_Mitigations
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Maintenance_Notes, Potential_Mitigations
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Potential_Mitigations, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, References, Relationships, Time_of_Introduction, Type
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Likelihood_of_Exploit, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Potential_Mitigations
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Detection_Factors
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Description
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Potential_Mitigations, Relationships
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Applicable_Platforms, Causal_Nature, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships, Weakness_Ordinalities
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Path Manipulation

Weakness ID: 209

View customized information:

Description

The product generates an error message that includes sensitive information about its environment, users, or associated data.

Extended Description

The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more serious attacks. The error message may be created in different ways:

self-generated: the source code explicitly constructs the error message and delivers it
externally-generated: the external environment, such as a language interpreter, handles the error and constructs its own message, whose contents are not under direct control by the programmer

An attacker may use the contents of error messages to help launch another, more focused attack. For example, an attempt to exploit a path traversal weakness (CWE-22) might yield the full pathname of the installed application. In turn, this could be used to select the proper number of ".." sequences to navigate to the targeted file. An attack using SQL injection (CWE-89) might not initially succeed, but an error message could reveal the malformed query, which would expose query logic and possibly even passwords or other sensitive information used within the query.

Common Consequences

Impact	Details
Read Application Data	Scope: Confidentiality Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server.

Potential Mitigations

Phase(s)	Mitigation
Implementation	Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
Implementation	Handle exceptions internally and do not display errors containing potentially sensitive information to a user.
Implementation	Strategy: Attack Surface Reduction Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible. Effectiveness: Defense in Depth Note: This makes it easier to spot places in the code where data is being used that is unencrypted.
Implementation; Build and Compilation	Strategy: Compilation or Build Hardening Debugging information should not make its way into a production release.
Implementation; Build and Compilation	Strategy: Environment Hardening Debugging information should not make its way into a production release.
System Configuration	Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.
System Configuration	Create default error pages or messages that do not leak any information.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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.	200	Exposure of Sensitive Information to an Unauthorized Actor
ChildOf	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.	755	Improper Handling of Exceptional Conditions
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	210	Self-generated Error Message Containing Sensitive Information
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	211	Externally-Generated Error Message Containing Sensitive Information
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	550	Server-generated Error Message Containing Sensitive Information
PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1295	Debug Messages Revealing Unnecessary Information
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	600	Uncaught Exception in Servlet
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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

Relevant to the view "Software Development" (View-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	199	Information Management Errors
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	389	Error Conditions, Return Values, Status Codes

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
ChildOf	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.	200	Exposure of Sensitive Information to an Unauthorized Actor

Relevant to the view "Architectural Concepts" (View-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1015	Limit Access

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.
System Configuration
Operation

Applicable Platforms

Languages

PHP (Often Prevalent)

Java (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

In the following example, sensitive information might be printed depending on the exception that occurs.

(bad code)

Example Language: Java

try {

/.../

}
catch (Exception e) {

System.out.println(e);

}

If an exception related to SQL is handled by the catch, then the output might contain sensitive information such as SQL query structure or private information. If this output is redirected to a web user, this may represent a security problem.

Example 2

This code tries to open a database connection, and prints any exceptions that occur.

(bad code)

Example Language: PHP

try {

openDbConnection();

}
//print exception message that includes exception message and configuration file location
catch (Exception $e) {

echo 'Caught exception: ', $e->getMessage(), '\n';
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';

}

If an exception occurs, the printed message exposes the location of the configuration file the script is using. An attacker can use this information to target the configuration file (perhaps exploiting a Path Traversal weakness). If the file can be read, the attacker could gain credentials for accessing the database. The attacker may also be able to replace the file with a malicious one, causing the application to use an arbitrary database.

Example 3

The following code generates an error message that leaks the full pathname of the configuration file.

(bad code)

Example Language: Perl

$ConfigDir = "/home/myprog/config";
$uname = GetUserInput("username");

# avoid CWE-22, CWE-78, others.
ExitError("Bad hacker!") if ($uname !~ /^\w+$/);
$file = "$ConfigDir/$uname.txt";
if (! (-e $file)) {

ExitError("Error: $file does not exist");

}
...

If this code is running on a server, such as a web application, then the person making the request should not know what the full pathname of the configuration directory is. By submitting a username that does not produce a $file that exists, an attacker could get this pathname. It could then be used to exploit path traversal or symbolic link following problems that may exist elsewhere in the application.

Example 4

In the example below, the method getUserBankAccount retrieves a bank account object from a database using the supplied username and account number to query the database. If an SQLException is raised when querying the database, an error message is created and output to a log file.

(bad code)

Example Language: Java

public BankAccount getUserBankAccount(String username, String accountNumber) {

BankAccount userAccount = null;
String query = null;
try {

if (isAuthorizedUser(username)) {

query = "SELECT * FROM accounts WHERE owner = "
+ username + " AND accountID = " + accountNumber;
DatabaseManager dbManager = new DatabaseManager();
Connection conn = dbManager.getConnection();
Statement stmt = conn.createStatement();
ResultSet queryResult = stmt.executeQuery(query);
userAccount = (BankAccount)queryResult.getObject(accountNumber);

}

} catch (SQLException ex) {

String logMessage = "Unable to retrieve account information from database,\nquery: " + query;
Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex);

}
return userAccount;

}

The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database.

Selected Observed Examples

Reference	Description
CVE-2008-2049	POP3 server reveals a password in an error message after multiple APOP commands are sent. Might be resultant from another weakness.
CVE-2007-5172	Program reveals password in error message if attacker can trigger certain database errors.
CVE-2008-4638	Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
CVE-2008-1579	Existence of user names can be determined by requesting a nonexistent blog and reading the error message.
CVE-2007-1409	Direct request to library file in web application triggers pathname leak in error message.
CVE-2008-3060	Malformed input to login page causes leak of full path when IMAP call fails.
CVE-2005-0603	Malformed regexp syntax leads to information exposure in error message.
CVE-2017-9615	verbose logging stores admin credentials in a world-readablelog file
CVE-2018-1999036	SSH password for private key stored in build log

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)
Resultant	(where the weakness is typically related to the presence of some other weaknesses)

Detection Methods

Method	Details
Manual Analysis	This weakness generally requires domain-specific interpretation using manual analysis. However, the number of potential error conditions may be too large to cover completely within limited time constraints. Effectiveness: High
Automated Analysis	Automated methods may be able to detect certain idioms automatically, such as exposed stack traces or pathnames, but violation of business rules or privacy requirements is not typically feasible. Effectiveness: Moderate
Automated Dynamic Analysis	This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Error conditions may be triggered with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior. Effectiveness: Moderate
Manual Dynamic Analysis	Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.
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.)

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	717	OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	728	OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOf	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	801	2010 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	815	OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	851	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	880	CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOf	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).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	933	OWASP Top Ten 2013 Category A5 - Security Misconfiguration
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	963	SFP Secondary Cluster: Exposed Data
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1032	OWASP Top Ten 2017 Category A6 - Security Misconfiguration
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1348	OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1417	Comprehensive Categorization: Sensitive Information Exposure

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			Accidental leaking of sensitive information through error messages
OWASP Top Ten 2007	A6	CWE More Specific	Information Leakage and Improper Error Handling
OWASP Top Ten 2004	A7	CWE More Specific	Improper Error Handling
OWASP Top Ten 2004	A10	CWE More Specific	Insecure Configuration Management
The CERT Oracle Secure Coding Standard for Java (2011)	ERR01-J		Do not allow exceptions to expose sensitive information
Software Fault Patterns	SFP23		Exposed Data

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-215	Fuzzing for application mapping
CAPEC-463	Padding Oracle Crypto Attack
CAPEC-54	Query System for Information
CAPEC-7	Blind SQL Injection

References

[REF-174]	Web Application Security Consortium. "Information Leakage". <http://projects.webappsec.org/w/page/13246936/Information%20Leakage>. (URL validated: 2023-04-07)
[REF-175]	Brian Chess and Jacob West. "Secure Programming with Static Analysis". Section 9.2, Page 326. Addison-Wesley. 2007.
[REF-176]	Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 16, "General Good Practices." Page 415. 1st Edition. Microsoft Press. 2001-11-13.
[REF-44]	Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
[REF-44]	Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 12: Information Leakage." Page 191. McGraw-Hill. 2010.
[REF-179]	Johannes Ullrich. "Top 25 Series - Rank 16 - Information Exposure Through an Error Message". SANS Software Security Institute. 2010-03-17. <http://software-security.sans.org/blog/2010/03/17/top-25-series-rank-16-information-exposure-through-an-error-message>.
[REF-62]	Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Overly Verbose Error Messages", Page 75. 1st Edition. Addison Wesley. 2006.
[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
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2022-07-11	Nick Johnston
2022-07-11	Identified incorrect language tag in demonstrative example.
Modifications
Modification Date	Modifier	Organization
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Demonstrative_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Potential_Mitigations, Related_Attack_Patterns
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Description, Name, Observed_Examples, References, Relationships, Weakness_Ordinalities
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Demonstrative_Examples, Observed_Examples
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References, Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Relationships
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated References
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Related_Attack_Patterns, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Relationships, Taxonomy_Mappings
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples, Observed_Examples, Relationships
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations, Relationships
2010-09-09		Veracode
2010-09-09	Suggested OWASP Top Ten mapping
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Related_Attack_Patterns
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, References, Relationships
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Demonstrative_Examples, Name, Potential_Mitigations, References, Time_of_Introduction
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Demonstrative_Examples, Potential_Mitigations, Relationships
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Demonstrative_Examples, Description, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Relationships
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Error Message Information Leaks
2009-12-28	Error Message Information Leak
2020-02-24	Information Exposure Through an Error Message

Weakness ID: 754

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:

Description

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.

Extended Description

The programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability.

Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions.

Common Consequences

Impact	Details
DoS: Crash, Exit, or Restart; Unexpected State	Scope: Integrity, Availability The data which were produced as a result of a function call could be in a bad state upon return. If the return value is not checked, then this bad data may be used in operations, possibly leading to a crash or other unintended behaviors.

Potential Mitigations

Phase(s)	Mitigation
Requirements	Strategy: Language Selection Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Implementation	Check the results of all functions that return a value and verify that the value is expected. Effectiveness: High Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.
Implementation	If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248). Effectiveness: High Note: Using specific exceptions, and ensuring that exceptions are checked, helps programmers to anticipate and appropriately handle many unusual events that could occur.
Implementation	Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
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: Performing extensive input validation does not help with handling unusual conditions, but it will minimize their occurrences and will make it more difficult for attackers to trigger 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.
Architecture and Design	Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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.	703	Improper Check or Handling of Exceptional Conditions
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	252	Unchecked Return Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	253	Incorrect Check of Function Return Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	273	Improper Check for Dropped Privileges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	354	Improper Validation of Integrity Check Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	391	Unchecked Error Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	394	Unexpected Status Code or Return Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference
CanPrecede	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
MemberOf	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 - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	252	Unchecked Return Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	273	Improper Check for Dropped Privileges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference

Relevant to the view "Architectural Concepts" (View-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1012	Cross Cutting

Background Details

Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.

Modes Of Introduction

Phase	Note
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

Consider the following code segment:

(bad code)

Example Language: C

char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

Example 2

The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

(bad code)

Example Language: C

buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);

The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:

Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.
It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state.
The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

Example 3

The following examples read a file into a byte array.

(bad code)

Example Language: C#

char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {

String userName = (String) i.Current();
String pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);

}

(bad code)

Example Language: Java

FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {

String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);

The code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker.

Example 4

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference.

(bad code)

Example Language: Java

String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) {

...

}
...

The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference.

(bad code)

Example Language: Java

String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {

...

}
...

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 5

The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.

(bad code)

Example Language: Java

System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

Example 6

The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value.

(bad code)

Example Language: C#

Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte
MyFile.Read(MyArray, 0, 50)
DoDangerousOperation(MyArray(20))

In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.

Example 7

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: C

void host_lookup(char *user_supplied_addr){

}

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy().

Note that this code is also vulnerable to a buffer overflow (CWE-119).

Example 8

In the following C/C++ example the method outputStringToFile opens a file in the local filesystem and outputs a string to the file. The input parameters output and filename contain the string to output to the file and the name of the file respectively.

(bad code)

Example Language: C++

int outputStringToFile(char *output, char *filename) {

openFileToWrite(filename);
writeToFile(output);
closeFile(filename);

}

However, this code does not check the return values of the methods openFileToWrite, writeToFile, closeFile to verify that the file was properly opened and closed and that the string was successfully written to the file. The return values for these methods should be checked to determine if the method was successful and allow for detection of errors or unexpected conditions as in the following example.

(good code)

Example Language: C++

int outputStringToFile(char *output, char *filename) {

int isOutput = SUCCESS;

int isOpen = openFileToWrite(filename);
if (isOpen == FAIL) {

printf("Unable to open file %s", filename);
isOutput = FAIL;

}
else {

int isWrite = writeToFile(output);
if (isWrite == FAIL) {

printf("Unable to write to file %s", filename);
isOutput = FAIL;

}

int isClose = closeFile(filename);
if (isClose == FAIL)

isOutput = FAIL;

}
return isOutput;

}

Example 9

In the following Java example the method readFromFile uses a FileReader object to read the contents of a file. The FileReader object is created using the File object readFile, the readFile object is initialized using the setInputFile method. The setInputFile method should be called before calling the readFromFile method.

(bad code)

Example Language: Java

private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file

}

public void readFromFile() {

try {

reader = new FileReader(readFile);

// read input file

} catch (FileNotFoundException ex) {...}

}

However, the readFromFile method does not check to see if the readFile object is null, i.e. has not been initialized, before creating the FileReader object and reading from the input file. The readFromFile method should verify whether the readFile object is null and output an error message and raise an exception if the readFile object is null, as in the following code.

(good code)

Example Language: Java

private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file

}

public void readFromFile() {

try {

if (readFile == null) {

System.err.println("Input file has not been set, call setInputFile method before calling openInputFile");
throw NullPointerException;

}

reader = new FileReader(readFile);

// read input file

} catch (FileNotFoundException ex) {...}
catch (NullPointerException ex) {...}

}

Selected Observed Examples

Reference	Description
CVE-2023-49286	Chain: function in web caching proxy does not correctly check a return value (CWE-253) leading to a reachable assertion (CWE-617)
CVE-2007-3798	Unchecked return value leads to resultant integer overflow and code execution.
CVE-2006-4447	Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
CVE-2006-2916	Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.

Detection Methods

Method

Details

Automated Static Analysis

Automated static analysis may be useful for detecting unusual conditions involving system resources or common programming idioms, but not for violations of business rules.

Effectiveness: Moderate

Manual Dynamic Analysis

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	880	CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	962	SFP Secondary Cluster: Unchecked Status Condition
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1141	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1181	SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - 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-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

Relationship

Sometimes, when a return value can be used to indicate an error, an unchecked return value is a code-layer instance of a missing application-layer check for exceptional conditions. However, return values are not always needed to communicate exceptional conditions. For example, expiration of resources, values passed by reference, asynchronously modified data, sockets, etc. may indicate exceptional conditions without the use of a return value.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
SEI CERT Perl Coding Standard	EXP31-PL	CWE More Abstract	Do not suppress or ignore exceptions
ISA/IEC 62443	Part 4-2		Req CR 3.5
ISA/IEC 62443	Part 4-2		Req CR 3.7

References

[REF-62]	Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Program Building Blocks" Page 341. 1st Edition. Addison Wesley. 2006.
[REF-62]	Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 1, "Exceptional Conditions," Page 22. 1st Edition. Addison Wesley. 2006.
[REF-44]	Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
[REF-622]	Frank Kim. "Top 25 Series - Rank 15 - Improper Check for Unusual or Exceptional Conditions". SANS Software Security Institute. 2010-03-15. <https://www.sans.org/blog/top-25-series-rank-15-improper-check-for-unusual-or-exceptional-conditions/>. (URL validated: 2023-04-07)

Content History

Submissions
Submission Date	Submitter	Organization
2009-03-03 (CWE 1.3, 2009-03-10)	CWE Content Team	MITRE
2009-03-03 (CWE 1.3, 2009-03-10)	New entry for reorganization of CWE-703.
Contributions
Contribution Date	Contributor	Organization
2023-04-25	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023-04-25	Suggested mappings to ISA/IEC 62443.
Modifications
Modification Date	Modifier	Organization
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Relationships
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Observed_Examples
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships, Taxonomy_Mappings
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Potential_Mitigations
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Potential_Mitigations
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Potential_Mitigations
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Description, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Demonstrative_Examples, Relationships
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences, Related_Attack_Patterns, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Description, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Relationship_Notes
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Demonstrative_Examples, Related_Attack_Patterns
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Likelihood_of_Exploit, Time_of_Introduction
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Relationships
Previous Entry Names
Change Date	Previous Entry Name
2010-02-16	Improper Check for Exceptional Conditions

Weakness ID: 116

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:

Description

Extended Description

Improper encoding or escaping can allow attackers to change the commands that are sent to another component, inserting malicious commands instead.

Most products follow a certain protocol that uses structured messages for communication between components, such as queries or commands. These structured messages can contain raw data interspersed with metadata or control information. For example, "GET /index.html HTTP/1.1" is a structured message containing a command ("GET") with a single argument ("/index.html") and metadata about which protocol version is being used ("HTTP/1.1").

If an application uses attacker-supplied inputs to construct a structured message without properly encoding or escaping, then the attacker could insert special characters that will cause the data to be interpreted as control information or metadata. Consequently, the component that receives the output will perform the wrong operations, or otherwise interpret the data incorrectly.

Alternate Terms

Output Sanitization
Output Validation
Output Encoding

Common Consequences

Impact	Details
Modify Application Data	Scope: Integrity The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.
Execute Unauthorized Code or Commands	Scope: Integrity, Confidentiality, Availability, Access Control The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.
Bypass Protection Mechanism	Scope: Confidentiality The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	Strategy: Libraries or Frameworks Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error. Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.
Architecture and Design	Strategy: Parameterization If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.
Architecture and Design; Implementation	Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
Architecture and Design	In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input.
Architecture and Design	Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20).
Requirements	Fully specify which encodings are required by components that will be communicating with each other.
Implementation	When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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.	707	Improper Neutralization
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	117	Improper Output Neutralization for Logs
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	644	Improper Neutralization of HTTP Headers for Scripting Syntax
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	838	Inappropriate Encoding for Output Context
CanPrecede	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.	74	Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
MemberOf	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 - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	838	Inappropriate Encoding for Output Context

Modes Of Introduction

Phase	Note
Implementation
Operation

Applicable Platforms

Languages	Class: Not Language-Specific (Often Prevalent)
Technologies	AI/ML (Undetermined Prevalence) Database Server (Often Prevalent) Web Server (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This code displays an email address that was submitted as part of a form.

(bad code)

Example Language: JSP

<% String email = request.getParameter("email"); %>
...
Email Address: <%= email %>

The value read from the form parameter is reflected back to the client browser without having been encoded prior to output, allowing various XSS attacks (CWE-79).

Example 2

Consider a chat application in which a front-end web application communicates with a back-end server. The back-end is legacy code that does not perform authentication or authorization, so the front-end must implement it. The chat protocol supports two commands, SAY and BAN, although only administrators can use the BAN command. Each argument must be separated by a single space. The raw inputs are URL-encoded. The messaging protocol allows multiple commands to be specified on the same line if they are separated by a "|" character.

First let's look at the back end command processor code

(bad code)

Example Language: Perl

$inputString = readLineFromFileHandle($serverFH);

# generate an array of strings separated by the "|" character.
@commands = split(/\|/, $inputString);

foreach $cmd (@commands) {

# separate the operator from its arguments based on a single whitespace
($operator, $args) = split(/ /, $cmd, 2);

$args = UrlDecode($args);
if ($operator eq "BAN") {

ExecuteBan($args);

}
elsif ($operator eq "SAY") {

ExecuteSay($args);

}

The front end web application receives a command, encodes it for sending to the server, performs the authorization check, and sends the command to the server.

(bad code)

Example Language: Perl

$inputString = GetUntrustedArgument("command");
($cmd, $argstr) = split(/\s+/, $inputString, 2);

# removes extra whitespace and also changes CRLF's to spaces
$argstr =~ s/\s+/ /gs;

$argstr = UrlEncode($argstr);
if (($cmd eq "BAN") && (! IsAdministrator($username))) {

die "Error: you are not the admin.\n";

}

# communicate with file server using a file handle
$fh = GetServerFileHandle("myserver");

print $fh "$cmd $argstr\n";

It is clear that, while the protocol and back-end allow multiple commands to be sent in a single request, the front end only intends to send a single command. However, the UrlEncode function could leave the "|" character intact. If an attacker provides:

(attack code)

SAY hello world|BAN user12

then the front end will see this is a "SAY" command, and the $argstr will look like "hello world | BAN user12". Since the command is "SAY", the check for the "BAN" command will fail, and the front end will send the URL-encoded command to the back end:

(result)

SAY hello%20world|BAN%20user12

The back end, however, will treat these as two separate commands:

(result)

SAY hello world
BAN user12

Notice, however, that if the front end properly encodes the "|" with "%7C", then the back end will only process a single command.

Example 3

This example takes user input, passes it through an encoding scheme and then creates a directory specified by the user.

(bad code)

Example Language: Perl

sub GetUntrustedInput {

return($ARGV[0]);

}

sub encode {

my($str) = @_;
$str =~ s/\&/\&/gs;
$str =~ s/\"/\"/gs;
$str =~ s/\'/\'/gs;
$str =~ s/\</\</gs;
$str =~ s/\>/\>/gs;
return($str);

}

sub doit {

my $uname = encode(GetUntrustedInput("username"));
print "<b>Welcome, $uname!</b><p>\n";
system("cd /home/$uname; /bin/ls -l");

}

The programmer attempts to encode dangerous characters, however the denylist for encoding is incomplete (CWE-184) and an attacker can still pass a semicolon, resulting in a chain with command injection (CWE-77).

Additionally, the encoding routine is used inappropriately with command execution. An attacker doesn't even need to insert their own semicolon. The attacker can instead leverage the encoding routine to provide the semicolon to separate the commands. If an attacker supplies a string of the form:

(attack code)

' pwd

then the program will encode the apostrophe and insert the semicolon, which functions as a command separator when passed to the system function. This allows the attacker to complete the command injection.

Selected Observed Examples

Reference	Description
CVE-2021-41232	Chain: authentication routine in Go-based agile development product does not escape user name (CWE-116), allowing LDAP injection (CWE-90)
CVE-2008-4636	OS command injection in backup software using shell metacharacters in a filename; correct behavior would require that this filename could not be changed.
CVE-2008-0769	Web application does not set the charset when sending a page to a browser, allowing for XSS exploitation when a browser chooses an unexpected encoding.
CVE-2008-0005	Program does not set the charset when sending a page to a browser, allowing for XSS exploitation when a browser chooses an unexpected encoding.
CVE-2008-5573	SQL injection via password parameter; a strong password might contain "&"
CVE-2008-3773	Cross-site scripting in chat application via a message subject, which normally might contain "&" and other XSS-related characters.
CVE-2008-0757	Cross-site scripting in chat application via a message, which normally might be allowed to contain arbitrary content.

Detection Methods

Method	Details
Automated Static Analysis	This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Effectiveness: Moderate Note:This is not a perfect solution, since 100% accuracy and coverage are not feasible.
Automated Dynamic Analysis	This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - 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	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	992	SFP Secondary Cluster: Faulty Input Transformation
MemberOf	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1179	SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1347	OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf	Category - 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-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

Relationship

This weakness is primary to all weaknesses related to injection (CWE-74) since the inherent nature of injection involves the violation of structured messages.

Relationship

CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks.

However, input validation is not always sufficient, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a last name is inserted into a query. The name "O'Reilly" would likely pass the validation step since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise neutralized. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

Terminology

The usage of the "encoding" and "escaping" terms varies widely. For example, in some programming languages, the terms are used interchangeably, while other languages provide APIs that use both terms for different tasks. This overlapping usage extends to the Web, such as the "escape" JavaScript function whose purpose is stated to be encoding. The concepts of encoding and escaping predate the Web by decades. Given such a context, it is difficult for CWE to adopt a consistent vocabulary that will not be misinterpreted by some constituency.

Theoretical

This is a data/directive boundary error in which data boundaries are not sufficiently enforced before it is sent to a different control sphere.

Research Gap

While many published vulnerabilities are related to insufficient output encoding, there is such an emphasis on input validation as a protection mechanism that the underlying causes are rarely described. Within CVE, the focus is primarily on well-understood issues like cross-site scripting and SQL injection. It is likely that this weakness frequently occurs in custom protocols that support multiple encodings, which are not necessarily detectable with automated techniques.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
WASC	22		Improper Output Handling
The CERT Oracle Secure Coding Standard for Java (2011)	IDS00-J	Exact	Sanitize untrusted data passed across a trust boundary
The CERT Oracle Secure Coding Standard for Java (2011)	IDS05-J		Use a subset of ASCII for file and path names
SEI CERT Oracle Coding Standard for Java	IDS00-J	Imprecise	Prevent SQL injection
SEI CERT Perl Coding Standard	IDS33-PL	Exact	Sanitize untrusted data passed across a trust boundary

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-104	Cross Zone Scripting
CAPEC-73	User-Controlled Filename
CAPEC-81	Web Server Logs Tampering
CAPEC-85	AJAX Footprinting

References

[REF-45]	OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-46]	Joshbw. "Output Sanitization". 2008-09-18. <https://web.archive.org/web/20081208054333/http://analyticalengine.net/archives/58>. (URL validated: 2023-04-07)
[REF-47]	Niyaz PK. "Sanitizing user data: How and where to do it". 2008-09-11. <https://web.archive.org/web/20090105222005/http://www.diovo.com/2008/09/sanitizing-user-data-how-and-where-to-do-it/>. (URL validated: 2023-04-07)
[REF-48]	Jeremiah Grossman. "Input validation or output filtering, which is better?". 2007-01-30. <https://blog.jeremiahgrossman.com/2007/01/input-validation-or-output-filtering.html>. (URL validated: 2023-04-07)
[REF-49]	Jim Manico. "Input Validation - Not That Important". 2008-08-10. <https://manicode.blogspot.com/2008/08/input-validation-not-that-important.html>. (URL validated: 2023-04-07)
[REF-50]	Michael Eddington. "Preventing XSS with Correct Output Encoding". <http://phed.org/2008/05/19/preventing-xss-with-correct-output-encoding/>.
[REF-7]	Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 11, "Canonical Representation Issues" Page 363. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	CWE Community
2006-07-19 (CWE Draft 3, 2006-07-19)	Submitted by members of the CWE community to extend early CWE versions
Modifications
Modification Date	Modifier	Organization
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Applicable_Platforms
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships, Time_of_Introduction
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Relationships, Terminology_Notes
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Applicable_Platforms, Demonstrative_Examples, Potential_Mitigations
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Likelihood_of_Exploit, References, Taxonomy_Mappings
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Demonstrative_Examples, Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated References
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships, Taxonomy_Mappings
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Relationship_Notes, Relationships
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Potential_Mitigations
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Potential_Mitigations
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, Potential_Mitigations, References, Taxonomy_Mappings
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Demonstrative_Examples, Potential_Mitigations
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Related_Attack_Patterns
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Description, Potential_Mitigations
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships, Research_Gaps, Terminology_Notes, Theoretical_Notes
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Name, Relationships
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-07-01	Sean Eidemiller	Cigital
2008-07-01	added/updated demonstrative examples
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Output Validation
2008-09-09	Incorrect Output Sanitization
2009-01-12	Insufficient Output Sanitization

Weakness ID: 665

Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
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:

Description

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.

Extended Description

This can have security implications when the associated resource is expected to have certain properties or values, such as a variable that determines whether a user has been authenticated or not.

Common Consequences

Impact	Details
Read Memory; Read Application Data	Scope: Confidentiality When reusing a resource such as memory or a program variable, the original contents of that resource may not be cleared before it is sent to an untrusted party.
Bypass Protection Mechanism	Scope: Access Control If security-critical decisions rely on a variable having a "0" or equivalent value, and the programming language performs this initialization on behalf of the programmer, then a bypass of security may occur.
DoS: Crash, Exit, or Restart	Scope: Availability The uninitialized data may contain values that cause program flow to change in ways that the programmer did not intend. For example, if an uninitialized variable is used as an array index in C, then its previous contents may produce an index that is outside the range of the array, possibly causing a crash or an exit in other environments.

Potential Mitigations

Phase(s)	Mitigation
Requirements	Strategy: Language Selection Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, in Java, if the programmer does not explicitly initialize a variable, then the code could produce a compile-time error (if the variable is local) or automatically initialize the variable to the default value for the variable's type. In Perl, if explicit initialization is not performed, then a default value of undef is assigned, which is interpreted as 0, false, or an equivalent value depending on the context in which the variable is accessed.
Architecture and Design	Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.
Implementation	Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage.
Implementation	Pay close attention to complex conditionals that affect initialization, since some conditions might not perform the initialization.
Implementation	Avoid race conditions (CWE-362) during initialization routines.
Build and Compilation	Run or compile your product with settings that generate warnings about uninitialized variables or data.
Testing	Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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.	664	Improper Control of a Resource Through its Lifetime
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	455	Non-exit on Failed Initialization
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	908	Use of Uninitialized Resource
ParentOf	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.	909	Missing Initialization of Resource
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1279	Cryptographic Operations are run Before Supporting Units are Ready
ParentOf	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.	1419	Incorrect Initialization of Resource

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
MemberOf	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 - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	908	Use of Uninitialized Resource
ParentOf	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.	909	Missing Initialization of Resource
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1188	Initialization of a Resource with an Insecure Default

Relevant to the view "CISQ Quality Measures (2020)" (View-1305)

Nature	Type	ID	Name
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	456	Missing Initialization of a Variable
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	457	Use of Uninitialized Variable

Relevant to the view "CISQ Data Protection Measures" (View-1340)

Nature	Type	ID	Name
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	456	Missing Initialization of a Variable
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	457	Use of Uninitialized Variable

Modes Of Introduction

Phase	Note
Implementation	This weakness can occur in code paths that are not well-tested, such as rare error conditions. This is because the use of uninitialized data would be noticed as a bug during frequently-used functionality.
Operation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

Here, a boolean initiailized field is consulted to ensure that initialization tasks are only completed once. However, the field is mistakenly set to true during static initialization, so the initialization code is never reached.

(bad code)

Example Language: Java

private boolean initialized = true;
public void someMethod() {

if (!initialized) {

// perform initialization tasks
...

initialized = true;

}

Example 2

The following code intends to limit certain operations to the administrator only.

(bad code)

Example Language: Perl

$username = GetCurrentUser();
$state = GetStateData($username);
if (defined($state)) {

$uid = ExtractUserID($state);

}

# do stuff
if ($uid == 0) {

DoAdminThings();

}

If the application is unable to extract the state information - say, due to a database timeout - then the $uid variable will not be explicitly set by the programmer. This will cause $uid to be regarded as equivalent to "0" in the conditional, allowing the original user to perform administrator actions. Even if the attacker cannot directly influence the state data, unexpected errors could cause incorrect privileges to be assigned to a user just by accident.

Example 3

The following code intends to concatenate a string to a variable and print the string.

(bad code)

Example Language: C

char str[20];
strcat(str, "hello world");
printf("%s", str);

This might seem innocent enough, but str was not initialized, so it contains random memory. As a result, str[0] might not contain the null terminator, so the copy might start at an offset other than 0. The consequences can vary, depending on the underlying memory.

If a null terminator is found before str[8], then some bytes of random garbage will be printed before the "hello world" string. The memory might contain sensitive information from previous uses, such as a password (which might occur as a result of CWE-14 or CWE-244). In this example, it might not be a big deal, but consider what could happen if large amounts of memory are printed out before the null terminator is found.

If a null terminator isn't found before str[8], then a buffer overflow could occur, since strcat will first look for the null terminator, then copy 12 bytes starting with that location. Alternately, a buffer over-read might occur (CWE-126) if a null terminator isn't found before the end of the memory segment is reached, leading to a segmentation fault and crash.

Selected Observed Examples

Reference	Description
CVE-2001-1471	chain: an invalid value prevents a library file from being included, skipping initialization of key variables, leading to resultant eval injection.
CVE-2008-3637	Improper error checking in protection mechanism produces an uninitialized variable, allowing security bypass and code execution.
CVE-2008-4197	Use of uninitialized memory may allow code execution.
CVE-2008-2934	Free of an uninitialized pointer leads to crash and possible code execution.
CVE-2007-3749	OS kernel does not reset a port when starting a setuid program, allowing local users to access the port and gain privileges.
CVE-2008-0063	Product does not clear memory contents when generating an error message, leading to information leak.
CVE-2008-0062	Lack of initialization triggers NULL pointer dereference or double-free.
CVE-2008-0081	Uninitialized variable leads to code execution in popular desktop application.
CVE-2008-3688	chain: Uninitialized variable leads to infinite loop.
CVE-2008-3475	chain: Improper initialization leads to memory corruption.
CVE-2008-5021	Composite: race condition allows attacker to modify an object while it is still being initialized, causing software to access uninitialized memory.
CVE-2005-1036	Chain: Bypass of access restrictions due to improper authorization (CWE-862) of a user results from an improperly initialized (CWE-909) I/O permission bitmap
CVE-2008-3597	chain: game server can access player data structures before initialization has happened leading to NULL dereference
CVE-2009-2692	chain: uninitialized function pointers can be dereferenced allowing code execution
CVE-2009-0949	chain: improper initialization of memory can lead to NULL dereference
CVE-2009-3620	chain: some unprivileged ioctls do not verify that a structure has been initialized before invocation, leading to NULL dereference

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)
Resultant	(where the weakness is typically related to the presence of some other weaknesses)

Detection Methods

Method	Details
Automated Dynamic Analysis	This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Initialization problems may be detected with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Effectiveness: Moderate
Manual Dynamic Analysis	Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.
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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	740	CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	752	2009 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	846	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 3 - Declarations and Initialization (DCL)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	874	CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOf	Category - 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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	962	SFP Secondary Cluster: Unchecked Status Condition
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1135	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 01. Declarations and Initialization (DCL)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1306	CISQ Quality Measures - Reliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1308	CISQ Quality Measures - Security
MemberOf	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).	1340	CISQ Data Protection Measures
MemberOf	Category - 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	DISCOURAGED (this CWE ID should not be used to map to real-world vulnerabilities)
Reason	Abstraction
Rationale	This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-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	Mapped Node Name
PLOVER		Incorrect initialization
CERT C Secure Coding	ARR02-C	Explicitly specify array bounds, even if implicitly defined by an initializer
The CERT Oracle Secure Coding Standard for Java (2011)	DCL00-J	Prevent class initialization cycles
Software Fault Patterns	SFP4	Unchecked Status Condition

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-26	Leveraging Race Conditions
CAPEC-29	Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

References

[REF-436]	mercy. "Exploiting Uninitialized Data". 2006-01. <http://www.felinemenace.org/~mercy/papers/UBehavior/UBehavior.zip>.
[REF-437]	Microsoft Security Vulnerability Research & Defense. "MS08-014 : The Case of the Uninitialized Stack Variable Vulnerability". 2008-03-11. <https://msrc.microsoft.com/blog/2008/03/ms08-014-the-case-of-the-uninitialized-stack-variable-vulnerability/>. (URL validated: 2023-04-07)
[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
2008-04-11 (CWE Draft 9, 2008-04-11)	PLOVER
2008-04-11 (CWE Draft 9, 2008-04-11)
Modifications
Modification Date	Modifier	Organization
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Mapping_Notes
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Potential_Mitigations, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Observed_Examples
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated References, Taxonomy_Mappings
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Type
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Demonstrative_Examples, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Observed_Examples
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Detection_Factors, Potential_Mitigations
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Applicable_Platforms
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Potential_Mitigations
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Related_Attack_Patterns
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Description, Relationships
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Potential_Mitigations
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Modes_of_Introduction, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Weakness_Ordinalities
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-07-01	Sean Eidemiller	Cigital
2008-07-01	added/updated demonstrative examples
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Incorrect or Incomplete Initialization

Weakness ID: 20

View customized information:

Description

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.

Extended Description

Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code, or when communicating with other components.

Input can consist of:

raw data - strings, numbers, parameters, file contents, etc.
metadata - information about the raw data, such as headers or size

Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of metadata and raw data, with other simple or structured data.

Many properties of raw data or metadata may need to be validated upon entry into the code, such as:

specified quantities such as size, length, frequency, price, rate, number of operations, time, etc.
implied or derived quantities, such as the actual size of a file instead of a specified size
indexes, offsets, or positions into more complex data structures
symbolic keys or other elements into hash tables, associative arrays, etc.
well-formedness, i.e. syntactic correctness - compliance with expected syntax
lexical token correctness - compliance with rules for what is treated as a token
specified or derived type - the actual type of the input (or what the input appears to be)
consistency - between individual data elements, between raw data and metadata, between references, etc.
conformance to domain-specific rules, e.g. business logic
equivalence - ensuring that equivalent inputs are treated the same
authenticity, ownership, or other attestations about the input, e.g. a cryptographic signature to prove the source of the data

Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may be considered a contributing factor to improper input validation.

Common Consequences

Impact	Details
DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)	Scope: Availability An attacker could provide unexpected values and cause a program crash or arbitrary control of resource allocation, leading to excessive consumption of resources such as memory and CPU.
Read Memory; Read Files or Directories	Scope: Confidentiality An attacker could read confidential data if they are able to control resource references.
Modify Memory; Execute Unauthorized Code or Commands	Scope: Integrity, Confidentiality, Availability An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	Strategy: Attack Surface Reduction Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
Architecture and Design	Strategy: Libraries or Frameworks Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
Architecture and Design; Implementation	Strategy: Attack Surface Reduction Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
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. Effectiveness: High
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. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Implementation	When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
Implementation	Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
Implementation	Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
Implementation	Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
Implementation	When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

Relationships

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	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.	707	Improper Neutralization
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	179	Incorrect Behavior Order: Early Validation
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	622	Improper Validation of Function Hook Arguments
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1284	Improper Validation of Specified Quantity in Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1285	Improper Validation of Specified Index, Position, or Offset in Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1286	Improper Validation of Syntactic Correctness of Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1288	Improper Validation of Consistency within Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1289	Improper Validation of Unsafe Equivalence in Input
PeerOf	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
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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')
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	41	Improper Resolution of Path Equivalence
CanPrecede	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.	74	Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
CanPrecede	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 - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
MemberOf	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	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	129	Improper Validation of Array Index
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1284	Improper Validation of Specified Quantity in Input

Relevant to the view "Architectural Concepts" (View-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1019	Validate Inputs

Relevant to the view "Seven Pernicious Kingdoms" (View-700)

Nature	Type	ID	Name
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	15	External Control of System or Configuration Setting
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	73	External Control of File Name or Path
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	102	Struts: Duplicate Validation Forms
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	103	Struts: Incomplete validate() Method Definition
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	104	Struts: Form Bean Does Not Extend Validation Class
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	105	Struts: Form Field Without Validator
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	106	Struts: Plug-in Framework not in Use
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	107	Struts: Unused Validation Form
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	108	Struts: Unvalidated Action Form
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	109	Struts: Validator Turned Off
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	110	Struts: Validator Without Form Field
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	111	Direct Use of Unsafe JNI
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	112	Missing XML Validation
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	113	Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
ParentOf	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.	114	Process Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	117	Improper Output Neutralization for Logs
ParentOf	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 - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	120	Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	134	Use of Externally-Controlled Format String
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	190	Integer Overflow or Wraparound
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	466	Return of Pointer Value Outside of Expected Range
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	470	Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	785	Use of Path Manipulation Function without Maximum-sized Buffer

Modes Of Introduction

Phase

Note

Architecture and Design

Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

If a programmer believes that an attacker cannot modify certain inputs, then the programmer might not perform any input validation at all. For example, in web applications, many programmers believe that cookies and hidden form fields can not be modified from a web browser (CWE-472), although they can be altered using a proxy or a custom program. In a client-server architecture, the programmer might assume that client-side security checks cannot be bypassed, even when a custom client could be written that skips those checks (CWE-602).

Applicable Platforms

Languages

Class: Not Language-Specific (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This example demonstrates a shopping interaction in which the user is free to specify the quantity of items to be purchased and a total is calculated.

(bad code)

Example Language: Java

...
public static final double price = 20.00;
int quantity = currentUser.getAttribute("quantity");
double total = price * quantity;
chargeUser(total);
...

The user has no control over the price variable, however the code does not prevent a negative value from being specified for quantity. If an attacker were to provide a negative value, then the user would have their account credited instead of debited.

Example 2

This example asks the user for a height and width of an m X n game board with a maximum dimension of 100 squares.

(bad code)

Example Language: C

...
#define MAX_DIM 100
...
/* board dimensions */

int m,n, error;
board_square_t *board;
printf("Please specify the board height: \n");
error = scanf("%d", &m);
if ( EOF == error ){

die("No integer passed: Die evil hacker!\n");

}
printf("Please specify the board width: \n");
error = scanf("%d", &n);
if ( EOF == error ){

die("No integer passed: Die evil hacker!\n");

}
if ( m > MAX_DIM || n > MAX_DIM ) {

die("Value too large: Die evil hacker!\n");

}
board = (board_square_t*) malloc( m * n * sizeof(board_square_t));
...

While this code checks to make sure the user cannot specify large, positive integers and consume too much memory, it does not check for negative values supplied by the user. As a result, an attacker can perform a resource consumption (CWE-400) attack against this program by specifying two, large negative values that will not overflow, resulting in a very large memory allocation (CWE-789) and possibly a system crash. Alternatively, an attacker can provide very large negative values which will cause an integer overflow (CWE-190) and unexpected behavior will follow depending on how the values are treated in the remainder of the program.

Example 3

The following example shows a PHP application in which the programmer attempts to display a user's birthday and homepage.

(bad code)

Example Language: PHP

$birthday = $_GET['birthday'];
$homepage = $_GET['homepage'];
echo "Birthday: $birthday<br>Homepage: <a href=$homepage>click here</a>"

The programmer intended for $birthday to be in a date format and $homepage to be a valid URL. However, since the values are derived from an HTTP request, if an attacker can trick a victim into clicking a crafted URL with <script> tags providing the values for birthday and / or homepage, then the script will run on the client's browser when the web server echoes the content. Notice that even if the programmer were to defend the $birthday variable by restricting input to integers and dashes, it would still be possible for an attacker to provide a string of the form:

(attack code)

2009-01-09--

If this data were used in a SQL statement, it would treat the remainder of the statement as a comment. The comment could disable other security-related logic in the statement. In this case, encoding combined with input validation would be a more useful protection mechanism.

Furthermore, an XSS (CWE-79) attack or SQL injection (CWE-89) are just a few of the potential consequences when input validation is not used. Depending on the context of the code, CRLF Injection (CWE-93), Argument Injection (CWE-88), or Command Injection (CWE-77) may also be possible.

Example 4

The following example takes a user-supplied value to allocate an array of objects and then operates on the array.

(bad code)

Example Language: Java

private void buildList ( int untrustedListSize ){

if ( 0 > untrustedListSize ){

die("Negative value supplied for list size, die evil hacker!");

}
Widget[] list = new Widget [ untrustedListSize ];
list[0] = new Widget();

}

This example attempts to build a list from a user-specified value, and even checks to ensure a non-negative value is supplied. If, however, a 0 value is provided, the code will build an array of size 0 and then try to store a new Widget in the first location, causing an exception to be thrown.

Example 5

This Android application has registered to handle a URL when sent an intent:

(bad code)

Example Language: Java

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {

@Override
public void onReceive(Context context, Intent intent) {

if("com.example.URLHandler.openURL".equals(intent.getAction())) {

String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();

...
}

}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

Selected Observed Examples

Reference	Description
CVE-2024-37032	Large language model (LLM) management tool does not validate the format of a digest value (CWE-1287) from a private, untrusted model registry, enabling relative path traversal (CWE-23), a.k.a. Probllama
CVE-2022-45918	Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using "../" sequences (CWE-24)
CVE-2021-30860	Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
CVE-2021-30663	Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
CVE-2021-22205	Chain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.
CVE-2021-21220	Chain: insufficient input validation (CWE-20) in browser allows heap corruption (CWE-787), as exploited in the wild per CISA KEV.
CVE-2020-9054	Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.
CVE-2020-3452	Chain: security product has improper input validation (CWE-20) leading to directory traversal (CWE-22), as exploited in the wild per CISA KEV.
CVE-2020-3161	Improper input validation of HTTP requests in IP phone, as exploited in the wild per CISA KEV.
CVE-2020-3580	Chain: improper input validation (CWE-20) in firewall product leads to XSS (CWE-79), as exploited in the wild per CISA KEV.
CVE-2021-37147	Chain: caching proxy server has improper input validation (CWE-20) of headers, allowing HTTP response smuggling (CWE-444) using an "LF line ending"
CVE-2008-5305	Eval injection in Perl program using an ID that should only contain hyphens and numbers.
CVE-2008-2223	SQL injection through an ID that was supposed to be numeric.
CVE-2008-3477	lack of input validation in spreadsheet program leads to buffer overflows, integer overflows, array index errors, and memory corruption.
CVE-2008-3843	insufficient validation enables XSS
CVE-2008-3174	driver in security product allows code execution due to insufficient validation
CVE-2007-3409	infinite loop from DNS packet with a label that points to itself
CVE-2006-6870	infinite loop from DNS packet with a label that points to itself
CVE-2008-1303	missing parameter leads to crash
CVE-2007-5893	HTTP request with missing protocol version number leads to crash
CVE-2006-6658	request with missing parameters leads to information exposure
CVE-2008-4114	system crash with offset value that is inconsistent with packet size

Common Weakness Enumeration

CWE VIEW: Weaknesses Addressed by the SEI CERT C++ Coding Standard (2016 Version)

View Components

CWE-464: Addition of Data Structure Sentinel

Edit Custom Filter

CWE-770: Allocation of Resources Without Limits or Throttling

Edit Custom Filter

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

Edit Custom Filter

CWE-563: Assignment to Variable without Use

Edit Custom Filter

CWE-805: Buffer Access with Incorrect Length Value

Edit Custom Filter

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

Edit Custom Filter

CWE CATEGORY: CERT C++ Secure Coding Section 01 - Preprocessor (PRE)

CWE CATEGORY: CERT C++ Secure Coding Section 02 - Declarations and Initialization (DCL)

CWE CATEGORY: CERT C++ Secure Coding Section 03 - Expressions (EXP)

CWE CATEGORY: CERT C++ Secure Coding Section 04 - Integers (INT)

CWE CATEGORY: CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)

CWE CATEGORY: CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)

CWE CATEGORY: CERT C++ Secure Coding Section 07 - Characters and Strings (STR)

CWE CATEGORY: CERT C++ Secure Coding Section 08 - Memory Management (MEM)

CWE CATEGORY: CERT C++ Secure Coding Section 09 - Input Output (FIO)

CWE CATEGORY: CERT C++ Secure Coding Section 10 - Environment (ENV)

CWE CATEGORY: CERT C++ Secure Coding Section 11 - Signals (SIG)

CWE CATEGORY: CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)

CWE CATEGORY: CERT C++ Secure Coding Section 13 - Object Oriented Programming (OOP)

CWE CATEGORY: CERT C++ Secure Coding Section 14 - Concurrency (CON)

CWE CATEGORY: CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)

CWE-482: Comparing instead of Assigning

Edit Custom Filter

CWE-14: Compiler Removal of Code to Clear Buffers

Edit Custom Filter

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Edit Custom Filter

CWE-379: Creation of Temporary File in Directory with Insecure Permissions

Edit Custom Filter

CWE-561: Dead Code

Edit Custom Filter

CWE-390: Detection of Error Condition Without Action

Edit Custom Filter

CWE-369: Divide By Zero

Edit Custom Filter

CWE-415: Double Free

Edit Custom Filter

CWE-462: Duplicate Key in Associative List (Alist)

Edit Custom Filter

CWE-528: Exposure of Core Dump File to an Unauthorized Control Sphere

Edit Custom Filter

CWE-488: Exposure of Data Element to Wrong Session

Edit Custom Filter

CWE-403: Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')

Edit Custom Filter

CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere

Edit Custom Filter

CWE-570: Expression is Always False

Edit Custom Filter

CWE-571: Expression is Always True

Edit Custom Filter

CWE-73: External Control of File Name or Path

Edit Custom Filter

CWE-552: Files or Directories Accessible to External Parties

Edit Custom Filter

CWE-590: Free of Memory not on the Heap

Edit Custom Filter

CWE-686: Function Call With Incorrect Argument Type

Edit Custom Filter

CWE-687: Function Call With Incorrectly Specified Argument Value

Edit Custom Filter

CWE-209: Generation of Error Message Containing Sensitive Information

Edit Custom Filter

CWE-754: Improper Check for Unusual or Exceptional Conditions

Edit Custom Filter

CWE-703: Improper Check or Handling of Exceptional Conditions

Edit Custom Filter

CWE-460: Improper Cleanup on Thrown Exception

Edit Custom Filter

CWE-244: Improper Clearing of Heap Memory Before Release ('Heap Inspection')

Edit Custom Filter