CWE - VIEW SLICE: CWE-1040: Quality Weaknesses with Indirect Security Impacts (4.15)

CWE VIEW: Quality Weaknesses with Indirect Security Impacts

View ID: 1040

Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
Type: Implicit

Downloads: Booklet | CSV | XML

Objective

CWE identifiers in this view (slice) are quality issues that only indirectly make it easier to introduce a vulnerability and/or make the vulnerability more difficult to detect or mitigate.

Audience

Stakeholder	Description
Assessment Tool Vendors	This view makes it easier for assessment vendors to identify and improve coverage for quality-related weaknesses.
Software Developers	This view makes it easier for developers to identify and learn about issues that might make their code more difficult to maintain, perform efficiently or reliably, or secure.
Product Vendors	This view makes it easier for software vendors to identify important issues that may make their software more difficult to maintain, perform efficiently or reliably, or secure.

Filter

/Weakness_Catalog/Weaknesses/Weakness[Weakness_Ordinalities/Weakness_Ordinality/Ordinality='Indirect']

Membership

Nature	Type	ID	Name
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	474	Use of Function with Inconsistent Implementations
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	475	Undefined Behavior for Input to API
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	477	Use of Obsolete Function
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	483	Incorrect Block Delimitation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	484	Omitted Break Statement in Switch
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	489	Active Debug Code
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	546	Suspicious Comment
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	547	Use of Hard-coded, Security-relevant Constants
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	554	ASP.NET Misconfiguration: Not Using Input Validation Framework
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	561	Dead Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	562	Return of Stack Variable Address
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	563	Assignment to Variable without Use
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	585	Empty Synchronized Block
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	587	Assignment of a Fixed Address to a Pointer
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	589	Call to Non-ubiquitous API
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	594	J2EE Framework: Saving Unserializable Objects to Disk
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	676	Use of Potentially Dangerous Function
HasMember	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.	684	Incorrect Provision of Specified Functionality
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	758	Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	766	Critical Data Element Declared Public
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1041	Use of Redundant Code
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1042	Static Member Data Element outside of a Singleton Class Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1043	Data Element Aggregating an Excessively Large Number of Non-Primitive Elements
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1044	Architecture with Number of Horizontal Layers Outside of Expected Range
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1045	Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1046	Creation of Immutable Text Using String Concatenation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1047	Modules with Circular Dependencies
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1048	Invokable Control Element with Large Number of Outward Calls
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1049	Excessive Data Query Operations in a Large Data Table
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1050	Excessive Platform Resource Consumption within a Loop
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1051	Initialization with Hard-Coded Network Resource Configuration Data
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1052	Excessive Use of Hard-Coded Literals in Initialization
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1053	Missing Documentation for Design
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1054	Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1055	Multiple Inheritance from Concrete Classes
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1056	Invokable Control Element with Variadic Parameters
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1057	Data Access Operations Outside of Expected Data Manager Component
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1058	Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element
HasMember	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.	1059	Insufficient Technical Documentation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1060	Excessive Number of Inefficient Server-Side Data Accesses
HasMember	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.	1061	Insufficient Encapsulation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1062	Parent Class with References to Child Class
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1063	Creation of Class Instance within a Static Code Block
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1064	Invokable Control Element with Signature Containing an Excessive Number of Parameters
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1065	Runtime Resource Management Control Element in a Component Built to Run on Application Servers
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1066	Missing Serialization Control Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1067	Excessive Execution of Sequential Searches of Data Resource
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1068	Inconsistency Between Implementation and Documented Design
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1069	Empty Exception Block
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1070	Serializable Data Element Containing non-Serializable Item Elements
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1071	Empty Code Block
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1072	Data Resource Access without Use of Connection Pooling
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1073	Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1074	Class with Excessively Deep Inheritance
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1075	Unconditional Control Flow Transfer outside of Switch Block
HasMember	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.	1076	Insufficient Adherence to Expected Conventions
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1077	Floating Point Comparison with Incorrect Operator
HasMember	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.	1078	Inappropriate Source Code Style or Formatting
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1079	Parent Class without Virtual Destructor Method
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1080	Source Code File with Excessive Number of Lines of Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1082	Class Instance Self Destruction Control Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1083	Data Access from Outside Expected Data Manager Component
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1084	Invokable Control Element with Excessive File or Data Access Operations
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1085	Invokable Control Element with Excessive Volume of Commented-out Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1086	Class with Excessive Number of Child Classes
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1087	Class with Virtual Method without a Virtual Destructor
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1088	Synchronous Access of Remote Resource without Timeout
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1089	Large Data Table with Excessive Number of Indices
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1090	Method Containing Access of a Member Element from Another Class
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1091	Use of Object without Invoking Destructor Method
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1092	Use of Same Invokable Control Element in Multiple Architectural Layers
HasMember	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.	1093	Excessively Complex Data Representation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1094	Excessive Index Range Scan for a Data Resource
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1095	Loop Condition Value Update within the Loop
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1096	Singleton Class Instance Creation without Proper Locking or Synchronization
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1097	Persistent Storable Data Element without Associated Comparison Control Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1098	Data Element containing Pointer Item without Proper Copy Control Element
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1099	Inconsistent Naming Conventions for Identifiers
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1100	Insufficient Isolation of System-Dependent Functions
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1101	Reliance on Runtime Component in Generated Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1102	Reliance on Machine-Dependent Data Representation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1103	Use of Platform-Dependent Third Party Components
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1104	Use of Unmaintained Third Party Components
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1105	Insufficient Encapsulation of Machine-Dependent Functionality
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1106	Insufficient Use of Symbolic Constants
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1107	Insufficient Isolation of Symbolic Constant Definitions
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1108	Excessive Reliance on Global Variables
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1109	Use of Same Variable for Multiple Purposes
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1110	Incomplete Design Documentation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1111	Incomplete I/O Documentation
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1112	Incomplete Documentation of Program Execution
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1113	Inappropriate Comment Style
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1114	Inappropriate Whitespace Style
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1115	Source Code Element without Standard Prologue
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1116	Inaccurate Comments
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1117	Callable with Insufficient Behavioral Summary
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1118	Insufficient Documentation of Error Handling Techniques
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1119	Excessive Use of Unconditional Branching
HasMember	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.	1120	Excessive Code Complexity
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1121	Excessive McCabe Cyclomatic Complexity
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1122	Excessive Halstead Complexity
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1123	Excessive Use of Self-Modifying Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1124	Excessively Deep Nesting
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1125	Excessive Attack Surface
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1126	Declaration of Variable with Unnecessarily Wide Scope
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1127	Compilation with Insufficient Warnings or Errors
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1164	Irrelevant Code
HasMember	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1174	ASP.NET Misconfiguration: Improper Model Validation
HasMember	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1176	Inefficient CPU Computation
HasMember	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.	1177	Use of Prohibited Code
HasMember	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.	1357	Reliance on Insufficiently Trustworthy Component

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.

View Metrics

	CWEs in this view		Total CWEs
Weaknesses	112	out of	939
Categories	0	out of	374
Views	0	out of	50
Total	112	out of	1363

Content History

Submissions
Submission Date	Submitter	Organization
2018-07-12 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2018-07-12 (CWE 3.2, 2019-01-03)	View originally constructed using entries from Common Quality Enumeration (CQE) Draft 0.9.
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated View_Audience
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

View Components

Weakness ID: 489

Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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

The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.

Extended Description

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the product. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the product.

Alternate Terms

Leftover debug code:	This term originates from Seven Pernicious Kingdoms

Common Consequences

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.

Scope	Impact	Likelihood
Confidentiality Integrity Availability Access Control Other	Technical Impact: Bypass Protection Mechanism; Read Application Data; Gain Privileges or Assume Identity; Varies by Context The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access.

Potential Mitigations

Phases: Build and Compilation; Distribution

Remove debug code before deploying the application.

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" (CWE-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.	710	Improper Adherence to Coding Standards
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.	11	ASP.NET Misconfiguration: Creating Debug Binary
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.	215	Insertion of Sensitive Information Into Debugging Code

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

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
Implementation	In web-based applications, debug code is used to test and modify web application properties, configuration information, and functions. If a debug application is left on a production server, this oversight during the "software process" allows attackers access to debug functionality.
Build and Compilation
Operation

