CWE

Common Weakness Enumeration

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

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-1081: Entries with Maintenance Notes (4.14)  
ID

CWE VIEW: Entries with Maintenance Notes

View ID: 1081
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
Type: Implicit
Downloads: Booklet | CSV | XML
+ Objective
CWE entries in this view have maintenance notes. Maintenance notes are an indicator that an entry might change significantly in future versions. This view was created due to feedback from the CWE Board and participants in the CWE Compatibility Summit in March 2021.
+ Audience
StakeholderDescription
Assessment Tool VendorsAssessment vendors may use this view to anticipate future changes to CWE that will help them to better prepare customers for important changes in CWE.
+ Filter
/Weakness_Catalog/*/*[Notes/Note[@Type='Maintenance']]
+ Membership
NatureTypeIDName
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.16Configuration
HasMemberClassClass - 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.20Improper Input Validation
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.32Path Traversal: '...' (Triple Dot)
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.33Path Traversal: '....' (Multiple Dot)
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.73External Control of File Name or Path
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.91XML Injection (aka Blind XPath Injection)
HasMemberClassClass - 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.99Improper Control of Resource Identifiers ('Resource Injection')
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.103Struts: Incomplete validate() Method Definition
HasMemberClassClass - 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.114Process Control
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.131Incorrect Calculation of Buffer Size
HasMemberClassClass - 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.159Improper Handling of Invalid Use of Special Elements
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.170Improper Null Termination
HasMemberClassClass - 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.172Encoding Error
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.192Integer Coercion Error
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.194Unexpected Sign Extension
HasMemberClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.202Exposure of Sensitive Information Through Data Queries
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.213Exposure of Sensitive Information Due to Incompatible Policies
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.226Sensitive Information in Resource Not Removed Before Reuse
HasMemberClassClass - 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.228Improper Handling of Syntactically Invalid Structure
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.234Failure to Handle Missing Parameter
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.250Execution with Unnecessary Privileges
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.257Storing Passwords in a Recoverable Format
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.259Use of Hard-coded Password
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.264Permissions, Privileges, and Access Controls
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.267Privilege Defined With Unsafe Actions
HasMemberClassClass - 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.269Improper Privilege Management
HasMemberClassClass - 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.271Privilege Dropping / Lowering Errors
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.272Least Privilege Violation
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.274Improper Handling of Insufficient Privileges
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.280Improper Handling of Insufficient Permissions or Privileges
HasMemberClassClass - 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.282Improper Ownership Management
HasMemberPillarPillar - 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.284Improper Access Control
HasMemberClassClass - 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.286Incorrect User Management
HasMemberClassClass - 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.287Improper Authentication
HasMemberClassClass - 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.300Channel Accessible by Non-Endpoint
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.301Reflection Attack in an Authentication Protocol
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.319Cleartext Transmission of Sensitive Information
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.320Key Management Errors
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.321Use of Hard-coded Cryptographic Key
HasMemberClassClass - 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.327Use of a Broken or Risky Cryptographic Algorithm
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.328Use of Weak Hash
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.329Generation of Predictable IV with CBC Mode
HasMemberClassClass - 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.330Use of Insufficiently Random Values
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.331Insufficient Entropy
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.332Insufficient Entropy in PRNG
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.333Improper Handling of Insufficient Entropy in TRNG
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.334Small Space of Random Values
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.335Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.336Same Seed in Pseudo-Random Number Generator (PRNG)
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.337Predictable Seed in Pseudo-Random Number Generator (PRNG)
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.338Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.339Small Seed Space in PRNG
HasMemberClassClass - 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.340Generation of Predictable Numbers or Identifiers
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.341Predictable from Observable State
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.342Predictable Exact Value from Previous Values
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.343Predictable Value Range from Previous Values
HasMemberClassClass - 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.345Insufficient Verification of Data Authenticity
HasMemberClassClass - 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.346Origin Validation Error
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.350Reliance on Reverse DNS Resolution for a Security-Critical Action
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.359Exposure of Private Personal Information to an Unauthorized Actor
HasMemberClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.372Incomplete Internal State Distinction
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.385Covert Timing Channel
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.387Signal Errors
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.391Unchecked Error Condition
HasMemberClassClass - 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.400Uncontrolled Resource Consumption
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.428Unquoted Search Path or Element
HasMemberClassClass - 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.441Unintended Proxy or Intermediary ('Confused Deputy')
HasMemberClassClass - 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.446UI Discrepancy for Security Feature
HasMemberClassClass - 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.451User Interface (UI) Misrepresentation of Critical Information
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.453Insecure Default Variable Initialization
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.466Return of Pointer Value Outside of Expected Range
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.502Deserialization of Untrusted Data
HasMemberClassClass - 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.514Covert Channel
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.515Covert Storage Channel
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.538Insertion of Sensitive Information into Externally-Accessible File or Directory
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.600Uncaught Exception in Servlet
HasMemberClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
HasMemberViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.640Weak Password Recovery Mechanism for Forgotten Password
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.654Reliance on a Single Factor in a Security Decision
HasMemberClassClass - 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.655Insufficient Psychological Acceptability
HasMemberClassClass - 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.657Violation of Secure Design Principles
HasMemberClassClass - 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.662Improper Synchronization
HasMemberPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
HasMemberClassClass - 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.667Improper Locking
HasMemberClassClass - 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.670Always-Incorrect Control Flow Implementation
HasMemberPillarPillar - 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.697Incorrect Comparison
HasMemberPillarPillar - 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.707Improper Neutralization
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.708Incorrect Ownership Assignment
HasMemberClassClass - 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.732Incorrect Permission Assignment for Critical Resource
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.760Use of a One-Way Hash with a Predictable Salt
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.761Free of Pointer not at Start of Buffer
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.763Release of Invalid Pointer or Reference
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.764Multiple Locks of a Critical Resource
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.765Multiple Unlocks of a Critical Resource
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.767Access to Critical Private Variable via Public Method
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.772Missing Release of Resource after Effective Lifetime
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.780Use of RSA Algorithm without OAEP
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.784Reliance on Cookies without Validation and Integrity Checking in a Security Decision
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.785Use of Path Manipulation Function without Maximum-sized Buffer
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.798Use of Hard-coded Credentials
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.820Missing Synchronization
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.821Incorrect Synchronization
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.822Untrusted Pointer Dereference
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.823Use of Out-of-range Pointer Offset
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.824Access of Uninitialized Pointer
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.825Expired Pointer Dereference
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.915Improperly Controlled Modification of Dynamically-Determined Object Attributes
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.917Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
HasMemberClassClass - 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.922Insecure Storage of Sensitive Information
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.924Improper Enforcement of Message Integrity During Transmission in a Communication Channel
HasMemberVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.925Improper Verification of Intent by Broadcast Receiver
HasMemberViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1037Processor Optimization Removal or Modification of Security-critical Code
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1188Initialization of a Resource with an Insecure Default
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1204Generation of Weak Initialization Vector (IV)
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1240Use of a Cryptographic Primitive with a Risky Implementation
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1241Use of Predictable Algorithm in Random Number Generator
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1253Incorrect Selection of Fuse Values
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1259Improper Restriction of Security Token Assignment
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1260Improper Handling of Overlap Between Protected Memory Ranges
HasMemberClassClass - 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.1263Improper Physical Access Control
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1264Hardware Logic with Insecure De-Synchronization between Control and Data Channels
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1266Improper Scrubbing of Sensitive Data from Decommissioned Device
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1268Policy Privileges are not Assigned Consistently Between Control and Data Agents
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1271Uninitialized Value on Reset for Registers Holding Security Settings
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1273Device Unlock Credential Sharing
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1278Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1282Assumed-Immutable Data is Stored in Writable Memory
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1283Mutable Attestation or Measurement Reporting Data
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1284Improper Validation of Specified Quantity in Input
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1285Improper Validation of Specified Index, Position, or Offset in Input
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1286Improper Validation of Syntactic Correctness of Input
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1287Improper Validation of Specified Type of Input
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1288Improper Validation of Consistency within Input
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1289Improper Validation of Unsafe Equivalence in Input
HasMemberClassClass - 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.1294Insecure Security Identifier Mechanism
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1296Incorrect Chaining or Granularity of Debug Components
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1297Unprotected Confidential Information on Device is Accessible by OSAT Vendors
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1301Insufficient or Incomplete Data Removal within Hardware Component
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1303Non-Transparent Sharing of Microarchitectural Resources
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1316Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1319Improper Protection against Electromagnetic Fault Injection (EM-FI)
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1336Improper Neutralization of Special Elements Used in a Template Engine
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1342Information Exposure through Microarchitectural State after Transient Execution
HasMemberViewView - 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).1344Weaknesses in OWASP Top Ten (2021)
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1352OWASP Top Ten 2021 Category A06:2021 - Vulnerable and Outdated Components
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1354OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1355OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1356OWASP Top Ten 2021 Category A10:2021 - Server-Side Request Forgery (SSRF)
HasMemberClassClass - 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.1357Reliance on Insufficiently Trustworthy Component
HasMemberViewView - 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).1358Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1359ICS Communications
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1360ICS Dependencies (& Architecture)
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1361ICS Supply Chain
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1362ICS Engineering (Constructions/Deployment)
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1363ICS Operations (& Maintenance)
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1367ICS Dependencies (& Architecture): External Physical Systems
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1369ICS Supply Chain: IT/OT Convergence/Expansion
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1370ICS Supply Chain: Common Mode Frailties
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1371ICS Supply Chain: Poorly Documented or Undocumented Features
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1372ICS Supply Chain: OT Counterfeit and Malicious Corruption
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1373ICS Engineering (Construction/Deployment): Trust Model Problems
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1374ICS Engineering (Construction/Deployment): Maker Breaker Blindness
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1375ICS Engineering (Construction/Deployment): Gaps in Details/Data
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1376ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1377ICS Engineering (Construction/Deployment): Inherent Predictability in Design
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1378ICS Operations (& Maintenance): Gaps in obligations and training
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1379ICS Operations (& Maintenance): Human factors in ICS environments
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1380ICS Operations (& Maintenance): Post-analysis changes
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1381ICS Operations (& Maintenance): Exploitable Standard Operational Procedures
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1382ICS Operations (& Maintenance): Emerging Energy Technologies
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1383ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1386Insecure Operation on Windows Junction / Mount Point
HasMemberViewView - 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).1424Weaknesses Addressed by ISA/IEC 62443 Requirements
+ 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 viewTotal CWEs
Weaknesses143out of 938
Categories39out of 374
Views5out of 50
Total187out of1362
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2021-03-14
(CWE 4.4, 2021-03-15)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

View Components

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

CWE-824: Access of Uninitialized Pointer

Weakness ID: 824
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.
×

Edit Custom Filter


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

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

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

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
CanPrecedeBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.125Out-of-bounds Read
CanPrecedeBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.787Out-of-bounds Write
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
Section HelpThis 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "CISQ Quality Measures (2020)" (CWE-1305)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "CISQ Data Protection Measures" (CWE-1340)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

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

Technical Impact: DoS: Crash, Exit, or Restart

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

Technical Impact: Execute Unauthorized Code or Commands

If the uninitialized pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.
+ Observed Examples
ReferenceDescription
chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
Pointer in structure is not initialized, leading to NULL pointer dereference (CWE-476) and system crash.
Free of an uninitialized pointer.
Improper handling of invalid signatures leads to free of invalid pointer.
Invalid encoding triggers free of uninitialized pointer.
Crafted PNG image leads to free of uninitialized pointer.
Crafted GIF image leads to free of uninitialized pointer.
Access of uninitialized pointer might lead to code execution.
Step-based manipulation: invocation of debugging function before the primary initialization function leads to access of an uninitialized pointer and code execution.
Unchecked return values can lead to a write to an uninitialized pointer.
zero-length input leads to free of uninitialized pointer.
Crafted font leads to uninitialized function pointer.
Uninitialized function pointer in freed memory is invoked
LDAP server mishandles malformed BER queries, leading to free of uninitialized memory
Firewall can crash with certain ICMP packets that trigger access of an uninitialized pointer.
LDAP server does not initialize members of structs, which leads to free of uninitialized pointer if an LDAP request fails.
+ Detection Methods

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive 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:

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

Terminology

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

Maintenance

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

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

Weakness ID: 767
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.
×

Edit Custom Filter


+ Description
The product defines a public method that reads or modifies a private variable.
+ Extended Description
If an attacker modifies the variable to contain unexpected values, this could violate assumptions from other parts of the code. Additionally, if an attacker can read the private variable, it may expose sensitive information or make it easier to launch further attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Java (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Modify Application Data; Other

+ Demonstrative Examples

Example 1

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

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

Example 2

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

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

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

+ Potential Mitigations

Phase: Implementation

Use class accessor and mutator methods appropriately. Perform validation when accepting data from a public method that is intended to modify a critical private variable. Also be sure that appropriate access controls are being applied when a public method interfaces with critical data.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1184SEI CERT Perl Coding Standard - Guidelines 06. Object-Oriented Programming (OOP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ 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

Maintenance

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

CWE-670: Always-Incorrect Control Flow Implementation

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

Edit Custom Filter


+ Description
The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.
+ Extended Description
This weakness captures cases in which a particular code segment is always incorrect with respect to the algorithm that it is implementing. For example, if a C programmer intends to include multiple statements in a single block but does not include the enclosing braces (CWE-483), then the logic is always incorrect. This issue is in contrast to most weaknesses in which the code usually behaves correctly, except when it is externally manipulated in malicious ways.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.480Use of Incorrect Operator
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.483Incorrect Block Delimitation
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.484Omitted Break Statement in Switch
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.617Reachable Assertion
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.698Execution After Redirect (EAR)
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.783Operator Precedence Logic Error
Section HelpThis 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.617Reachable Assertion
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
ImplementationThis issue typically appears in rarely-tested code, since the "always-incorrect" nature will be detected as a bug during normal usage.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Other

Technical Impact: Other; Alter Execution Logic

+ Demonstrative Examples

Example 1

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

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

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

Example 2

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

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

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

Example 3

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

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

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

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

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

Example 4

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

(bad code)
Example Language: Java 
String email = request.getParameter("email_address");
assert email != null;
+ Observed Examples
ReferenceDescription
virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

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

Reason: Abstraction

Rationale:

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

Comments:

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

Maintenance

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

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

Weakness ID: 1282
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.
×

Edit Custom Filter


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

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

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
CanPrecedeBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.471Modification of Assumed-Immutable Data (MAID)
Section HelpThis 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1202Memory and Storage Issues
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
ImplementationKeys, code, configuration settings, and other data should be programmed in write-once or read-only memory instead of writable memory.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

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

+ Potential Mitigations

Phase: Implementation

All immutable code or data should be programmed into ROM or write-once memory.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ 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

Maintenance

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

Maintenance

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

CWE-300: Channel Accessible by Non-Endpoint

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

Edit Custom Filter


+ Description
The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.
+ Extended Description
In order to establish secure communication between two parties, it is often important to adequately verify the identity of entities at each end of the communication channel. Inadequate or inconsistent verification may result in insufficient or incorrect identification of either communicating entity. This can have negative consequences such as misplaced trust in the entity at the other end of the channel. An attacker can leverage this by interposing between the communicating entities and masquerading as the original entity. In the absence of sufficient verification of identity, such an attacker can eavesdrop and potentially modify the communication between the original entities.
+ Alternate Terms
Adversary-in-the-Middle / AITM
Man-in-the-Middle / MITM
Person-in-the-Middle / PITM
Monkey-in-the-Middle
Monster-in-the-Middle
On-path attack
Interception attack
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.923Improper Restriction of Communication Channel to Intended Endpoints
PeerOfClassClass - 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.602Client-Side Enforcement of Server-Side Security
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.603Use of Client-Side Authentication
Section HelpThis 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 "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and DesignREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Application Data; Modify Application Data; Gain Privileges or Assume Identity

An attacker could pose as one of the entities and read or possibly modify the communication.
+ Demonstrative Examples

Example 1

In the Java snippet below, data is sent over an unencrypted channel to a remote server.

(bad code)
Example Language: Java 
Socket sock;
PrintWriter out;

try {
sock = new Socket(REMOTE_HOST, REMOTE_PORT);
out = new PrintWriter(echoSocket.getOutputStream(), true);

// Write data to remote host via socket output stream.
...
}

By eavesdropping on the communication channel or posing as the endpoint, an attacker would be able to read all of the transmitted data.

+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversry-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).
+ Potential Mitigations

Phase: Implementation

Always fully authenticate both ends of any communications channel.

Phase: Architecture and Design

Adhere to the principle of complete mediation.

Phase: Implementation

A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure.
+ 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
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Frequent Misuse

Rationale:

CWE-300 is commonly misused for vulnerabilities in which the prerequisites for exploitation require the adversary to be in a privileged "in-the-middle" position.

Comments:

Consider root-cause weaknesses that allow adversary-in-the-middle attacks to happen, such as CWEs involving poor integrity protection.
+ Notes

Maintenance

The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMan-in-the-middle (MITM)
WASC32Routing Detour
The CERT Oracle Secure Coding Standard for Java (2011)SEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
+ References
[REF-244] M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Alternate_Terms, Name, Observed_Examples, Related_Attack_Patterns, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Alternate_Terms, Related_Attack_Patterns
2021-07-20CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Man-in-the-middle (MITM)
2009-05-27Channel Accessible by Non-Endpoint (aka 'Man-in-the-Middle')
2020-02-24Channel Accessible by Non-Endpoint ('Man-in-the-Middle')

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
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.
×

Edit Custom Filter


+ Description
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+ Extended Description

Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data.

Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries.

When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.311Missing Encryption of Sensitive Data
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.5J2EE Misconfiguration: Data Transmission Without Encryption
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.614Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
Section HelpThis 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass - 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.311Missing Encryption of Sensitive Data
Section HelpThis 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 "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt Data
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and DesignFor hardware, this may be introduced when design does not plan for an attacker having physical access while a legitimate user is remotely operating the device.
Operation
System Configuration
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

Class: System on Chip (Undetermined Prevalence)

Test/Debug Hardware (Often Prevalent)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Read Application Data; Modify Files or Directories

Anyone can read the information by gaining access to the channel being used for communication.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code attempts to establish a connection to a site to communicate sensitive information.

(bad code)
Example Language: Java 
try {
URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();
}
catch (IOException e) {
//...
}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.

Example 2

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

Multiple vendors used cleartext transmission of sensitive information in their OT products.

Example 3

A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed.

Example 4

The following Azure CLI command lists the properties of a particular storage account:

(informative)
Example Language: Shell 
az storage account show -g {ResourceGroupName} -n {StorageAccountName}

The JSON result might be:

(bad code)
Example Language: JSON 
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"
}

The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.).

Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as:

(good code)
Example Language: Shell 
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true

The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true:

(good code)
Example Language: JSON 
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"
}

Note: to enable secure transfer using Azure's Portal instead of the command line:

  1. Open the Create storage account pane in the Azure portal.
  2. In the Advanced page, select the Enable secure transfer checkbox.

+ Observed Examples
ReferenceDescription
Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.
Building Controller uses a protocol that transmits authentication credentials in plaintext.
Programmable Logic Controller (PLC) sends password in plaintext.
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Potential Mitigations

Phase: Architecture and Design

Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.

Phase: Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Phase: Implementation

When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.

Phase: Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Phase: Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
+ Detection Methods

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.818OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ 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

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011)SEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
The CERT Oracle Secure Coding Standard for Java (2011)SER02-JSign then seal sensitive objects before sending them outside a trust boundary
Software Fault PatternsSFP23Exposed Data
ISA/IEC 62443Part 3-3Req SR 4.1
ISA/IEC 62443Part 4-2Req CR 4.1B
+ References
[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007. <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. URL validated: 2023-04-07.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.
[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Sections 3.1 and 3.10. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.
[REF-1309] Microsoft. "Require secure transfer to ensure secure connections". 2022-07-24. <https://learn.microsoft.com/en-us/azure/storage/common/storage-require-secure-transfer>. URL validated: 2023-01-24.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-01-24Accellera IP Security Assurance (IPSA) Working GroupAccellera Systems Initiative
Submitted original contents of CWE-1324 and reviewed its integration into this entry.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated References
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Relationships
2010-12-13CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-01-23CWE Content TeamMITRE
updated Abstraction
2018-03-27CWE Content TeamMITRE
updated References, Relationships, Type
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Description, Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Transmission of Sensitive Information

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

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

Edit Custom Filter


+ Description
The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
+ Extended Description

This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.

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

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

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

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

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

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.364Signal Handler Race Condition
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.366Race Condition within a Thread
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.367Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.368Context Switching Race Condition
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.421Race Condition During Access to Alternate Channel
ParentOfCompositeComposite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.689Permission Race Condition During Resource Copy
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1223Race Condition for Write-Once Attributes
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1298Hardware Logic Contains Race Conditions
CanFollowClassClass - 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.662Improper Synchronization
Section HelpThis 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.367Time-of-check Time-of-use (TOCTOU) Race Condition
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Java (Sometimes Prevalent)

Technologies

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Availability

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

When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion (CWE-400).
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Instability

When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
Confidentiality
Integrity

Technical Impact: Read Files or Directories; Read Application Data

When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

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

(bad code)
Example Language: Perl 
$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {
FatalError("Bad Transfer Amount");
}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
FatalError("Insufficient Funds");
}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

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

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

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

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

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

Example 2

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

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

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

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

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

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


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 3

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

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

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

Phase: Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Phase: Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Phase: Architecture and Design

Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.

Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

Phase: Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Phase: Implementation

Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.

Phase: Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Phase: Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Phase: Implementation

Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.

Phase: Implementation

Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
+ Detection Methods

Black Box

Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.

White Box

Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Race conditions may be detected with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior.

Insert breakpoints or delays in between relevant code statements to artificially expand the race window so that it will be easier to detect.

Effectiveness: Moderate

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
Cost effective for partial coverage:
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

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

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

Highly cost effective:
  • Framework-based Fuzzer
Cost effective for partial coverage:
  • Fuzz Tester
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: High

Manual Static Analysis - Source Code

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

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

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

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

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

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.882CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1376ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

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

Reason: Abstraction

Rationale:

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

Comments:

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

Research Gap

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

Research Gap

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

Research Gap

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

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRace Conditions
The CERT Oracle Secure Coding Standard for Java (2011)VNA03-JDo not assume that a group of calls to independently atomic methods is atomic
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <https://drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766>. URL validated: 2023-04-07.
[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <https://web.archive.org/web/20170609174845/http://www.javalobby.org/articles/thread-safe/index.jsp>. URL validated: 2023-04-07.
[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <https://www.ida.liu.se/~TDDC90/literature/papers/SP-race-conditions.pdf>. URL validated: 2023-04-07.
[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <https://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/ucd-ecs-95-08.pdf>. URL validated: 2023-04-07.
[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>. URL validated: 2023-04-07.
[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <https://www.blakewatts.com/blog/discovering-and-exploiting-named-pipe-security-flaws-for-fun-and-profit>. URL validated: 2023-04-07.
[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <https://web.archive.org/web/20081010155022/http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>. URL validated: 2023-04-07.
[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <https://web.archive.org/web/20100530231203/http://blogs.sans.org:80/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>. URL validated: 2023-04-07.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-1237] CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2010-04-30Martin SeborCisco Systems, Inc.
Provided Demonstrative Example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Observed_Examples, References
2022-04-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Race Conditions
2010-12-13Race Condition

CWE CATEGORY: Configuration

Category ID: 16
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are typically introduced during the configuration of the software.
+ Membership
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.933OWASP Top Ten 2013 Category A5 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1032OWASP Top Ten 2017 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
+ Vulnerability Mapping Notes

Usage: PROHIBITED

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

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves [REF-1287]. This CWE entry may have become widely-used because of NIST's usage in NVD from 2008 to 2016 (see CWE-635 view, updated to the CWE-1003 view in 2016). Mapping is also Prohibited because this entry's status is Obsolete.

Comments:

As of CWE 4.9, "Configuration" is beginning to be treated as an aspect of the SDLC in which a product is directed (by a human or automated process) to perform an insecure behavior. CWE mapping should be conducted by analyzing the weakness in the behavior that has been set by the configuration, such as those related to access control (descendants of CWE-284) or resource management (CWE-400), etc.
+ Notes

Maintenance

Further discussion about this category was held over the CWE Research mailing list in early 2020. No definitive action has been decided.

Maintenance

This entry is a Category, but various sources map to it anyway, despite CWE guidance that Categories should not be mapped. In this case, there are no clear CWE Weaknesses that can be utilized. "Inappropriate Configuration" sounds more like a Weakness in CWE's style, but it still does not indicate actual behavior of the product. Further research is still required, however, as a "configuration weakness" might be Primary to many other CWEs, i.e., it might be better described in terms of chaining relationships.
+ References
[REF-1287] MITRE. "Supplemental Details - 2022 CWE Top 25". Details of Problematic Mappings. 2022-06-28. <https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25_supplemental.html#problematicMappingDetails>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2017-11-08CWE Content TeamMITRE
updated Detection_Factors
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Maintenance_Notes, References
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-514: Covert Channel

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

Edit Custom Filter


+ Description
A covert channel is a path that can be used to transfer information in a way not intended by the system's designers.
+ Extended Description
Typically the system has not given authorization for the transmission and has no knowledge of its occurrence.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1229Creation of Emergent Resource
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.385Covert Timing Channel
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.515Covert Storage Channel
CanFollowBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.205Observable Behavioral Discrepancy
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Implementation
Operation
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

In this example, the attacker observes how long an authentication takes when the user types in the correct password.

When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.

(bad code)
Example Language: Python 
def validate_password(actual_pw, typed_pw):
if len(actual_pw) <> len(typed_pw):
return 0

for i in len(actual_pw):
if actual_pw[i] <> typed_pw[i]:
return 0

return 1

Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.

+ Detection Methods

Architecture or Design Review

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

Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: SOAR Partial

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.968SFP Secondary Cluster: Covert Channel
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
+ 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

Theoretical

A covert channel can be thought of as an emergent resource, meaning that it was not an originally intended resource, however it exists due the application's behaviors.

Maintenance

As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrCovert Channel
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes, Theoretical_Notes
2009-07-27CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITRE
updated Description, Relationships, Theoretical_Notes
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-515: Covert Storage Channel

Weakness ID: 515
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.
×

Edit Custom Filter


+ Description
A covert storage channel transfers information through the setting of bits by one program and the reading of those bits by another. What distinguishes this case from that of ordinary operation is that the bits are used to convey encoded information.
+ Extended Description
Covert storage channels occur when out-of-band data is stored in messages for the purpose of memory reuse. Covert channels are frequently classified as either storage or timing channels. Examples would include using a file intended to hold only audit information to convey user passwords--using the name of a file or perhaps status bits associated with it that can be read by all users to signal the contents of the file. Steganography, concealing information in such a manner that no one but the intended recipient knows of the existence of the message, is a good example of a covert storage channel.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.514Covert Channel
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Implementation
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Covert storage channels may provide attackers with important information about the system in question.
Integrity
Confidentiality

Technical Impact: Read Application Data

If these messages or packets are sent with unnecessary data contained within, it may tip off malicious listeners as to the process that created the message. With this information, attackers may learn any number of things, including the hardware platform, operating system, or algorithms used by the sender. This information can be of significant value to the user in launching further attacks.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

An excellent example of covert storage channels in a well known application is the ICMP error message echoing functionality. Due to ambiguities in the ICMP RFC, many IP implementations use the memory within the packet for storage or calculation. For this reason, certain fields of certain packets -- such as ICMP error packets which echo back parts of received messages -- may contain flaws or extra information which betrays information about the identity of the target operating system. This information is then used to build up evidence to decide the environment of the target. This is the first crucial step in determining if a given system is vulnerable to a particular flaw and what changes must be made to malicious code to mount a successful attack.

+ Potential Mitigations

Phase: Implementation

Ensure that all reserved fields are set to zero before messages are sent and that no unnecessary information is included.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.968SFP Secondary Cluster: Covert Channel
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
+ 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

Maintenance

As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrStorage
CLASPCovert storage channel
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Description
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-385: Covert Timing Channel

Weakness ID: 385
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.
×

Edit Custom Filter


+ Description
Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.
+ Extended Description

In some instances, knowing when data is transmitted between parties can provide a malicious user with privileged information. Also, externally monitoring the timing of operations can potentially reveal sensitive data. For example, a cryptographic operation can expose its internal state if the time it takes to perform the operation varies, based on the state.

Covert channels are frequently classified as either storage or timing channels. Some examples of covert timing channels are the system's paging rate, the time a certain transaction requires to execute, and the time it takes to gain access to a shared bus.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.514Covert Channel
CanFollowBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.208Observable Timing Discrepancy
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Other

Technical Impact: Read Application Data; Other

Information exposure.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

In this example, the attacker observes how long an authentication takes when the user types in the correct password.

When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.

(bad code)
Example Language: Python 
def validate_password(actual_pw, typed_pw):
if len(actual_pw) <> len(typed_pw):
return 0

for i in len(actual_pw):
if actual_pw[i] <> typed_pw[i]:
return 0

return 1

Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.

+ Potential Mitigations

Phase: Architecture and Design

Whenever possible, specify implementation strategies that do not introduce time variances in operations.

Phase: Implementation

Often one can artificially manipulate the time which operations take or -- when operations occur -- can remove information from the attacker.

Phase: Implementation

It is reasonable to add artificial or random delays so that the amount of CPU time consumed is independent of the action being taken by the application.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.968SFP Secondary Cluster: Covert Channel
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
+ 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

Maintenance

As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrTiming
CLASPCovert Timing Channel
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Common_Consequences, Description
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2022-10-13CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-502: Deserialization of Untrusted Data

Weakness ID: 502
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.
×

Edit Custom Filter


+ Description
The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
+ Extended Description

It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is a dangerous security assumption.

Data that is untrusted can not be trusted to be well-formed.

When developers place no restrictions on "gadget chains," or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell.

+ Alternate Terms
Marshaling, Unmarshaling:
Marshaling and unmarshaling are effectively synonyms for serialization and deserialization, respectively.
Pickling, Unpickling:
In Python, the "pickle" functionality is used to perform serialization and deserialization.
PHP Object Injection:
Some PHP application researchers use this term when attacking unsafe use of the unserialize() function; but it is also used for CWE-915.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.913Improper Control of Dynamically-Managed Code Resources
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.915Improperly Controlled Modification of Dynamically-Determined Object Attributes
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
Section HelpThis 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass - 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.913Improper Control of Dynamically-Managed Code Resources
Section HelpThis 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 "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
+ Background Details
Serialization and deserialization refer to the process of taking program-internal object-related data, packaging it in a way that allows the data to be externally stored or transferred ("serialization"), then extracting the serialized data to reconstruct the original object ("deserialization").
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Java (Undetermined Prevalence)

Ruby (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Python (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data; Unexpected State

Attackers can modify unexpected objects or data that was assumed to be safe from modification.
Availability

Technical Impact: DoS: Resource Consumption (CPU)

If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.
Other

Technical Impact: Varies by Context

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code snippet deserializes an object from a file and uses it as a UI button:

(bad code)
Example Language: Java 
try {
File file = new File("object.obj");
ObjectInputStream in = new ObjectInputStream(new FileInputStream(file));
javax.swing.JButton button = (javax.swing.JButton) in.readObject();
in.close();
}

This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed.

To mitigate this, explicitly define final readObject() to prevent deserialization. An example of this is:

(good code)
Example Language: Java 
private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized"); }

Example 2

In Python, the Pickle library handles the serialization and deserialization processes. In this example derived from [REF-467], the code receives and parses data, and afterwards tries to authenticate a user based on validating a token.

(bad code)
Example Language: Python 
try {
class ExampleProtocol(protocol.Protocol):
def dataReceived(self, data):

# Code that would be here would parse the incoming data
# After receiving headers, call confirmAuth() to authenticate

def confirmAuth(self, headers):
try:
token = cPickle.loads(base64.b64decode(headers['AuthToken']))
if not check_hmac(token['signature'], token['data'], getSecretKey()):
raise AuthFail
self.secure_data = token['data']
except:
raise AuthFail
}

Unfortunately, the code does not verify that the incoming data is legitimate. An attacker can construct a illegitimate, serialized object "AuthToken" that instantiates one of Python's subprocesses to execute arbitrary commands. For instance,the attacker could construct a pickle that leverages Python's subprocess module, which spawns new processes and includes a number of arguments for various uses. Since Pickle allows objects to define the process for how they should be unpickled, the attacker can direct the unpickle process to call Popen in the subprocess module and execute /bin/sh.

+ Observed Examples
ReferenceDescription
chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183)
Deserialization issue in commonly-used Java library allows remote execution.
Deserialization issue in commonly-used Java library allows remote execution.
Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
Use of PHP unserialize function on untrusted input in content management system might allow code execution.
Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
Python script allows local users to execute code via pickled data.
Unsafe deserialization using pickle in a Python script.
Web browser allows execution of native methods via a crafted string to a JavaScript function that deserializes the string.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.

Phase: Implementation

When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Phase: Implementation

Explicitly define a final object() to prevent deserialization.

Phases: Architecture and Design; Implementation

Make fields transient to protect them from deserialization.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

Phase: Implementation

Avoid having unnecessary types or gadgets available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
+ 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
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1034OWASP Top Ten 2017 Category A8 - Insecure Deserialization
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1354OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ 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

Maintenance

The relationships between CWE-502 and CWE-915 need further exploration. CWE-915 is more narrowly scoped to object modification, and is not necessarily used for deserialization.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDeserialization of untrusted data
The CERT Oracle Secure Coding Standard for Java (2011)SER01-JDo not deviate from the proper signatures of serialization methods
The CERT Oracle Secure Coding Standard for Java (2011)SER03-JDo not serialize unencrypted, sensitive data
The CERT Oracle Secure Coding Standard for Java (2011)SER06-JMake defensive copies of private mutable components during deserialization
The CERT Oracle Secure Coding Standard for Java (2011)SER08-JDo not use the default serialized form for implementation defined invariants
Software Fault PatternsSFP25Tainted input to variable
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-461] Matthias Kaiser. "Exploiting Deserialization Vulnerabilities in Java". 2015-10-28. <https://www.slideshare.net/codewhitesec/exploiting-deserialization-vulnerabilities-in-java-54707478>. URL validated: 2023-04-07.
[REF-462] Sam Thomas. "PHP unserialization vulnerabilities: What are we missing?". 2015-08-27. <https://www.slideshare.net/_s_n_t/php-unserialization-vulnerabilities-what-are-we-missing>. URL validated: 2023-04-07.
[REF-463] Gabriel Lawrence and Chris Frohoff. "Marshalling Pickles: How deserializing objects can ruin your day". 2015-01-28. <https://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles>. URL validated: 2023-04-07.
[REF-464] Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <https://drupalsun.com/heine/2010/08/25/unserializing-user-supplied-data-bad-idea>. URL validated: 2023-04-07.
[REF-465] Manish S. Saindane. "Black Hat EU 2010 - Attacking Java Serialized Communication". 2010-04-26. <https://www.slideshare.net/msaindane/black-hat-eu-2010-attacking-java-serialized-communication>. URL validated: 2023-04-07.
[REF-466] Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://michael-rushanan.blogspot.com/2012/10/why-python-pickle-is-insecure.html>. URL validated: 2023-04-07.
[REF-467] Nelson Elhage. "Exploiting misuse of Python's "pickle"". 2011-03-20. <https://blog.nelhage.com/2011/03/exploiting-pickle/>.
[REF-468] Chris Frohoff. "Deserialize My Shorts: Or How I Learned to Start Worrying and Hate Java Object Deserialization". 2016-03-21. <https://speakerdeck.com/frohoff/owasp-sd-deserialize-my-shorts-or-how-i-learned-to-start-worrying-and-hate-java-object-deserialization>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2017-05-03CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Modes_of_Introduction, Potential_Mitigations, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2020-06-25CWE Content TeamMITRE
updated Alternate_Terms, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships

CWE-1273: Device Unlock Credential Sharing

Weakness ID: 1273
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.
×

Edit Custom Filter


+ Description
The credentials necessary for unlocking a device are shared across multiple parties and may expose sensitive information.
+ Extended Description

"Unlocking a device" often means activating certain unadvertised debug and manufacturer-specific capabilities of a device using sensitive credentials. Unlocking a device might be necessary for the purpose of troubleshooting device problems. For example, suppose a device contains the ability to dump the content of the full system memory by disabling the memory-protection mechanisms. Since this is a highly security-sensitive capability, this capability is "locked" in the production part. Unless the device gets unlocked by supplying the proper credentials, the debug capabilities are not available. For cases where the chip designer, chip manufacturer (fabricator), and manufacturing and assembly testers are all employed by the same company, the risk of compromise of the credentials is greatly reduced. However, the risk is greater when the chip designer is employed by one company, the chip manufacturer is employed by another company (a foundry), and the assemblers and testers are employed by yet a third company. Since these different companies will need to perform various tests on the device to verify correct device function, they all need to share the unlock key. Unfortunately, the level of secrecy and policy might be quite different at each company, greatly increasing the risk of sensitive credentials being compromised.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
Section HelpThis 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1195Manufacturing and Life Cycle Management Concerns
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Integration
Manufacturing
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

VHDL (Undetermined Prevalence)

Verilog (Undetermined Prevalence)

Class: Compiled (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Other (Undetermined Prevalence)

Class: Not Technology-Specific (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Modify Memory; Read Memory; Modify Files or Directories; Read Files or Directories; Modify Application Data; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism

Once unlock credentials are compromised, an attacker can use the credentials to unlock the device and gain unauthorized access to the hidden functionalities protected by those credentials.
+ Demonstrative Examples

Example 1

This example shows how an attacker can take advantage of compromised credentials.

(bad code)
 
Suppose a semiconductor chipmaker, "C", uses the foundry "F" for fabricating its chips. Now, F has many other customers in addition to C, and some of the other customers are much smaller companies. F has dedicated teams for each of its customers, but somehow it mixes up the unlock credentials and sends the unlock credentials of C to the wrong team. This other team does not take adequate precautions to protect the credentials that have nothing to do with them, and eventually the unlock credentials of C get leaked.

When the credentials of multiple organizations are stored together, exposure to third parties occurs frequently.

(good code)
 
Vertical integration of a production company is one effective method of protecting sensitive credentials. Where vertical integration is not possible, strict access control and need-to-know are methods which can be implemented to reduce these risks.
+ Potential Mitigations

Phase: Integration

Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.

Phase: Manufacturing

Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ 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

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-29
(CWE 4.1, 2020-02-24)
Parbati Kumar Manna, Hareesh Khattri, Arun KanuparthiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2022-10-13CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-172: Encoding Error

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

Edit Custom Filter


+ Description
The product does not properly encode or decode the data, resulting in unexpected values.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.173Improper Handling of Alternate Encoding
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.174Double Decoding of the Same Data
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.175Improper Handling of Mixed Encoding
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.176Improper Handling of Unicode Encoding
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.177Improper Handling of URL Encoding (Hex Encoding)
CanPrecedeBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CanPrecedeBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.41Improper Resolution of Path Equivalence
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Forum software improperly URL decodes the highlight parameter when extracting text to highlight, which allows remote attackers to execute arbitrary PHP code by double-encoding the highlight value so that special characters are inserted into the result.
XSS protection mechanism attempts to remove "/" that could be used to close tags, but it can be bypassed using double encoded slashes (%252F)
Server allows a remote attacker to obtain source code of ASP files via a URL encoded with Unicode.
Hex-encoded path traversal variants - "%2e%2e", "%2e%2e%2f", "%5c%2e%2e"
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Implementation

Strategy: Output Encoding

While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

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

Reason: Abstraction

Rationale:

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

Comments:

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

Relationship

Partially overlaps path traversal and equivalence weaknesses.

Maintenance

This is more like a category than a weakness.

Maintenance

Many other types of encodings should be listed in this category.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEREncoding Error
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Description
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-250: Execution with Unnecessary Privileges

Weakness ID: 250
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.
×

Edit Custom Filter


+ Description
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
+ Extended Description

New weaknesses can be exposed because running with extra privileges, such as root or Administrator, can disable the normal security checks being performed by the operating system or surrounding environment. Other pre-existing weaknesses can turn into security vulnerabilities if they occur while operating at raised privileges.

Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.657Violation of Secure Design Principles
ChildOfClassClass - 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.269Improper Privilege Management
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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 "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit Access
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Implementation

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

Installation
Architecture and Design

If an application has this design problem, then it can be easier for the developer to make implementation-related errors such as CWE-271 (Privilege Dropping / Lowering Errors). In addition, the consequences of Privilege Chaining (CWE-268) can become more severe.

Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands; Read Application Data; DoS: Crash, Exit, or Restart

An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code temporarily raises the program's privileges to allow creation of a new user folder.

(bad code)
Example Language: Python 
def makeNewUserDir(username):
if invalidUsername(username):

#avoid CWE-22 and CWE-78
print('Usernames cannot contain invalid characters')
return False

try:
raisePrivileges()
os.mkdir('/home/' + username)
lowerPrivileges()

except OSError:
print('Unable to create new user directory for user:' + username)
return False

return True

While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.

Example 2

The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file.

(bad code)
Example Language:
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...

Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced.

Example 3

This application intends to use a user's location to determine the timezone the user is in:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
setTimeZone(userCurrLocation);

This is unnecessary use of the location API, as this information is already available using the Android Time API. Always be sure there is not another way to obtain needed information before resorting to using the location API.

Example 4

This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(bad code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.

+ Observed Examples
ReferenceDescription
FTP client program on a certain OS runs with setuid privileges and has a buffer overflow. Most clients do not need extra privileges, so an overflow is not a vulnerability for those clients.
Program runs with privileges and calls another program with the same privileges, which allows read of arbitrary files.
OS incorrectly installs a program with setuid privileges, allowing users to gain privileges.
Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
Program does not drop privileges before calling another program, allowing code execution.
setuid root program allows creation of arbitrary files through command line argument.
Installation script installs some programs as setuid when they shouldn't be.
mail program runs as root but does not drop its privileges before attempting to access a file. Attacker can use a symlink from their home directory to a directory only readable by root, then determine whether the file exists based on the response.
Product launches Help functionality while running with raised privileges, allowing command execution using Windows message to access "open file" dialog.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Architecture and Design

Strategy: Separation of Privilege

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Phase: Architecture and Design

Strategy: Attack Surface Reduction

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Phase: Implementation

Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements.

Phase: Implementation

When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed.

Phase: Implementation

If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else [REF-76]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place.

Phases: Operation; System Configuration

Strategy: Environment Hardening

Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
+ Detection Methods

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process and perform a login. Look for library functions and system calls that indicate when privileges are being raised or dropped. Look for accesses of resources that are restricted to normal users.

Note: Note that this technique is only useful for privilege issues related to system resources. It is not likely to detect application-level business rules that are related to privileges, such as if a blog system allows a user to delete a blog entry without first checking that the user has administrator privileges.

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:
  • Compare binary / bytecode to application permission manifest
Cost effective for partial coverage:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

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

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

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

Cost effective for partial coverage:
  • Host-based Vulnerability Scanners - Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:
  • Host Application Interface Scanner

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

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

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

Cost effective for partial coverage:
  • Configuration Checker
  • Permission Manifest Analysis

Effectiveness: SOAR Partial

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

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7532009 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8662011 Top 25 - Porous Defenses
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ 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

Relationship

There is a close association with CWE-653 (Insufficient Separation of Privileges). CWE-653 is about providing separate components for each privilege; CWE-250 is about ensuring that each component has the least amount of privileges possible.

Maintenance

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category. Both CWE-272 and CWE-250 are in active use by the community. The "least privilege" phrase has multiple interpretations.

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOften Misused: Privilege Management
The CERT Oracle Secure Coding Standard for Java (2011)SER09-JMinimize privileges before deserializing from a privilege context
ISA/IEC 62443Part 2-4Req SP.03.05 BR
ISA/IEC 62443Part 2-4Req SP.03.08 BR
ISA/IEC 62443Part 2-4Req SP.03.08 RE(1)
ISA/IEC 62443Part 2-4Req SP.05.07 BR
ISA/IEC 62443Part 2-4Req SP.09.02 RE(4)
ISA/IEC 62443Part 2-4Req SP.09.03 BR
ISA/IEC 62443Part 2-4Req SP.09.04 BR
ISA/IEC 62443Part 3-3Req SR 1.1
ISA/IEC 62443Part 3-3Req SR 1.2
ISA/IEC 62443Part 3-3Req SR 2.1
ISA/IEC 62443Part 3-3Req SR 2.1 RE 1
ISA/IEC 62443Part 4-1Req SD-4
ISA/IEC 62443Part 4-2Req CCSC 3
ISA/IEC 62443Part 4-2Req CR 1.1
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
[REF-196] Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. 1975-09. <http://web.mit.edu/Saltzer/www/publications/protection/>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 7, "Running with Least Privilege" Page 207. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-199] NIST. "United States Government Configuration Baseline (USGCB)". <https://csrc.nist.gov/Projects/United-States-Government-Configuration-Baseline>. URL validated: 2023-03-28.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 16: Executing Code With Too Much Privilege." Page 243. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Privilege Vulnerabilities", Page 477. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution DateContributorOrganization
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Maintenance_Notes
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Maintenance_Notes, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Detection_Factors
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References, Relationships, Type
2022-04-28CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description, Maintenance_Notes, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Often Misused: Privilege Management
2009-01-12Design Principle Violation: Failure to Use Least Privilege

CWE-825: Expired Pointer Dereference

Weakness ID: 825
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.
×

Edit Custom Filter


+ Description
The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.
+ Extended Description
When a product releases memory, but it maintains a pointer to that memory, then the memory might be re-allocated at a later time. If the original pointer is accessed to read or write data, then this could cause the product to read or modify data that is in use by a different function or process. Depending on how the newly-allocated memory is used, this could lead to a denial of service, information exposure, or code execution.
+ Alternate Terms
Dangling pointer
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.415Double Free
ParentOfVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.416Use After Free
CanFollowBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.562Return of Stack Variable Address
CanPrecedeBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.125Out-of-bounds Read
CanPrecedeBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.787Out-of-bounds Write
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
Section HelpThis 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 "CISQ Quality Measures (2020)" (CWE-1305)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "CISQ Data Protection Measures" (CWE-1340)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

If the expired pointer is used in a read operation, an attacker might be able to control data read in by the application.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

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

Technical Impact: Execute Unauthorized Code or Commands

If the expired pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.
+ Demonstrative Examples

Example 1

The following code shows a simple example of a use after free error:

(bad code)
Example Language:
char* ptr = (char*)malloc (SIZE);
if (err) {
abrt = 1;
free(ptr);
}
...
if (abrt) {
logError("operation aborted before commit", ptr);
}

When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

Example 2

The following code shows a simple example of a double free error:

(bad code)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances
  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

+ Observed Examples
ReferenceDescription
access of expired memory address leads to arbitrary code execution
stale pointer issue leads to denial of service and possibly other consequences
Chain: a message having an unknown message type may cause a reference to uninitialized memory resulting in a null pointer dereference (CWE-476) or dangling pointer (CWE-825), possibly crashing the system or causing heap corruption.
read of value at an offset into a structure after the offset is no longer valid
+ Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive 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:

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

Terminology

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

Maintenance

There are close relationships between incorrect pointer dereferences and other weaknesses related to buffer operations. There may not be sufficient community agreement regarding these relationships. Further study is needed to determine when these relationships are chains, composites, perspective/layering, or other types of relationships. As of September 2010, most of the relationships are being captured as chains.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2010-09-22
(CWE 1.10, 2010-09-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-06-27CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Observed_Examples
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

Weakness ID: 359
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.
×

Edit Custom Filter


+ Description
The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.
+ Extended Description

There are many types of sensitive information that products must protect from attackers, including system data, communications, configuration, business secrets, intellectual property, and an individual's personal (private) information. Private personal information may include a password, phone number, geographic location, personal messages, credit card number, etc. Private information is important to consider whether the person is a user of the product, or part of a data set that is processed by the product. An exposure of private information does not necessarily prevent the product from working properly, and in fact the exposure might be intended by the developer, e.g. as part of data sharing with other organizations. However, the exposure of personal private information can still be undesirable or explicitly prohibited by law or regulation.

Some types of private information include:

  • Government identifiers, such as Social Security Numbers
  • Contact information, such as home addresses and telephone numbers
  • Geographic location - where the user is (or was)
  • Employment history
  • Financial data - such as credit card numbers, salary, bank accounts, and debts
  • Pictures, video, or audio
  • Behavioral patterns - such as web surfing history, when certain activities are performed, etc.
  • Relationships (and types of relationships) with others - family, friends, contacts, etc.
  • Communications - e-mail addresses, private messages, text messages, chat logs, etc.
  • Health - medical conditions, insurance status, prescription records
  • Account passwords and other credentials

Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

+ Alternate Terms
Privacy violation
Privacy leak
Privacy leakage
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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 "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

(bad code)
Example Language: C# 
pass = GetPassword();
...
dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp);

The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Example 2

This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(bad code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.

Example 3

In 2004, an employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [REF-338]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated.

+ Potential Mitigations

Phase: Requirements

Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.

Phase: Architecture and Design

Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.

+ Detection Methods

Architecture or Design Review

Private personal data can enter a program in a variety of ways:

  • Directly from the user in the form of a password or personal information
  • Accessed from a database or other data store by the application
  • Indirectly from a partner or other third party

If the data is written to an external location - such as the console, file system, or network - a privacy violation may occur.

Effectiveness: High

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ 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

Maintenance

This entry overlaps many other entries that are not organized around the kind of sensitive information that is exposed. However, because privacy is treated with such importance due to regulations and other factors, and it may be useful for weakness-finding tools to highlight capabilities that detect personal private information instead of system information, it is not clear whether - and how - this entry should be deprecated.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsPrivacy Violation
The CERT Oracle Secure Coding Standard for Java (2011)FIO13-JDo not log sensitive information outside a trust boundary
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
[REF-338] J. Oates. "AOL man pleads guilty to selling 92m email addies". The Register. 2005. <https://www.theregister.com/2005/02/07/aol_email_theft/>. URL validated: 2023-04-07.
[REF-339] NIST. "Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122)". 2010-04. <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf>. URL validated: 2023-04-07.
[REF-340] U.S. Department of Commerce. "Safe Harbor Privacy Framework". <https://web.archive.org/web/20010223203241/http://www.export.gov/safeharbor/>. URL validated: 2023-04-07.
[REF-341] Federal Trade Commission. "Financial Privacy: The Gramm-Leach Bliley Act (GLBA)". <https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act>. URL validated: 2023-04-07.
[REF-342] U.S. Department of Human Services. "Health Insurance Portability and Accountability Act (HIPAA)". <https://www.hhs.gov/hipaa/index.html>. URL validated: 2023-04-07.
[REF-343] Government of the State of California. "California SB-1386". 2002. <http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html>.
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. URL validated: 2023-04-07.
[REF-1047] Wikipedia. "General Data Protection Regulation". <https://en.wikipedia.org/wiki/General_Data_Protection_Regulation>.
[REF-1048] State of California Department of Justice, Office of the Attorney General. "California Consumer Privacy Act (CCPA)". <https://oag.ca.gov/privacy/ccpa>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Other_Notes
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Other_Notes, References
2010-02-16CWE Content TeamMITRE
updated Other_Notes, References
2011-03-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Other_Notes, References
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2014-02-18CWE Content TeamMITRE
updated Alternate_Terms, Demonstrative_Examples, Description, Name, Other_Notes, References
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Potential_Mitigations, References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-02-18Privacy Violation
2020-02-24Exposure of Private Information ('Privacy Violation')

CWE-213: Exposure of Sensitive Information Due to Incompatible Policies

Weakness ID: 213
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.
×

Edit Custom Filter


+ Description
The product's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.
+ Extended Description

When handling information, the developer must consider whether the information is regarded as sensitive by different stakeholders, such as users or administrators. Each stakeholder effectively has its own intended security policy that the product is expected to uphold. When a developer does not treat that information as sensitive, this can introduce a vulnerability that violates the expectations of the product's users.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
Section HelpThis 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
PolicyThis can occur when the product's policy does not account for all relevant stakeholders, or when the policies of other stakeholders are not interpreted properly.
RequirementsThis can occur when requirements do not explicitly account for all relevant stakeholders.
Architecture and DesignCommunications or data exchange frameworks may be chosen that exchange or provide access to more information than strictly needed.
ImplementationThis can occur when the developer does not properly track the flow of sensitive information and how it is exposed, e.g., via an API.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

This code displays some information on a web page.

(bad code)
Example Language: JSP 
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>

The code displays a user's credit card and social security numbers, even though they aren't absolutely necessary.

+ Observed Examples
ReferenceDescription
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Product lists DLLs and full pathnames.
Telnet protocol allows servers to obtain sensitive environment information from clients.
Telnet protocol allows servers to obtain sensitive environment information from clients.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ 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

Theoretical

In vulnerability theory terms, this covers cases in which the developer's Intended Policy allows the information to be made available, but the information might be in violation of a Universal Policy in which the product's administrator should have control over which information is considered sensitive and therefore should not be exposed.

Maintenance

This entry is being considered for deprecation. It overlaps many other entries related to information exposures. It might not be essential to preserve this entry, since other key stakeholder policies are covered elsewhere, e.g. personal privacy leaks (CWE-359) and system-level exposures that are important to system administrators (CWE-497).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERIntended information leak
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes, Theoretical_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Name, Other_Notes, Relationship_Notes, Relationships, Time_of_Introduction
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Intended Information Leak
2020-02-24Intentional Information Exposure

CWE-202: Exposure of Sensitive Information Through Data Queries

Weakness ID: 202
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.
×

Edit Custom Filter


+ Description
When trying to keep information confidential, an attacker can often infer some of the information by using statistics.
+ Extended Description
In situations where data should not be tied to individual users, but a large number of users should be able to make queries that "scrub" the identity of users, it may be possible to get information about a user -- e.g., by specifying search terms that are known to be unique to that user.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1230Exposure of Sensitive Information Through Metadata
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories; Read Application Data

Sensitive information may possibly be leaked through data queries accidentally.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

See the book Translucent Databases for examples.

+ Observed Examples
ReferenceDescription
Wiki product allows an adversary to discover filenames via a series of queries starting with one letter and then iteratively extending the match.
+ Potential Mitigations

Phase: Architecture and Design

This is a complex topic. See the book Translucent Databases for a good discussion of best practices.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ 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

Maintenance

The relationship between CWE-202 and CWE-612 needs to be investigated more closely, as they may be different descriptions of the same kind of problem. CWE-202 is also being considered for deprecation, as it is not clearly described and may have been misunderstood by CWE users. It could be argued that this issue is better covered by CAPEC; an attacker can utilize their data-query privileges to perform this kind of operation, and if the attacker should not be allowed to perform the operation - or if the sensitive data should not have been made accessible at all - then that is more appropriately classified as a separate CWE related to authorization (see the parent, CWE-1230).

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPAccidental leaking of sensitive information through data queries
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Maintenance_Notes, Name, References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Information Leak Through Data Queries
2011-03-29Privacy Leak through Data Queries
2020-02-24Exposure of Sensitive Data Through Data Queries

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

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

Edit Custom Filter


+ Description
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
+ Extended Description

There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:

  • private, personal information, such as personal messages, financial data, health records, geographic location, or contact details
  • system status and environment, such as the operating system and installed packages
  • business secrets and intellectual property
  • network status and configuration
  • the product's own code or internal state
  • metadata, e.g. logging of connections or message headers
  • indirect information, such as a discrepancy between two internal operations that can be observed by an outsider

Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:

  • the product's own users
  • people or organizations whose information is created or used by the product, even if they are not direct product users
  • the product's administrators, including the admins of the system(s) and/or networks on which the product operates
  • the developer

Information exposures can occur in different ways:

  • the code explicitly inserts sensitive information into resources or messages that are intentionally made accessible to unauthorized actors, but should not contain the information - i.e., the information should have been "scrubbed" or "sanitized"
  • a different weakness or mistake indirectly inserts the sensitive information into resources, such as a web script error revealing the full system path of the program.
  • the code manages resources that intentionally contain sensitive information, but the resources are unintentionally made accessible to unauthorized actors. In this case, the information exposure is resultant - i.e., a different weakness enabled the access to the information in the first place.

It is common practice to describe any loss of confidentiality as an "information exposure," but this can lead to overuse of CWE-200 in CWE mapping. From the CWE perspective, loss of confidentiality is a technical impact that can arise from dozens of different weaknesses, such as insecure file permissions or out-of-bounds read. CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information.

+ Alternate Terms
Information Disclosure:
This term is frequently used in vulnerability advisories to describe a consequence or technical impact, for any vulnerability that has a loss of confidentiality. Often, CWE-200 can be misused to represent the loss of confidentiality, even when the mistake - i.e., the weakness - is not directly related to the mishandling of the information itself, such as an out-of-bounds read that accesses sensitive memory contents; here, the out-of-bounds read is the primary weakness, not the disclosure of the memory. In addition, this phrase is also used frequently in policies and legal documents, but it does not refer to any disclosure of security-relevant information.
Information Leak:
This is a frequently used term, however the "leak" term has multiple uses within security. In some cases it deals with the accidental exposure of information from a different weakness, but in other cases (such as "memory leak"), this deals with improper tracking of resources, which can lead to exhaustion. As a result, CWE is actively avoiding usage of the "leak" term.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.201Insertion of Sensitive Information Into Sent Data
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.203Observable Discrepancy
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.209Generation of Error Message Containing Sensitive Information
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.213Exposure of Sensitive Information Due to Incompatible Policies
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.215Insertion of Sensitive Information Into Debugging Code
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.359Exposure of Private Personal Information to an Unauthorized Actor
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.497Exposure of Sensitive System Information to an Unauthorized Control Sphere
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.538Insertion of Sensitive Information into Externally-Accessible File or Directory
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1258Exposure of Sensitive System Information Due to Uncleared Debug Information
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1273Device Unlock Credential Sharing
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1295Debug Messages Revealing Unnecessary Information
CanFollowVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.498Cloneable Class Containing Sensitive Information
CanFollowVariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.499Serializable Class Containing Sensitive Data
CanFollowBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1272Sensitive Information Uncleared Before Debug/Power State Transition
Section HelpThis 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.203Observable Discrepancy
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.209Generation of Error Message Containing Sensitive Information
ParentOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.532Insertion of Sensitive Information into Log File
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and Design
Implementation<