Applicable Platforms

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 (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Demonstrative Examples

Example 1

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

(bad code)

Example Language: HTML

</FORM>

Then a conforming link will look like:

(informative)

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

An attacker can change this to:

(attack code)

http://TARGET/authenticate_login.cgi?username=&password=&debug=1

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

Weakness Ordinalities

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

Detection Methods

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

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.	485	7PK - Encapsulation
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.	1002	SFP Secondary Cluster: Unexpected Entry Points
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1371	ICS Supply Chain: Poorly Documented or Undocumented Features
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

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

Notes

Other

In J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Leftover Debug Code
OWASP Top Ten 2004	A10	CWE More Specific	Insecure Configuration Management
Software Fault Patterns	SFP28		Unexpected access points

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-121	Exploit Non-Production Interfaces
CAPEC-661	Root/Jailbreak Detection Evasion via Debugging

References

[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	7 Pernicious Kingdoms
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Description, Modes_of_Introduction, Other_Notes, Time_of_Introduction
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Relationships, White_Box_Definitions
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Weakness_Ordinalities
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Description, Name, References, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Related_Attack_Patterns
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Alternate_Terms
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Description, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2020-02-24	Leftover Debug Code

Weakness ID: 587

Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.

View customized information:

Description

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

Extended Description

Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality Availability	Technical Impact: Execute Unauthorized Code or Commands If one executes code at a known location, an attacker might be able to inject code there beforehand.
Availability	Technical Impact: DoS: Crash, Exit, or Restart; Reduce Maintainability; Reduce Reliability If the code is ported to another platform or environment, the pointer is likely to be invalid and cause a crash.
Confidentiality Integrity	Technical Impact: Read Memory; Modify Memory The data at a known pointer location can be easily read or influenced by an attacker.

Potential Mitigations

Phase: Implementation

Never set a pointer to a fixed address.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	344	Use of Invariant Value in Dynamically Changing Context
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.	758	Reliance on Undefined, Unspecified, or Implementation-Defined Behavior

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	465	Pointer Issues

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Class: Assembly (Undetermined Prevalence)

Demonstrative Examples

Example 1

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

(bad code)

Example Language: C

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

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

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	738	CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	872	CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOf	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.	998	SFP Secondary Cluster: Glitch in Computation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1158	SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOf	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 could be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

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

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	INT36-C	Imprecise	Converting a pointer to integer or integer to pointer
Software Fault Patterns	SFP1		Glitch in computation

Content History

Submissions
Submission Date	Submitter	Organization
2006-12-15 (CWE Draft 5, 2006-12-15)	CWE Content Team	MITRE
2006-12-15 (CWE Draft 5, 2006-12-15)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Common_Consequences, Description, Other_Notes
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Taxonomy_Mappings, White_Box_Definitions
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Common_Consequences, Weakness_Ordinalities
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships, Time_of_Introduction, Type
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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

Weakness ID: 563

View customized information:

Description

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

Extended Description

After the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.

Alternate Terms

Unused Variable

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Quality Degradation; Varies by Context This weakness could be an indication of a bug in the program or a deprecated variable that was not removed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.

Potential Mitigations

Phase: Implementation

Remove unused variables from the code.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	1164	Irrelevant Code

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

Modes Of Introduction

Phase	Note
Implementation

Demonstrative Examples

Example 1

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

(bad code)

Example Language: C

r = getName();
r = getNewBuffer(buf);

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	747	CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOf	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	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.	886	SFP Primary Cluster: Unused entities
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1186	SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	MSC00-C		Compile cleanly at high warning levels
SEI CERT Perl Coding Standard	MSC01-PL	Imprecise	Detect and remove unused variables
Software Fault Patterns	SFP2		Unused Entities

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	Anonymous Tool Vendor (under NDA)
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Common_Consequences, Description, Name, Other_Notes
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Alternate_Terms, Name, Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships, Type
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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
Previous Entry Names
Change Date	Previous Entry Name
2014-06-23	Unused Variable

2017-11-08	Assignment to Variable without Use ('Unused Variable')

Weakness ID: 766

View customized information:

Description

The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.

Extended Description

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality	Technical Impact: Read Application Data; Modify Application Data Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.
Other	Technical Impact: Reduce Maintainability

Potential Mitigations

Phase: Implementation

Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	1061	Insufficient Encapsulation
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.	732	Incorrect Permission Assignment for Critical Resource

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	275	Permission Issues

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Java (Undetermined Prevalence)

Demonstrative Examples

Example 1

The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.

(bad code)

Example Language: C++

public: char* password;

Instead, the critical data should be declared private.

(good code)

Example Language: C++

private: char* password;

Even though this example declares the password to be private, there are other possible issues with this implementation, such as the possibility of recovering the password from process memory (CWE-257).

Example 2

The following example shows a basic user account class that includes member variables for the username and password as well as a public constructor for the class and a public method to authorize access to the user account.

(bad code)

Example Language: C++

#define MAX_PASSWORD_LENGTH 15
#define MAX_USERNAME_LENGTH 15

class UserAccount
{

public:

UserAccount(char *username, char *password)
{

if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {

ExitError("Invalid username or password");

}
strcpy(this->username, username);
strcpy(this->password, password);

}

int authorizeAccess(char *username, char *password)
{

if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {

ExitError("Invalid username or password");

}
// if the username and password in the input parameters are equal to

// the username and password of this account class then authorize access
if (strcmp(this->username, username) ||
strcmp(this->password, password))

return 0;

// otherwise do not authorize access
else

return 1;

}

char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];

};

However, the member variables username and password are declared public and therefore will allow access and changes to the member variables to anyone with access to the object. These member variables should be declared private as shown below to prevent unauthorized access and changes.

(good code)

Example Language: C++

class UserAccount
{
public:

...

private:

char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];

};

Observed Examples

Reference	Description
CVE-2010-3860	variables declared public allow remote read of system properties such as user name and home directory.

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	849	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1002	SFP Secondary Cluster: Unexpected Entry Points
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1130	CISQ Quality Measures (2016) - Maintainability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1139	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
CLASP		Failure to protect stored data from modification
The CERT Oracle Secure Coding Standard for Java (2011)	OBJ01-J	Declare data members as private and provide accessible wrapper methods
Software Fault Patterns	SFP28	Unexpected access points
OMG ASCMM	ASCMM-MNT-15

References

[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-15. 2016-01. <https://www.omg.org/spec/ASCMM/>. URL validated: 2023-04-07.

Content History

Submissions
Submission Date	Submitter	Organization
2009-03-03 (CWE 1.4, 2009-05-27)	CWE Content Team	MITRE
2009-03-03 (CWE 1.4, 2009-05-27)
Modifications
Modification Date	Modifier	Organization
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Demonstrative_Examples
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Observed_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Likelihood_of_Exploit, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Common_Consequences, Description, Name, References, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships, Time_of_Introduction, Type
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
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
Previous Entry Names
Change Date	Previous Entry Name
2019-01-03	Critical Variable Declared Public

Weakness ID: 561

View customized information:

Description

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

Extended Description

Dead code is code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Quality Degradation Dead code that results from code that can never be executed is an indication of problems with the source code that needs to be fixed and is an indication of poor quality.
Other	Technical Impact: Reduce Maintainability

Potential Mitigations

Phase: Implementation

Remove dead code before deploying the application.

Phase: Testing

Use a static analysis tool to spot dead code.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	1164	Irrelevant Code
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.	570	Expression is Always False
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.	571	Expression is Always True

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, on the only path where s can be assigned a non-null value, there is a return statement.

(bad code)

Example Language: C++

String s = null;
if (b) {

s = "Yes";
return;

}

if (s != null) {

Dead();

}

Example 2

In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code.

(bad code)

Example Language: Java

public class DoubleDead {

private void doTweedledee() {

doTweedledumb();

}
private void doTweedledumb() {

doTweedledee();

}
public static void main(String[] args) {

System.out.println("running DoubleDead");

}

(In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.)

Example 3

The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant.

(bad code)

Example Language: Java

public class Dead {

String glue;

public String getGlue() {

return "glue";

}

Observed Examples

Reference	Description
CVE-2014-1266	chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).

Weakness Ordinalities

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

Detection Methods

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Binary / Bytecode Quality Analysis

Compare binary / bytecode to application permission manifest

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Automated Monitored Execution

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Permission Manifest Analysis

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Source Code Quality Analyzer

Cost effective for partial coverage:

Warning Flags

Source code Weakness Analyzer

Context-configured Source Code Weakness Analyzer

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

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	747	CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOf	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	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.	886	SFP Primary Cluster: Unused entities
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1130	CISQ Quality Measures (2016) - Maintainability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1186	SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1307	CISQ Quality Measures - Maintainability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	MSC07-C		Detect and remove dead code
SEI CERT Perl Coding Standard	MSC00-PL	Exact	Detect and remove dead code
Software Fault Patterns	SFP2		Unused Entities
OMG ASCMM	ASCMM-MNT-20

References

[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-20. 2016-01. <https://www.omg.org/spec/ASCMM/>. URL validated: 2023-04-07.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	Anonymous Tool Vendor (under NDA)
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Other_Notes
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Observed_Examples
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Common_Consequences, References, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Observed_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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

Weakness ID: 585

View customized information:

Description

The product contains an empty synchronized block.

Extended Description

An empty synchronized block does not actually accomplish any synchronization and may indicate a troubled section of code. An empty synchronized block can occur because code no longer needed within the synchronized block is commented out without removing the synchronized block.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Other An empty synchronized block will wait until nobody else is using the synchronizer being specified. While this may be part of the desired behavior, because you haven't protected the subsequent code by placing it inside the synchronized block, nothing is stopping somebody else from modifying whatever it was you were waiting for while you run the subsequent code.

Potential Mitigations

Phase: Implementation

When you come across an empty synchronized statement, or a synchronized statement in which the code has been commented out, try to determine what the original intentions were and whether or not the synchronized block is still necessary.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	1071	Empty Code Block

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

Java (Undetermined Prevalence)

Demonstrative Examples

Example 1

The following code attempts to synchronize on an object, but does not execute anything in the synchronized block. This does not actually accomplish anything and may be a sign that a programmer is wrestling with synchronization but has not yet achieved the result they intend.

(bad code)

Example Language: Java

synchronized(this) { }

Instead, in a correct usage, the synchronized statement should contain procedures that access or modify data that is exposed to multiple threads. For example, consider a scenario in which several threads are accessing student records at the same time. The method which sets the student ID to a new value will need to make sure that nobody else is accessing this data at the same time and will require synchronization.

(good code)

public void setID(int ID){

synchronized(this){

this.ID = ID;

}

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	987	SFP Secondary Cluster: Multiple Locks/Unlocks
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
Software Fault Patterns	SFP21		Multiple locks/unlocks

References

[REF-478] "Intrinsic Locks and Synchronization (in Java)". <https://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html>. URL validated: 2023-04-07.

Content History

Submissions
Submission Date	Submitter	Organization
2006-12-15 (CWE Draft 5, 2006-12-15)	CWE Community
2006-12-15 (CWE Draft 5, 2006-12-15)	Submitted by members of the CWE community to extend early CWE versions
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Common_Consequences, Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, References
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships, Type
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships, Type
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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

Weakness ID: 1120

Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: ClassClass - 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 code is too complex, as calculated using a well-defined, quantitative measure.

Extended Description

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

This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Reduce Maintainability
Other	Technical Impact: Reduce Performance

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards
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.	1047	Modules with Circular Dependencies
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.	1056	Invokable Control Element with Variadic Parameters
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.	1060	Excessive Number of Inefficient Server-Side Data Accesses
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.	1064	Invokable Control Element with Signature Containing an Excessive Number of Parameters
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.	1075	Unconditional Control Flow Transfer outside of Switch Block
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.	1080	Source Code File with Excessive Number of Lines of Code
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.	1095	Loop Condition Value Update within the Loop
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.	1119	Excessive Use of Unconditional Branching
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.	1121	Excessive McCabe Cyclomatic Complexity
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.	1122	Excessive Halstead Complexity
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.	1123	Excessive Use of Self-Modifying Code
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.	1124	Excessively Deep Nesting
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.	1125	Excessive Attack Surface

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED-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

Content History

Submissions
Submission Date	Submitter	Organization
2018-07-02 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2018-07-02 (CWE 3.2, 2019-01-03)	Entry derived from Common Quality Enumeration (CQE) Draft 0.9.
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 1173

View customized information:

Description

The product does not use, or incorrectly uses, an input validation framework that is provided by the source language or an independent library.

Extended Description

Many modern coding languages provide developers with input validation frameworks to make the task of input validation easier and less error-prone. These frameworks will automatically check all input against specified criteria and direct execution to error handlers when invalid input is received. The improper use (i.e., an incorrect implementation or missing altogether) of these frameworks is not directly exploitable, but can lead to an exploitable condition if proper input validation is not performed later in the product. Not using provided input validation frameworks can also hurt the maintainability of code as future developers may not recognize the downstream input validation being used in the place of the validation framework.

Common Consequences

Scope	Impact	Likelihood
Integrity	Technical Impact: Unexpected State Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.

Potential Mitigations

Phase: Implementation

Properly use provided input validation frameworks.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	20	Improper Input 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.	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.	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.	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.	554	ASP.NET Misconfiguration: Not Using Input Validation Framework
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.	1174	ASP.NET Misconfiguration: Improper Model Validation

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1215	Data Validation Issues

Modes Of Introduction

Phase	Note
Architecture and Design	This weakness may occur when software designers choose to not leverage input validation frameworks provided by the source language.
Implementation	This weakness may occur when developers do not correctly use a provided input validation framework.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis

Some instances of improper input validation can be detected using automated static analysis.

A static analysis tool might allow the user to specify which application-specific methods or functions perform input validation; the tool might also have built-in knowledge of validation frameworks such as Struts. The tool may then suppress or de-prioritize any associated warnings. This allows the analyst to focus on areas of the software in which input validation does not appear to be present.

Except in the cases described in the previous paragraph, 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.	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.	1406	Comprehensive Categorization: Improper Input Validation

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Content History

Submissions
Submission Date	Submitter	Organization
2018-12-21 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2018-12-21 (CWE 3.2, 2019-01-03)
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 1078

Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
Abstraction: ClassClass - 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 source code does not follow desired style or formatting for indentation, white space, comments, etc.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	1076	Insufficient Adherence to Expected Conventions
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.	546	Suspicious Comment
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.	547	Use of Hard-coded, Security-relevant Constants
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.	1085	Invokable Control Element with Excessive Volume of Commented-out Code
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.	1099	Inconsistent Naming Conventions for Identifiers
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.	1106	Insufficient Use of Symbolic Constants
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.	1107	Insufficient Isolation of Symbolic Constant Definitions
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.	1109	Use of Same Variable for Multiple Purposes
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.	1113	Inappropriate Comment Style
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.	1114	Inappropriate Whitespace Style
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.	1115	Source Code Element without Standard Prologue
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.	1116	Inaccurate Comments
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.	1117	Callable with Insufficient Behavioral Summary

Demonstrative Examples

Example 1

The usage of symbolic names instead of hard-coded constants is preferred.

The following is an example of using a hard-coded constant instead of a symbolic name.

(bad code)

Example Language: C

char buffer[1024];
...
fgets(buffer, 1024, stdin);

If the buffer value needs to be changed, then it has to be altered in more than one place. If the developer forgets or does not find all occurrences, in this example it could lead to a buffer overflow.

(good code)

Example Language: C

enum { MAX_BUFFER_SIZE = 1024 };
...
char buffer[MAX_BUFFER_SIZE];
...
fgets(buffer, MAX_BUFFER_SIZE, stdin);

In this example the developer will only need to change one value and all references to the buffer size are updated, as a symbolic name is used instead of a hard-coded constant.

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: PROHIBITED

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

Reason: Other

Rationale:

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

Comments:

Look for weaknesses that are focused specifically on insecure behaviors that have more direct security implications.

Content History

Submissions
Submission Date	Submitter	Organization
2018-07-02 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2018-07-02 (CWE 3.2, 2019-01-03)	Entry derived from Common Quality Enumeration (CQE) Draft 0.9.
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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, Mapping_Notes

Weakness ID: 483

View customized information:

Description

The code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error.

Extended Description

In some languages, braces (or other delimiters) are optional for blocks. When the delimiter is omitted, it is possible to insert a logic error in which a statement is thought to be in a block but is not. In some cases, the logic error can have security implications.

Common Consequences

Scope	Impact	Likelihood
Confidentiality Integrity Availability	Technical Impact: Alter Execution Logic This is a general logic error which will often lead to obviously-incorrect behaviors that are quickly noticed and fixed. In lightly tested or untested code, this error may be introduced it into a production environment and provide additional attack vectors by creating a control flow path leading to an unexpected state in the application. The consequences will depend on the types of behaviors that are being incorrectly executed.

Potential Mitigations

Phase: Implementation

Always use explicit block delimitation and use static-analysis technologies to enforce this practice.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	670	Always-Incorrect Control Flow Implementation

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	438	Behavioral Problems

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Likelihood Of Exploit

Low

Demonstrative Examples

Example 1

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

(bad code)

Example Language: C

if (condition==true)

Do_X();
Do_Y();

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

Example 2

In this example, the programmer has indented the Do_Y() statement as if the intention is that the function should be associated with the preceding conditional and should only be called when the condition is true. However, because Do_X() was called on the same line as the conditional and there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

(bad code)

Example Language: C

if (condition==true) Do_X();

Do_Y();

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

Observed Examples

Reference	Description
CVE-2014-1266	incorrect indentation of "goto" statement makes it more difficult to detect an incorrect goto (Apple's "goto fail")

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis

Effectiveness: High

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).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	977	SFP Secondary Cluster: Design
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1410	Comprehensive Categorization: Insufficient Control Flow Management

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CLASP			Incorrect block delimitation

References

[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.

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
2010-04-28	Michael Koo and Paul Black	NIST
2010-04-28	Correction to Demonstrative Examples
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Demonstrative_Examples, Description, Other_Notes
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Observed_Examples
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships, Type
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Demonstrative_Examples

Weakness ID: 684

View customized information:

Description

The code does not function according to its published specifications, potentially leading to incorrect usage.

Extended Description

When providing functionality to an external party, it is important that the product behaves in accordance with the details specified. When requirements of nuances are not documented, the functionality may produce unintended behaviors for the caller, possibly leading to an exploitable state.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Quality Degradation

Potential Mitigations

Phase: Implementation

Ensure that your code strictly conforms to specifications.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards
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.	392	Missing Report of 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.	393	Return of Wrong Status Code
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.	440	Expected Behavior Violation
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.	446	UI Discrepancy for Security Feature
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.	451	User Interface (UI) Misrepresentation of Critical Information
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.	912	Hidden Functionality
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.	1245	Improper Finite State Machines (FSMs) in Hardware Logic

Modes Of Introduction

Phase	Note
Implementation

Demonstrative Examples

Example 1

In the following snippet from a doPost() servlet method, the server returns "200 OK" (default) even if an error occurs.

(bad code)

Example Language: Java

try {

// Something that may throw an exception.
...

} catch (Throwable t) {

logger.error("Caught: " + t.toString());
return;

}

Example 2

In the following example, an HTTP 404 status code is returned in the event of an IOException encountered in a Java servlet. A 404 code is typically meant to indicate a non-existent resource and would be somewhat misleading in this case.

(bad code)

Example Language: Java

try {

// something that might throw IOException
...

} catch (IOException ioe) {

response.sendError(SC_NOT_FOUND);

}

Observed Examples

Reference	Description
CVE-2002-1446	Error checking routine in PKCS#11 library returns "OK" status even when invalid signature is detected, allowing spoofed messages.
CVE-2001-1559	Chain: System call returns wrong value (CWE-393), leading to a resultant NULL dereference (CWE-476).
CVE-2003-0187	Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations.
CVE-1999-1446	UI inconsistency; visited URLs list not cleared when "Clear History" option is selected.

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	735	CERT C Secure Coding Standard (2008) Chapter 2 - Preprocessor (PRE)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1001	SFP Secondary Cluster: Use of an Improper API
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

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

Comments:

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

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	PRE09-C		Do not replace secure functions with less secure functions

Content History

Submissions
Submission Date	Submitter	Organization
2008-04-11 (CWE Draft 9, 2008-04-11)	CWE Content Team	MITRE
2008-04-11 (CWE Draft 9, 2008-04-11)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Description, Relationships
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Potential_Mitigations
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Description, Name
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships, Type
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Demonstrative_Examples, Observed_Examples
Previous Entry Names
Change Date	Previous Entry Name
2011-03-29	Failure to Provide Specified Functionality

Weakness ID: 1076

View customized information:

Description

The product's architecture, source code, design, documentation, or other artifact does not follow required conventions.

Extended Description

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Reduce Maintainability

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards
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.	586	Explicit Call to Finalize()
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.	594	J2EE Framework: Saving Unserializable Objects to Disk
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.	1045	Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor
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.	1070	Serializable Data Element Containing non-Serializable Item Elements
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.	1078	Inappropriate Source Code Style or Formatting
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.	1079	Parent Class without Virtual Destructor Method
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.	1082	Class Instance Self Destruction Control Element
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.	1087	Class with Virtual Method without a Virtual Destructor
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.	1091	Use of Object without Invoking Destructor Method
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.	1097	Persistent Storable Data Element without Associated Comparison Control Element
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.	1098	Data Element containing Pointer Item without Proper Copy Control Element
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.	1108	Excessive Reliance on Global Variables

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: PROHIBITED

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

Reason: Other

Rationale:

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

Comments:

Look for weaknesses that are focused specifically on insecure behaviors that have more direct security implications.

Content History

Submissions
Submission Date	Submitter	Organization
2018-07-02 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2018-07-02 (CWE 3.2, 2019-01-03)	Entry derived from Common Quality Enumeration (CQE) Draft 0.9.
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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, Relationships

Weakness ID: 1061

View customized information:

Description

The product does not sufficiently hide the internal representation and implementation details of data or methods, which might allow external components or modules to modify data unexpectedly, invoke unexpected functionality, or introduce dependencies that the programmer did not intend.

Extended Description

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards
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.	766	Critical Data Element Declared Public
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.	1054	Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer
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.	1057	Data Access Operations Outside of Expected Data Manager Component
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.	1062	Parent Class with References to Child Class
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.	1083	Data Access from Outside Expected Data Manager Component
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.	1090	Method Containing Access of a Member Element from Another Class
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.	1100	Insufficient Isolation of System-Dependent Functions
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.	1105	Insufficient Encapsulation of Machine-Dependent Functionality

Demonstrative Examples

Example 1

(bad code)

Example Language: C++

#define MAX_PASSWORD_LENGTH 15
#define MAX_USERNAME_LENGTH 15

class UserAccount
{

public:

UserAccount(char *username, char *password)
{

if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {

ExitError("Invalid username or password");

}
strcpy(this->username, username);
strcpy(this->password, password);

}

int authorizeAccess(char *username, char *password)
{

if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {

ExitError("Invalid username or password");

return 0;

// otherwise do not authorize access
else

return 1;

}

char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];

};

(good code)

Example Language: C++

class UserAccount
{
public:

...

private:

char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];

};

Observed Examples

Reference	Description
CVE-2010-3860	variables declared public allow remote read of system properties such as user name and home directory.

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED-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

References

[REF-969] Wikipedia. "Encapsulation (computer programming)". <https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)>.

Content History

Submissions
Submission Date	Submitter	Organization
2018-07-29 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2018-07-29 (CWE 3.2, 2019-01-03)
Modifications
Modification Date	Modifier	Organization
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
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

Weakness ID: 1059

View customized information:

Description

The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all the relevant software/hardware elements of the product, such as its usage, structure, architectural components, interfaces, design, implementation, configuration, operation, etc.

Extended Description

When technical documentation is limited or lacking, products are more difficult to maintain. This indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities.

When using time-limited or labor-limited third-party/in-house security consulting services (such as threat modeling, vulnerability discovery, or pentesting), insufficient documentation can force those consultants to invest unnecessary time in learning how the product is organized, instead of focusing their expertise on finding the flaws or suggesting effective mitigations.

With respect to hardware design, the lack of a formal, final manufacturer reference can make it difficult or impossible to evaluate the final product, including post-manufacture verification. One cannot ensure that design functionality or operation is within acceptable tolerances, conforms to specifications, and is free from unexpected behavior. Hardware-related documentation may include engineering artifacts such as hardware description language (HDLs), netlists, Gerber files, Bills of Materials, EDA (Electronic Design Automation) tool files, etc.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Varies by Context; Hide Activities; Reduce Reliability; Quality Degradation; Reduce Maintainability Without a method of verification, one cannot be sure that everything only functions as expected.

Potential Mitigations

Phases: Documentation; Architecture and Design

Ensure that design documentation is detailed enough to allow for post-manufacturing verification.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards
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.	1053	Missing Documentation for Design
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.	1110	Incomplete Design Documentation
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.	1111	Incomplete I/O Documentation
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.	1112	Incomplete Documentation of Program Execution
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.	1118	Insufficient Documentation of Error Handling Techniques

Relevant to the view "Hardware Design" (CWE-1194)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1195	Manufacturing and Life Cycle Management Concerns
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1208	Cross-Cutting Problems

Modes Of Introduction

Phase	Note
Architecture and Design
Documentation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Observed Examples

Reference	Description
CVE-2022-3203	A wireless access point manual specifies that the only method of configuration is via web interface (CWE-1059), but there is an undisclosed telnet server that was activated by default (CWE-912).

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1368	ICS Dependencies (& Architecture): External Digital Systems
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1371	ICS Supply Chain: Poorly Documented or Undocumented Features
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1375	ICS Engineering (Construction/Deployment): Gaps in Details/Data
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: PROHIBITED

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

Reason: Other

Rationale:

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

Comments:

Look for weaknesses that are focused specifically on insecure behaviors that have more direct security implications.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
ISA/IEC 62443	Part 2-4	Req SP.02.03 BR
ISA/IEC 62443	Part 2-4	Req SP.02.03 RE(1)
ISA/IEC 62443	Part 2-4	Req SP.03.03 RE(1)
ISA/IEC 62443	Part 4-1	Req SG-1
ISA/IEC 62443	Part 4-1	Req SG-2
ISA/IEC 62443	Part 4-1	Req SG-3
ISA/IEC 62443	Part 4-1	Req SG-4
ISA/IEC 62443	Part 4-1	Req SG-5
ISA/IEC 62443	Part 4-1	Req SG-6
ISA/IEC 62443	Part 4-1	Req SG-7

References

[REF-1248] Securing Energy Infrastructure Executive Task Force (SEI ETF). "Categories of Security Vulnerabilities in ICS". Poorly Documented or Undocumented Features. 2022-03-09. <https://inl.gov/wp-content/uploads/2022/03/SEI-ETF-NCSV-TPT-Categories-of-Security-Vulnerabilities-ICS-v1_03-09-22.pdf>.

[REF-1254] FDA. "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions Draft Guidance for Industry and Food and Drug Administration Staff (DRAFT GUIDANCE)". 2022-04-08. <https://www.fda.gov/media/119933/download>.

Content History

Submissions
Submission Date	Submitter	Organization
2018-07-02 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2018-07-02 (CWE 3.2, 2019-01-03)	Entry derived from Common Quality Enumeration (CQE) Draft 0.9.
Contributions
Contribution Date	Contributor	Organization
2021-06-11	Paul A. Wortman	Wells Fargo
2021-06-11	Submitted hardware-specific information about a "golden standard" that was integrated into this entry
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
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Applicable_Platforms, Common_Consequences, Description, Name, Potential_Mitigations, References, Relationships, Time_of_Introduction
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships, Taxonomy_Mappings
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Taxonomy_Mappings
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
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
Previous Entry Names
Change Date	Previous Entry Name
2022-04-28	Incomplete Documentation

Weakness ID: 594

View customized information:

Description

When the J2EE container attempts to write unserializable objects to disk there is no guarantee that the process will complete successfully.

Extended Description

In heavy load conditions, most J2EE application frameworks flush objects to disk to manage memory requirements of incoming requests. For example, session scoped objects, and even application scoped objects, are written to disk when required. While these application frameworks do the real work of writing objects to disk, they do not enforce that those objects be serializable, thus leaving the web application vulnerable to crashes induced by serialization failure. An attacker may be able to mount a denial of service attack by sending enough requests to the server to force the web application to save objects to disk.

Common Consequences

Scope	Impact	Likelihood
Integrity	Technical Impact: Modify Application Data Data represented by unserializable objects can be corrupted.
Availability	Technical Impact: DoS: Crash, Exit, or Restart Non-serializability of objects can lead to system crash.

Potential Mitigations

Phases: Architecture and Design; Implementation

All objects that become part of session and application scope must implement the java.io.Serializable interface to ensure serializability of containing objects.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	1076	Insufficient Adherence to Expected Conventions

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

Java (Undetermined Prevalence)

Demonstrative Examples

Example 1

In the following Java example, a Customer Entity JavaBean provides access to customer information in a database for a business application. The Customer Entity JavaBean is used as a session scoped object to return customer information to a Session EJB.

(bad code)

Example Language: Java

@Entity
public class Customer {

private String id;
private String firstName;
private String lastName;
private Address address;

public Customer() {
}

public Customer(String id, String firstName, String lastName) {...}

@Id
public String getCustomerId() {...}

public void setCustomerId(String id) {...}

public String getFirstName() {...}

public void setFirstName(String firstName) {...}

public String getLastName() {...}

public void setLastName(String lastName) {...}

@OneToOne()
public Address getAddress() {...}

public void setAddress(Address address) {...}

}

However, the Customer Entity JavaBean is an unserialized object which can cause serialization failure and crash the application when the J2EE container attempts to write the object to the system. Session scoped objects must implement the Serializable interface to ensure that the objects serialize properly.

(good code)

Example Language: Java

public class Customer implements Serializable {...}

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	998	SFP Secondary Cluster: Glitch in Computation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
Software Fault Patterns	SFP1		Glitch in computation

Content History

Submissions
Submission Date	Submitter	Organization
2006-12-15 (CWE Draft 5, 2006-12-15)	CWE Community
2006-12-15 (CWE Draft 5, 2006-12-15)	Submitted by members of the CWE community to extend early CWE versions
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Common_Consequences, Relationships, Other_Notes
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Description, Other_Notes
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships, Time_of_Introduction
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Relationships
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Persistence in J2EE Frameworks

Weakness ID: 484

View customized information:

Description

The product omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.

Extended Description

This can lead to critical code executing in situations where it should not.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Alter Execution Logic This weakness can cause unintended logic to be executed and other unexpected application behavior.

Potential Mitigations

Phase: Implementation

Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logical possibilities.

Phase: Implementation

The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	670	Always-Incorrect Control Flow Implementation
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.	710	Improper Adherence to Coding Standards

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	438	Behavioral Problems

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

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

(bad code)

Example Language: Java

public void printMessage(int month){

switch (month) {

case 1: print("January");
case 2: print("February");
case 3: print("March");
case 4: print("April");
case 5: print("May");
case 6: print("June");
case 7: print("July");
case 8: print("August");
case 9: print("September");
case 10: print("October");
case 11: print("November");
case 12: print("December");

}
println(" is a great month");

}

(bad code)

Example Language: C

void printMessage(int month){

switch (month) {

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

}
printf(" is a great month");

}

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

Weakness Ordinalities

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

Detection Methods

White Box

Omission of a break statement might be intentional, in order to support fallthrough. Automated detection methods might therefore be erroneous. Semantic understanding of expected product behavior is required to interpret whether the code is correct.

Black Box

Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.

Automated Static Analysis

Effectiveness: High

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).	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.	1307	CISQ Quality Measures - Maintainability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CLASP			Omitted break statement
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>.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Switch Statements", Page 337. 1st Edition. Addison Wesley. 2006.

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
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Description, Detection_Factors, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, Name, Other_Notes, Potential_Mitigations, Weakness_Ordinalities
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, References, Relationships, Taxonomy_Mappings
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Demonstrative_Examples
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Detection_Factors
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Demonstrative_Examples
Previous Entry Names
Change Date	Previous Entry Name
2008-11-24	Omitted Break Statement

Weakness ID: 1357

View customized information:

Description

The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.

Extended Description

Many modern hardware and software products are built by combining multiple smaller components together into one larger entity, often during the design or architecture phase. For example, a hardware component might be built by a separate supplier, or the product might use an open-source software library from a third party.

Regardless of the source, each component should be sufficiently trusted to ensure correct, secure operation of the product. If a component is not trustworthy, it can produce significant risks for the overall product, such as vulnerabilities that cannot be patched fast enough (if at all); hidden functionality such as malware; inability to update or replace the component if needed for security purposes; hardware components built from parts that do not meet specifications in ways that can lead to weaknesses; etc. Note that a component might not be trustworthy even if it is owned by the product vendor, such as a software component whose source code is lost and was built by developers who left the company, or a component that was developed by a separate company that was acquired and brought into the product's own company.

Note that there can be disagreement as to whether a component is sufficiently trustworthy, since trust is ultimately subjective. Different stakeholders (e.g., customers, vendors, governments) have various threat models and ways to assess trust, and design/architecture choices might make tradeoffs between security, reliability, safety, privacy, cost, and other characteristics.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Reduce Maintainability

Potential Mitigations

Phases: Requirements; Architecture and Design; Implementation

For each component, ensure that its supply chain is well-controlled with sub-tier suppliers using best practices. For third-party software components such as libraries, ensure that they are developed and actively maintained by reputable vendors.

Phases: Architecture and Design; Implementation; Integration; Manufacturing

Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], "An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships."

Phases: Operation; Patching and Maintenance

Continue to monitor changes in each of the product's components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, supplier practices that affect trustworthiness, etc.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards
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.	1104	Use of Unmaintained Third Party Components
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.	1329	Reliance on Component That is Not Updateable

Relevant to the view "Hardware Design" (CWE-1194)

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

Modes Of Introduction

Phase	Note
Requirements	Requirements might include criteria for which the only available solutions are provided by insufficiently trusted components.
Architecture and Design	An insufficiently trusted component might be selected because it is less expensive to do in-house, requires expertise that is not available in-house, or might allow the product to reach the market faster.

Applicable Platforms

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Observed Examples

Reference	Description
CVE-2020-9054	Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are "end-of-support" and cannot be patched (CWE-1277). [REF-1097]

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1367	ICS Dependencies (& Architecture): External Physical Systems
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1368	ICS Dependencies (& Architecture): External Digital Systems
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1370	ICS Supply Chain: Common Mode Frailties
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

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

Comments:

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

Notes

Maintenance

As of CWE 4.10, the name and description for this entry has undergone significant change and is still under public discussion, especially by members of the HW SIG.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
ISA/IEC 62443	Part 2-4	Req SP.03.02 RE(1)
ISA/IEC 62443	Part 2-4	Req SP.03.02 RE(2)
ISA/IEC 62443	Part 3-3	Req SR 1.13
ISA/IEC 62443	Part 4-2	Req EDR 3.12
ISA/IEC 62443	Part 4-2	Req HDR 3.12
ISA/IEC 62443	Part 4-2	Req NDR 3.12
ISA/IEC 62443	Part 4-2	Req EDR 3.13
ISA/IEC 62443	Part 4-2	Req HDR 3.13
ISA/IEC 62443	Part 4-2	Req NDR 3.13
ISA/IEC 62443	Part 4-2	Req CR-7.8
ISA/IEC 62443	Part 4-1	Req SM-6
ISA/IEC 62443	Part 4-1	Req SM-9
ISA/IEC 62443	Part 4-1	Req SM-10

References

[REF-1212] "A06:2021 - Vulnerable and Outdated Components". OWASP. 2021-09-24. <https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/>.

[REF-1246] National Telecommunications and Information Administration. "SOFTWARE BILL OF MATERIALS". <https://ntia.gov/page/software-bill-materials>. URL validated: 2023-04-07.

[REF-1247] NTIA Multistakeholder Process on Software Component Transparency Framing Working Group. "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)". 2021-10-21. <https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf>.

[REF-1097] Brian Krebs. "Zyxel Flaw Powers New Mirai IoT Botnet Strain". 2020-03-20. <https://krebsonsecurity.com/2020/03/zxyel-flaw-powers-new-mirai-iot-botnet-strain/>.

Content History

Submissions
Submission Date	Submitter	Organization
2022-04-20 (CWE 4.7, 2022-04-28)	CWE Content Team	MITRE
2022-04-20 (CWE 4.7, 2022-04-28)
Contributions
Contribution Date	Contributor	Organization
2023-06-29 (CWE 4.12, 2023-06-29)	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023-06-29 (CWE 4.12, 2023-06-29)	Suggested mappings to ISA/IEC 62443.
Modifications
Modification Date	Modifier	Organization
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Description, Maintenance_Notes, Modes_of_Introduction, Name, Potential_Mitigations, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Taxonomy_Mappings
Previous Entry Names
Change Date	Previous Entry Name
2023-01-31	Reliance on Uncontrolled Component

Weakness ID: 758

View customized information:

Description

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

Extended Description

This can lead to resultant weaknesses when the required properties change, such as when the product is ported to a different platform or if an interaction error (CWE-435) occurs.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Other

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards
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.	474	Use of Function with Inconsistent Implementations
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.	562	Return of Stack Variable Address
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.	587	Assignment of a Fixed Address to a Pointer
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.	588	Attempt to Access Child of a Non-structure Pointer
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.	1038	Insecure Automated Optimizations
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.	1102	Reliance on Machine-Dependent Data Representation
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.	1103	Use of Platform-Dependent Third Party Components
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.	1105	Insufficient Encapsulation of Machine-Dependent Functionality

Demonstrative Examples

Example 1

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

(bad code)

Example Language: C

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

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

Example 2

The following function returns a stack address.

(bad code)

Example Language: C

char* getName() {

char name[STR_MAX];
fillInName(name);
return name;

}

Observed Examples

Reference	Description
CVE-2006-1902	Change in C compiler behavior causes resultant buffer overflows in programs that depend on behaviors that were undefined in the C standard.

Weakness Ordinalities

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

Detection Methods

Fuzzing

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

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1001	SFP Secondary Cluster: Use of an Improper API
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1157	SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1158	SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOf	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.	1162	SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1163	SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1167	SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1170	SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
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.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

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

Comments:

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

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	ARR32-C	CWE More Abstract	Ensure size arguments for variable length arrays are in a valid range
CERT C Secure Coding	ERR34-C	Imprecise	Detect errors when converting a string to a number
CERT C Secure Coding	EXP30-C	CWE More Abstract	Do not depend on the order of evaluation for side effects
CERT C Secure Coding	EXP33-C	CWE More Abstract	Do not read uninitialized memory
CERT C Secure Coding	FIO46-C	CWE More Abstract	Do not access a closed file
CERT C Secure Coding	INT34-C	CWE More Abstract	Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand
CERT C Secure Coding	INT36-C	CWE More Abstract	Converting a pointer to integer or integer to pointer
CERT C Secure Coding	MEM30-C	CWE More Abstract	Do not access freed memory
CERT C Secure Coding	MSC14-C		Do not introduce unnecessary platform dependencies
CERT C Secure Coding	MSC15-C		Do not depend on undefined behavior
CERT C Secure Coding	MSC37-C	CWE More Abstract	Ensure that control never reaches the end of a non-void function

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)
Modifications
Modification Date	Modifier	Organization
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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

Weakness ID: 562

View customized information:

Description

A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

Extended Description

Because local variables are allocated on the stack, when a program returns a pointer to a local variable, it is returning a stack address. A subsequent function call is likely to re-use this same stack address, thereby overwriting the value of the pointer, which no longer corresponds to the same variable since a function's stack frame is invalidated when it returns. At best this will cause the value of the pointer to change unexpectedly. In many cases it causes the program to crash the next time the pointer is dereferenced.

Common Consequences

Scope	Impact	Likelihood
Availability Integrity Confidentiality	Technical Impact: Read Memory; Modify Memory; Execute Unauthorized Code or Commands; DoS: Crash, Exit, or Restart If the returned stack buffer address is dereferenced after the return, then an attacker may be able to modify or read memory, depending on how the address is used. If the address is used for reading, then the address itself may be exposed, or the contents that the address points to. If the address is used for writing, this can lead to a crash and possibly code execution.

Potential Mitigations

Phase: Testing

Use static analysis tools to spot return of the address of a stack variable.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	758	Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
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.	672	Operation on a Resource after Expiration or Release
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.	825	Expired Pointer Dereference

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Demonstrative Examples

Example 1

The following function returns a stack address.

(bad code)

Example Language: C

char* getName() {

char name[STR_MAX];
fillInName(name);
return name;

}

Weakness Ordinalities

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

Detection Methods

Fuzzing

Effectiveness: High

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	748	CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	998	SFP Secondary Cluster: Glitch in Computation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1156	SEI CERT C Coding Standard - Guidelines 02. 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	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.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	DCL30-C	CWE More Specific	Declare objects with appropriate storage durations
CERT C Secure Coding	POS34-C		Do not call putenv() with a pointer to an automatic variable as the argument
Software Fault Patterns	SFP1		Glitch in computation

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	Anonymous Tool Vendor (under NDA)
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Description, Other_Notes
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Common_Consequences
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Stack Address Returned

Weakness ID: 475

View customized information:

Description

The behavior of this function is undefined unless its control parameter is set to a specific value.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Quality Degradation; Varies by Context

Relationships

Relevant to the view "Research Concepts" (CWE-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.	573	Improper Following of Specification by Caller

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1228	API / Function Errors

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	398	7PK - Code Quality
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	998	SFP Secondary Cluster: Glitch in Computation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Notes

Other

The Linux Standard Base Specification 2.0.1 for libc places constraints on the arguments to some internal functions [21]. If the constraints are not met, the behavior of the functions is not defined. It is unusual for this function to be called directly. It is almost always invoked through a macro defined in a system header file, and the macro ensures that the following constraints are met: The value 1 must be passed to the third parameter (the version number) of the following file system function: __xmknod The value 2 must be passed to the third parameter (the group argument) of the following wide character string functions: __wcstod_internal __wcstof_internal __wcstol_internal __wcstold_internal __wcstoul_internal The value 3 must be passed as the first parameter (the version number) of the following file system functions: __xstat __lxstat __fxstat __xstat64 __lxstat64 __fxstat64

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Undefined Behavior
Software Fault Patterns	SFP1		Glitch in computation

References

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
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Undefined Behavior

Weakness ID: 474

View customized information:

Description

The code uses a function that has inconsistent implementations across operating systems and versions.

Extended Description

The use of inconsistent implementations can cause changes in behavior when the code is ported or built under a different environment than the programmer expects, which can lead to security problems in some cases.

The implementation of many functions varies by platform, and at times, even by different versions of the same platform. Implementation differences can include:

Slight differences in the way parameters are interpreted leading to inconsistent results.
Some implementations of the function carry significant security risks.
The function might not be defined on all platforms.
The function might change which return codes it can provide, or change the meaning of its return codes.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Quality Degradation; Varies by Context

Potential Mitigations

Phases: Architecture and Design; Requirements

Do not accept inconsistent behavior from the API specifications when the deviant behavior increase the risk level.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	758	Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
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.	589	Call to Non-ubiquitous API

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1228	API / Function Errors

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Often Prevalent)

PHP (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	398	7PK - Code Quality
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1001	SFP Secondary Cluster: Use of an Improper API
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Inconsistent Implementations
Software Fault Patterns	SFP3		Use of an improper API

References

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
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Other_Notes
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Applicable_Platforms, Description, Other_Notes
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Inconsistent Implementations

Weakness ID: 547

View customized information:

Description

The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.

Extended Description

If the developer does not find all occurrences of the hard-coded constants, an incorrect policy decision may be made if one of the constants is not changed. Making changes to these values will require code changes that may be difficult or impossible once the system is released to the field. In addition, these hard-coded values may become available to attackers if the code is ever disclosed.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Varies by Context; Quality Degradation The existence of hardcoded constants could cause unexpected behavior and the introduction of weaknesses during code maintenance or when making changes to the code if all occurrences are not modified. The use of hardcoded constants is an indication of poor quality.

Potential Mitigations

Phase: Implementation

Avoid using hard-coded constants. Configuration files offer a more flexible solution.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	1078	Inappropriate Source Code Style or Formatting

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

Modes Of Introduction

Phase	Note
Implementation

Demonstrative Examples

Example 1

The usage of symbolic names instead of hard-coded constants is preferred.

The following is an example of using a hard-coded constant instead of a symbolic name.

(bad code)

Example Language: C

char buffer[1024];
...
fgets(buffer, 1024, stdin);

(good code)

Example Language: C

enum { MAX_BUFFER_SIZE = 1024 };
...
char buffer[MAX_BUFFER_SIZE];
...
fgets(buffer, MAX_BUFFER_SIZE, stdin);

In this example the developer will only need to change one value and all references to the buffer size are updated, as a symbolic name is used instead of a hard-coded constant.

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	736	CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL)
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.	950	SFP Secondary Cluster: Hardcoded Sensitive Data
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1349	OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CERT C Secure Coding	DCL06-C		Use meaningful symbolic constants to represent literal values in program logic

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	Anonymous Tool Vendor (under NDA)
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Description, Relationships, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Description, Potential_Mitigations, Relationships, Taxonomy_Mappings
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships, Type
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Demonstrative_Examples, Mapping_Notes
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
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Security-relevant Constants

Weakness ID: 477

View customized information:

Description

The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.

Extended Description

As programming languages evolve, functions occasionally become obsolete due to:

Advances in the language
Improved understanding of how operations should be performed effectively and securely
Changes in the conventions that govern certain operations

Functions that are removed are usually replaced by newer counterparts that perform the same task in some different and hopefully improved way.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Quality Degradation

Potential Mitigations

Phase: Implementation

Refer to the documentation for the obsolete function in order to determine why it is deprecated or obsolete and to learn about alternative ways to achieve the same functionality.

Phase: Requirements

Consider seriously the security implications of using an obsolete function. Consider using alternate functions.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1228	API / Function Errors

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

The following code uses the deprecated function getpw() to verify that a plaintext password matches a user's encrypted password. If the password is valid, the function sets result to 1; otherwise it is set to 0.

(bad code)

Example Language: C

...
getpw(uid, pwdline);
for (i=0; i<3; i++){

cryptpw=strtok(pwdline, ":");
pwdline=0;

}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
...

Although the code often behaves correctly, using the getpw() function can be problematic from a security standpoint, because it can overflow the buffer passed to its second parameter. Because of this vulnerability, getpw() has been supplanted by getpwuid(), which performs the same lookup as getpw() but returns a pointer to a statically-allocated structure to mitigate the risk. Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

Example 2

In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a null pointer exception when it attempts to call the "Trim()" method.

(bad code)

Example Language: Java

String cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();

Example 3

The following code constructs a string object from an array of bytes and a value that specifies the top 8 bits of each 16-bit Unicode character.

(bad code)

Example Language: Java

...
String name = new String(nameBytes, highByte);
...

In this example, the constructor may not correctly convert bytes to characters depending upon which charset is used to encode the string represented by nameBytes. Due to the evolution of the charsets used to encode strings, this constructor was deprecated and replaced by a constructor that accepts as one of its parameters the name of the charset used to encode the bytes for conversion.

Weakness Ordinalities

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

Detection Methods

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Binary / Bytecode Quality Analysis

Cost effective for partial coverage:

Bytecode 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 Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Debugger

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 Quality Analyzer

Source code Weakness Analyzer

Context-configured Source Code Weakness Analyzer

Effectiveness: High

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Origin Analysis

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Formal Methods / Correct-By-Construction

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, 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.	398	7PK - Code Quality
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1001	SFP Secondary Cluster: Use of an Improper API
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1180	SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)
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.	1308	CISQ Quality Measures - Security
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Obsolete
Software Fault Patterns	SFP3		Use of an improper API
SEI CERT Perl Coding Standard	DCL30-PL	CWE More Specific	Do not import deprecated modules
SEI CERT Perl Coding Standard	EXP30-PL	CWE More Specific	Do not use deprecated or obsolete functions or modules

References

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
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Other_Notes
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Demonstrative_Examples
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Description, Other_Notes, Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Name, Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2008-01-30	Obsolete

2017-11-08	Use of Obsolete Functions

Weakness ID: 676

View customized information:

Description

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.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Varies by Context; Quality Degradation; Unexpected State If the function is used incorrectly, then it could result in security problems.

Potential Mitigations

Phases: Build and Compilation; Implementation

Identify a list of prohibited API functions and prohibit developers from using these functions, providing safer alternatives. In some cases, automatic code analysis tools or the compiler can be instructed to spot use of prohibited functions, such as the "banned.h" include file from Microsoft's SDL. [REF-554] [REF-7]

Relationships

Relevant to the view "Research Concepts" (CWE-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.	1177	Use of Prohibited Code
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

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1228	API / Function Errors

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

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.

Observed Examples

Reference	Description
CVE-2007-1470	Library has multiple buffer overflows using sprintf() and strcpy()
CVE-2009-3849	Buffer overflow using strcat()
CVE-2006-2114	Buffer overflow using strcpy()
CVE-2006-0963	Buffer overflow using strcpy()
CVE-2011-0712	Vulnerable use of strcpy() changed to use safer strlcpy()
CVE-2008-5005	Buffer overflow using strcpy()

Weakness Ordinalities

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

Detection Methods

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

Cost effective for partial coverage:

Binary / Bytecode Quality Analysis

Binary / Bytecode simple extractor - strings, ELF readers, etc.

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 Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Debugger

Cost effective for partial coverage:

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

Cost effective for partial coverage:

Warning Flags

Source Code Quality Analyzer

Effectiveness: High

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Origin Analysis

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Formal Methods / Correct-By-Construction

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, 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.	738	CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
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.	746	CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
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.	872	CERT C++ Secure Coding Section 04 - Integers (INT)
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.	1001	SFP Secondary Cluster: Use of an Improper API
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.	1165	SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1167	SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1169	SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1170	SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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:

Notes

Relationship

This weakness is different than CWE-242 (Use of Inherently Dangerous Function). CWE-242 covers functions with such significant security problems that they can never be guaranteed to be safe. Some functions, if used properly, do not directly pose a security risk, but can introduce a weakness if not called correctly. These are regarded as potentially dangerous. A well-known example is the strcpy() function. When provided with a destination buffer that is larger than its source, strcpy() will not overflow. However, it is so often misused that some developers prohibit strcpy() entirely.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Dangerous Functions
CERT C Secure Coding	CON33-C	CWE More Abstract	Avoid race conditions when using library functions
CERT C Secure Coding	ENV33-C	CWE More Abstract	Do not call system()
CERT C Secure Coding	ERR07-C		Prefer functions that support error checking over equivalent functions that don't
CERT C Secure Coding	ERR34-C	CWE More Abstract	Detect errors when converting a string to a number
CERT C Secure Coding	FIO01-C		Be careful using functions that use file names for identification
CERT C Secure Coding	MSC30-C	CWE More Abstract	Do not use the rand() function for generating pseudorandom numbers
CERT C Secure Coding	STR31-C	Imprecise	Guarantee that storage for strings has sufficient space for character data and the null terminator
Software Fault Patterns	SFP3		Use of an improper API

References

[REF-554] Michael Howard. "Security Development Lifecycle (SDL) Banned Function Calls". <https://learn.microsoft.com/en-us/previous-versions/bb288454(v=msdn.10)?redirectedfrom=MSDN>. URL validated: 2023-04-07.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Safe String Handling" Page 156, 160. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[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.

Content History

Submissions
Submission Date	Submitter	Organization
2008-04-11 (CWE Draft 9, 2008-04-11)	7 Pernicious Kingdoms
2008-04-11 (CWE Draft 9, 2008-04-11)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Sean Eidemiller	Cigital
2008-07-01	added/updated demonstrative examples
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Relationships
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Demonstrative_Examples, Other_Notes, References, Relationship_Notes
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences, Observed_Examples, Potential_Mitigations, References, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Related_Attack_Patterns, Relationships, Weakness_Ordinalities
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Causal_Nature, References, Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Weakness_Ordinalities
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Detection_Factors, References, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Demonstrative_Examples
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships, Time_of_Introduction
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 1041

Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
Abstraction: BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 has multiple functions, methods, procedures, macros, etc. that contain the same code.

Extended Description

This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. For example, if there are two copies of the same code, the programmer might fix a weakness in one copy while forgetting to fix the same weakness in another copy.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Reduce Maintainability

Potential Mitigations

Phase: Implementation

Merge common functionality into a single function and then call that function from across the entire code base.

Relationships

Relevant to the view "Research Concepts" (CWE-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.	710	Improper Adherence to Coding Standards

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

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

In the following Java example the code performs some complex math when specific test conditions are met. The math is the same in each case and the equations are repeated within the code. Unfortunately if a future change needs to be made then that change needs to be made in all locations. This opens the door to mistakes being made and the changes not being made in the same way in each instance.

(bad code)

Example Language: Java

public class Main {

public static void main(String[] args) {

double s = 10.0;
double r = 1.0;
double pi = 3.14159;
double surface_area;

if(r > 0.0) {

// complex math equations
surface_area = pi * r * s + pi * Math.pow(r, 2);

}

if(r > 1.0) {

// a complex set of math
surface_area = pi * r * s + pi * Math.pow(r, 2);

}

It is recommended to place the complex math into its own function and then call that function whenever necessary.

(good code)

Example Language: Java

public class Main {

private double ComplexMath(double r, double s) {

//complex math equations
double pi = Math.PI;
double surface_area = pi * r * s + pi * Math.pow(r, 2);
return surface_area;

}

public static void main(String[] args) {

double s = 10.0;
double r = 1.0;
double surface_area;

if(r > 0.0) {

surface_area = ComplexMath(r, s);

}

if(r > 1.0) {

surface_area = ComplexMath(r, s);

}

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1130	CISQ Quality Measures (2016) - Maintainability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1307	CISQ Quality Measures - Maintainability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1412	Comprehensive Categorization: Poor Coding Practices

Vulnerability Mapping Notes

Usage: PROHIBITED

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

Reason: Other

Rationale:

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

Comments:

Look for weaknesses that are focused specifically on insecure behaviors that have more direct security implications.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
OMG ASCMM	ASCMM-MNT-19

References

[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-19. 2016-01. <https://www.omg.org/spec/ASCMM/>. URL validated: 2023-04-07.

Content History

Submissions
Submission Date	Submitter	Organization
2018-07-02 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2018-07-02 (CWE 3.2, 2019-01-03)	Entry derived from Common Quality Enumeration (CQE) Draft 0.9.
Contributions
Contribution Date	Contributor	Organization
2022-08-15	Drew Buttner
2022-08-15	Suggested new demonstrative examples, mitigations, and applicable platforms.
Modifications
Modification Date	Modifier	Organization
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms, Demonstrative_Examples, Potential_Mitigations
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
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

Common Weakness Enumeration

CWE VIEW: Quality Weaknesses with Indirect Security Impacts

View Components

CWE-489: Active Debug Code

Edit Custom Filter

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

Edit Custom Filter

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

Edit Custom Filter

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

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-589: Call to Non-ubiquitous API

Edit Custom Filter

CWE-1117: Callable with Insufficient Behavioral Summary

Edit Custom Filter

CWE-1082: Class Instance Self Destruction Control Element

Edit Custom Filter

CWE-1086: Class with Excessive Number of Child Classes

Edit Custom Filter

CWE-1074: Class with Excessively Deep Inheritance

Edit Custom Filter

CWE-1087: Class with Virtual Method without a Virtual Destructor

Edit Custom Filter

CWE-1127: Compilation with Insufficient Warnings or Errors

Edit Custom Filter

CWE-1063: Creation of Class Instance within a Static Code Block

Edit Custom Filter

CWE-1046: Creation of Immutable Text Using String Concatenation

Edit Custom Filter

CWE-766: Critical Data Element Declared Public

Edit Custom Filter

CWE-1083: Data Access from Outside Expected Data Manager Component

Edit Custom Filter

CWE-1057: Data Access Operations Outside of Expected Data Manager Component

Edit Custom Filter

CWE-1043: Data Element Aggregating an Excessively Large Number of Non-Primitive Elements

Edit Custom Filter

CWE-1098: Data Element containing Pointer Item without Proper Copy Control Element

Edit Custom Filter

CWE-1072: Data Resource Access without Use of Connection Pooling

Edit Custom Filter

CWE-561: Dead Code

Edit Custom Filter

CWE-1126: Declaration of Variable with Unnecessarily Wide Scope

Edit Custom Filter

CWE-1071: Empty Code Block

Edit Custom Filter

CWE-1069: Empty Exception Block

Edit Custom Filter

CWE-585: Empty Synchronized Block

Edit Custom Filter

CWE-1125: Excessive Attack Surface

Edit Custom Filter

CWE-1120: Excessive Code Complexity

Edit Custom Filter

CWE-1049: Excessive Data Query Operations in a Large Data Table

Edit Custom Filter

CWE-1067: Excessive Execution of Sequential Searches of Data Resource

Edit Custom Filter

CWE-1122: Excessive Halstead Complexity

Edit Custom Filter

CWE-1094: Excessive Index Range Scan for a Data Resource

Edit Custom Filter

CWE-1121: Excessive McCabe Cyclomatic Complexity

Edit Custom Filter

CWE-1060: Excessive Number of Inefficient Server-Side Data Accesses

Edit Custom Filter

CWE-1050: Excessive Platform Resource Consumption within a Loop

Edit Custom Filter

CWE-1108: Excessive Reliance on Global Variables

Edit Custom Filter

CWE-1052: Excessive Use of Hard-Coded Literals in Initialization

Edit Custom Filter

CWE-1123: Excessive Use of Self-Modifying Code

Edit Custom Filter

CWE-1119: Excessive Use of Unconditional Branching