CWE - VIEW SLICE: CWE-1194: Hardware Design (5.0)

CWE VIEW: Hardware Design

View ID: 1194

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

Downloads: Booklet | CSV | XML | Markdown

Objective

This view organizes weaknesses around concepts that are frequently used or encountered in hardware design. Accordingly, this view can align closely with the perspectives of designers, manufacturers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and mapping.

Audience

Stakeholder	Description
Hardware Designers	Hardware Designers use this view to better understand potential mistakes that can be made in specific areas of their IP design. The use of concepts with which hardware designers are familiar makes it easier to navigate.
Educators	Educators use this view to teach future professionals about the types of mistakes that are commonly made in hardware design.

Relationships

div.collapseblock { display:inline }

The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.

Show Details:

Expand All | Collapse All | Filter View

1194 - Hardware Design

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Manufacturing and Life Cycle Management Concerns - (1195)

1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns)

Weaknesses in this category are root-caused to defects that arise in the semiconductor-manufacturing process or during the life cycle and supply chain.

Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Insufficient Technical Documentation - (1059)

1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1059 (Insufficient Technical Documentation)

The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all of the relevant software/hardware elements of the product.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Semiconductor Defects in Hardware Logic with Security-Sensitive Implications - (1248)

1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1248 (Semiconductor Defects in Hardware Logic with Security-Sensitive Implications)

The security-sensitive hardware module contains semiconductor defects.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Scrubbing of Sensitive Data from Decommissioned Device - (1266)

1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1266 (Improper Scrubbing of Sensitive Data from Decommissioned Device)

The product does not properly provide a capability for the product administrator to remove sensitive data at the time the product is decommissioned. A scrubbing capability could be missing, insufficient, or incorrect.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Product Released in Non-Release Configuration - (1269)

1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1269 (Product Released in Non-Release Configuration)

The product released to market is released in pre-production or manufacturing configuration.

1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1273 (Device Unlock Credential Sharing)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unprotected Confidential Information on Device is Accessible by OSAT Vendors - (1297)

1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1297 (Unprotected Confidential Information on Device is Accessible by OSAT Vendors)

The product does not adequately protect confidential information on the device from being accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Security Flow Issues - (1196)

1194 (Hardware Design) > 1196 (Security Flow Issues)

Weaknesses in this category are related to improper design of full-system security flows, including but not limited to secure boot, secure update, and hardware-device attestation.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. DMA Device Enabled Too Early in Boot Phase - (1190)

1194 (Hardware Design) > 1196 (Security Flow Issues) > 1190 (DMA Device Enabled Too Early in Boot Phase)

The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Power-On of Untrusted Execution Core Before Enabling Fabric Access Control - (1193)

1194 (Hardware Design) > 1196 (Security Flow Issues) > 1193 (Power-On of Untrusted Execution Core Before Enabling Fabric Access Control)

The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Hardware Logic with Insecure De-Synchronization between Control and Data Channels - (1264)

1194 (Hardware Design) > 1196 (Security Flow Issues) > 1264 (Hardware Logic with Insecure De-Synchronization between Control and Data Channels)

The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Access Control for Volatile Memory Containing Boot Code - (1274)

1194 (Hardware Design) > 1196 (Security Flow Issues) > 1274 (Improper Access Control for Volatile Memory Containing Boot Code)

The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Mutable Attestation or Measurement Reporting Data - (1283)

1194 (Hardware Design) > 1196 (Security Flow Issues) > 1283 (Mutable Attestation or Measurement Reporting Data)

The register contents used for attestation or measurement reporting data to verify boot flow are modifiable by an adversary.

1194 (Hardware Design) > 1196 (Security Flow Issues) > 1310 (Missing Ability to Patch ROM Code)

Missing an ability to patch ROM code may leave a System or System-on-Chip (SoC) in a vulnerable state.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Immutable Root of Trust in Hardware - (1326)

1194 (Hardware Design) > 1196 (Security Flow Issues) > 1326 (Missing Immutable Root of Trust in Hardware)

A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Security Version Number Mutable to Older Versions - (1328)

1194 (Hardware Design) > 1196 (Security Flow Issues) > 1328 (Security Version Number Mutable to Older Versions)

The security version number in the hardware product is mutable, resulting in the ability to downgrade (roll-back) the boot firmware to vulnerable code versions.

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Integration Issues - (1197)

1194 (Hardware Design) > 1197 (Integration Issues)

Weaknesses in this category are those that arise due to integration of multiple hardware Intellectual Property (IP) cores, from System-on-a-Chip (SoC) subsystem interactions, or from hardware platform subsystem interactions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Hardware Child Block Incorrectly Connected to Parent System - (1276)

1194 (Hardware Design) > 1197 (Integration Issues) > 1276 (Hardware Child Block Incorrectly Connected to Parent System)

Signals between a hardware IP and the parent system design are incorrectly connected.

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Privilege Separation and Access Control Issues - (1198)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues)

Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of sensitive shared hardware resources such as registers and fuses.

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 276 (Incorrect Default Permissions)

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

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 441 (Unintended Proxy or Intermediary)

The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. Confused Deputy

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Isolation of Shared Resources on System-on-a-Chip (SoC) - (1189)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1189 (Improper Isolation of Shared Resources on System-on-a-Chip (SoC))

The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Identifier for IP Block used in System-On-Chip (SOC) - (1192)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1192 (Improper Identifier for IP Block used in System-On-Chip (SOC))

The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insufficient Granularity of Access Control - (1220)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1220 (Insufficient Granularity of Access Control)

The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack the required granularity

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Insufficient Granularity of Address Regions Protected by Register Locks - (1222)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1222 (Insufficient Granularity of Address Regions Protected by Register Locks)

The product defines a large address region protected from modification by the same register lock control bit. This results in a conflict between the functional requirement that some addresses need to be writable by software during operation and the security requirement that the system configuration lock bit must be set during the boot process.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Inclusion of Undocumented Features or Chicken Bits - (1242)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1242 (Inclusion of Undocumented Features or Chicken Bits)

The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Restriction of Security Token Assignment - (1259)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1259 (Improper Restriction of Security Token Assignment)

The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected, such as improperly restricting the assignment to trusted components.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Overlap Between Protected Memory Ranges - (1260)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1260 (Improper Handling of Overlap Between Protected Memory Ranges)

The product allows address regions to overlap, which can result in the bypassing of intended memory protection.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Access Control for Register Interface - (1262)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1262 (Improper Access Control for Register Interface)

The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1267 (Policy Uses Obsolete Encoding)

The product uses an encoding mechanism that is no longer trusted, i.e., an obsolete encoding, to implement access controls.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Policy Privileges are not Assigned Consistently Between Control and Data Agents - (1268)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1268 (Policy Privileges are not Assigned Consistently Between Control and Data Agents)

The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1270 (Generation of Incorrect Security Tokens)

The product implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens generated in the system are incorrect.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Access Control Check Implemented After Asset is Accessed - (1280)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1280 (Access Control Check Implemented After Asset is Accessed)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Decoding of Security Identifiers - (1290)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1290 (Incorrect Decoding of Security Identifiers)

The product implements a decoding mechanism to decode certain bus-transaction signals to security identifiers, but it decodes an untrusted agent's security identifier into a trusted agent's security identifier.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Conversion of Security Identifiers - (1292)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1292 (Incorrect Conversion of Security Identifiers)

The product implements a conversion mechanism to map certain bus-transaction signals to security identifiers, but this conversion between protocols is incorrectly implemented.

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1294 (Insecure Security Identifier Mechanism)

The System-on-Chip (SoC) implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers are not correctly implemented.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Protection Mechanism for Alternate Hardware Interface - (1299)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1299 (Missing Protection Mechanism for Alternate Hardware Interface)

The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC) - (1302)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1302 (Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC))

The product implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity, but the entity does not consistently include the necessary Security Identifier with a security-critical transaction.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Non-Transparent Sharing of Microarchitectural Resources - (1303)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1303 (Non-Transparent Sharing of Microarchitectural Resources)

Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Write Protection for Parametric Data Values - (1314)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1314 (Missing Write Protection for Parametric Data Values)

The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Support for Security Features in On-chip Fabrics or Buses - (1318)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1318 (Missing Support for Security Features in On-chip Fabrics or Buses)

On-chip fabrics or buses either do not support or are not configured to support privilege separation or other security features, such as access control.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unauthorized Error Injection Can Degrade Hardware Redundancy - (1334)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1334 (Unauthorized Error Injection Can Degrade Hardware Redundancy)

An unauthorized agent can inject errors into a redundant block to deprive the system of redundancy or put the system in a degraded operating mode.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information during Transient Execution - (1420)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1420 (Exposure of Sensitive Information during Transient Execution)

A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution - (1421)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1421 (Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution)

A processor event may allow transient operations to access architecturally restricted data (for example, in another address space) in a shared microarchitectural structure (for example, a CPU cache), potentially exposing the data over a covert channel.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution - (1422)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1422 (Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution)

A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution - (1423)

1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1423 (Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution)

Shared microarchitectural predictor state may allow code to influence transient execution across a hardware boundary, potentially exposing data that is accessible beyond the boundary over a covert channel.

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. General Circuit and Logic Design Concerns - (1199)

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns)

Weaknesses in this category are related to hardware-circuit design and logic (e.g., CMOS transistors, finite state machines, and registers) as well as issues related to hardware description languages such as System Verilog and VHDL.

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1209 (Failure to Disable Reserved Bits)

The reserved bits in a hardware design are not disabled prior to production.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Register Defaults or Module Parameters - (1221)

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1221 (Incorrect Register Defaults or Module Parameters)

Hardware description language code incorrectly defines register defaults or hardware Intellectual Property (IP) parameters to insecure values.

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1223 (Race Condition for Write-Once Attributes)

A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Restriction of Write-Once Bit Fields - (1224)

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1224 (Improper Restriction of Write-Once Bit Fields)

The hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Prevention of Lock Bit Modification - (1231)

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1231 (Improper Prevention of Lock Bit Modification)

The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Lock Behavior After Power State Transition - (1232)

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1232 (Improper Lock Behavior After Power State Transition)

Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Security-Sensitive Hardware Controls with Missing Lock Bit Protection - (1233)

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1233 (Security-Sensitive Hardware Controls with Missing Lock Bit Protection)

The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Hardware Internal or Debug Modes Allow Override of Locks - (1234)

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1234 (Hardware Internal or Debug Modes Allow Override of Locks)

System configuration protection may be bypassed during debug mode.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Finite State Machines (FSMs) in Hardware Logic - (1245)

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1245 (Improper Finite State Machines (FSMs) in Hardware Logic)

Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system.

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1250 (Improper Preservation of Consistency Between Independent Representations of Shared State)

The product has or supports multiple distributed components or sub-systems that are each required to keep their own local copy of shared data - such as state or cache - but the product does not ensure that all local copies remain consistent with each other.

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1253 (Incorrect Selection of Fuse Values)

The logic level used to set a system to a secure state relies on a fuse being unblown.

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1254 (Incorrect Comparison Logic Granularity)

The product's comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1261 (Improper Handling of Single Event Upsets)

The hardware logic does not effectively handle when single-event upsets (SEUs) occur.

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1298 (Hardware Logic Contains Race Conditions)

A race condition in the hardware logic results in undermining security guarantees of the system.

1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1461 (Hardware Simulation / Synthesis Mismatch)

The hardware design contains structures that are interpreted differently during synthesis than during simulation, which cause inconsistencies in security-relevant behavior between the synthesized implementation and the simulation.

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Core and Compute Issues - (1201)

1194 (Hardware Design) > 1201 (Core and Compute Issues)

Weaknesses in this category are typically associated with CPUs, Graphics, Vision, AI, FPGA, and microcontrollers.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations - (1252)

1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1252 (CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations)

The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Sequence of Processor Instructions Leads to Unexpected Behavior - (1281)

1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1281 (Sequence of Processor Instructions Leads to Unexpected Behavior)

Specific combinations of processor instructions lead to undesirable behavior such as locking the processor until a hard reset performed.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Information Exposure through Microarchitectural State after Transient Execution - (1342)

1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1342 (Information Exposure through Microarchitectural State after Transient Execution)

The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information during Transient Execution - (1420)

1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1420 (Exposure of Sensitive Information during Transient Execution)

A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution - (1421)

1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1421 (Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution)

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution - (1422)

1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1422 (Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution)

A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution - (1423)

1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1423 (Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution)

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Memory and Storage Issues - (1202)

1194 (Hardware Design) > 1202 (Memory and Storage Issues)

Weaknesses in this category are typically associated with memory (e.g., DRAM, SRAM) and storage technologies (e.g., NAND Flash, OTP, EEPROM, and eMMC).

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Sensitive Information in Resource Not Removed Before Reuse - (226)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 226 (Sensitive Information in Resource Not Removed Before Reuse)

The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1239 (Improper Zeroization of Hardware Register)

The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Write Handling in Limited-write Non-Volatile Memories - (1246)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1246 (Improper Write Handling in Limited-write Non-Volatile Memories)

The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories.

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1251 (Mirrored Regions with Different Values)

The product's architecture mirrors regions without ensuring that their contents always stay in sync.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Access Control Applied to Mirrored or Aliased Memory Regions - (1257)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1257 (Improper Access Control Applied to Mirrored or Aliased Memory Regions)

Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Assumed-Immutable Data is Stored in Writable Memory - (1282)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1282 (Assumed-Immutable Data is Stored in Writable Memory)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Information Exposure through Microarchitectural State after Transient Execution - (1342)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1342 (Information Exposure through Microarchitectural State after Transient Execution)

The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information during Transient Execution - (1420)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1420 (Exposure of Sensitive Information during Transient Execution)

A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution - (1421)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1421 (Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution)

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution - (1422)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1422 (Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution)

A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution - (1423)

1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1423 (Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution)

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Peripherals, On-chip Fabric, and Interface/IO Problems - (1203)

1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems)

Weaknesses in this category are related to hardware security problems that apply to peripheral devices, IO interfaces, on-chip interconnects, network-on-chip (NoC), and buses. For example, this category includes issues related to design of hardware interconnect and/or protocols such as PCIe, USB, SMBUS, general-purpose IO pins, and user-input peripherals such as mouse and keyboard.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Translation of Security Attributes by Fabric Bridge - (1311)

1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1311 (Improper Translation of Security Attributes by Fabric Bridge)

The fabric bridge incorrectly translates security attributes from either trusted to untrusted or from untrusted to trusted when converting from one fabric protocol to another.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Protection for Mirrored Regions in On-Chip Fabric Firewall - (1312)

1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1312 (Missing Protection for Mirrored Regions in On-Chip Fabric Firewall)

The firewall in an on-chip fabric protects the main addressed region, but it does not protect any mirrored memory or memory-mapped-IO (MMIO) regions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Setting of Bus Controlling Capability in Fabric End-point - (1315)

1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1315 (Improper Setting of Bus Controlling Capability in Fabric End-point)

The bus controller enables bits in the fabric end-point to allow responder devices to control transactions on the fabric.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges - (1316)

1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1316 (Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges)

The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.

1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1317 (Improper Access Control in Fabric Bridge)

The product uses a fabric bridge for transactions between two Intellectual Property (IP) blocks, but the bridge does not properly perform the expected privilege, identity, or other access control checks between those IP blocks.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Isolation of Shared Resources in Network On Chip (NoC) - (1331)

1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1331 (Improper Isolation of Shared Resources in Network On Chip (NoC))

The Network On Chip (NoC) does not isolate or incorrectly isolates its on-chip-fabric and internal resources such that they are shared between trusted and untrusted agents, creating timing channels.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Request Propagation before Data Reception in Write Transactions in a Bus Architecture - (1476)

1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1476 (Improper Request Propagation before Data Reception in Write Transactions in a Bus Architecture)

The product uses a multi-manager shared bus architecture with an on-chip interconnect that speculatively propagates a request for a write transaction, but it does not ensure that the remaining steps required by the manager module to complete the request are fulfilled in a timely manner.

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Security Primitives and Cryptography Issues - (1205)

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues)

Weaknesses in this category are related to hardware implementations of cryptographic protocols and other hardware-security primitives such as physical unclonable functions (PUFs) and random number generators (RNGs).

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 203 (Observable Discrepancy)

The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor. Side Channel Attack

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 325 (Missing Cryptographic Step)

The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of a Cryptographic Primitive with a Risky Implementation - (1240)

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1240 (Use of a Cryptographic Primitive with a Risky Implementation)

To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Predictable Algorithm in Random Number Generator - (1241)

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1241 (Use of Predictable Algorithm in Random Number Generator)

The device uses an algorithm that is predictable and generates a pseudo-random number.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Cryptographic Operations are Run Before Supporting Units are Ready - (1279)

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1279 (Cryptographic Operations are Run Before Supporting Units are Ready)

Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protection of Physical Side Channels - (1300)

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1300 (Improper Protection of Physical Side Channels)

The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Hardware Behavior in Exceptionally Cold Environments - (1351)

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1351 (Improper Handling of Hardware Behavior in Exceptionally Cold Environments)

The hardware device, or the firmware running on it, is missing or has incorrect protection mechanisms to maintain goals of security primitives when the device is cooled below standard operating temperatures.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Driving Intermediate Cryptographic State/Results to Hardware Module Outputs - (1431)

1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1431 (Driving Intermediate Cryptographic State/Results to Hardware Module Outputs)

The product uses a hardware module implementing a cryptographic algorithm that writes sensitive information about the intermediate state or results of its cryptographic operations via one of its output wires (typically the output port containing the final result).

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Power, Clock, Thermal, and Reset Concerns - (1206)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns)

Weaknesses in this category are related to system power, voltage, current, temperature, clocks, system state saving/restoring, and resets at the platform and SoC level.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Lock Behavior After Power State Transition - (1232)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1232 (Improper Lock Behavior After Power State Transition)

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protection Against Voltage and Clock Glitches - (1247)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1247 (Improper Protection Against Voltage and Clock Glitches)

The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1248 (Semiconductor Defects in Hardware Logic with Security-Sensitive Implications)

The security-sensitive hardware module contains semiconductor defects.

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Comparison Logic is Vulnerable to Power Side-Channel Attacks - (1255)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1255 (Comparison Logic is Vulnerable to Power Side-Channel Attacks)

A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Restriction of Software Interfaces to Hardware Features - (1256)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1256 (Improper Restriction of Software Interfaces to Hardware Features)

The product provides software-controllable device functionality for capabilities such as power and clock management, but it does not properly limit functionality that can lead to modification of hardware memory or register bits, or the ability to observe physical side channels.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Uninitialized Value on Reset for Registers Holding Security Settings - (1271)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1271 (Uninitialized Value on Reset for Registers Holding Security Settings)

Security-critical logic is not set to a known value on reset.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation - (1304)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1304 (Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation)

The product performs a power save/restore operation, but it does not ensure that the integrity of the configuration state is maintained and/or verified between the beginning and ending of the operation.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Write Protection for Parametric Data Values - (1314)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1314 (Missing Write Protection for Parametric Data Values)

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protection for Outbound Error Messages and Alert Signals - (1320)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1320 (Improper Protection for Outbound Error Messages and Alert Signals)

Untrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Faults that Lead to Instruction Skips - (1332)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1332 (Improper Handling of Faults that Lead to Instruction Skips)

The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protections Against Hardware Overheating - (1338)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1338 (Improper Protections Against Hardware Overheating)

A hardware device is missing or has inadequate protection features to prevent overheating.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Hardware Behavior in Exceptionally Cold Environments - (1351)

1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1351 (Improper Handling of Hardware Behavior in Exceptionally Cold Environments)

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Debug and Test Problems - (1207)

1194 (Hardware Design) > 1207 (Debug and Test Problems)

Weaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. On-Chip Debug and Test Interface With Improper Access Control - (1191)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1191 (On-Chip Debug and Test Interface With Improper Access Control)

The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Hardware Internal or Debug Modes Allow Override of Locks - (1234)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1234 (Hardware Internal or Debug Modes Allow Override of Locks)

System configuration protection may be bypassed during debug mode.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Sensitive Non-Volatile Information Not Protected During Debug - (1243)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1243 (Sensitive Non-Volatile Information Not Protected During Debug)

Access to security-sensitive information stored in fuses is not limited during debug.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Internal Asset Exposed to Unsafe Debug Access Level or State - (1244)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1244 (Internal Asset Exposed to Unsafe Debug Access Level or State)

The product uses physical debug or test interfaces with support for multiple access levels, but it assigns the wrong debug access level to an internal asset, providing unintended access to the asset from untrusted debug agents.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Sensitive System Information Due to Uncleared Debug Information - (1258)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1258 (Exposure of Sensitive System Information Due to Uncleared Debug Information)

The hardware product enters debug mode but does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Sensitive Information Uncleared Before Debug/Power State Transition - (1272)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1272 (Sensitive Information Uncleared Before Debug/Power State Transition)

The product performs a power or debug state transition, but it does not clear sensitive information that should no longer be accessible due to changes to information access restrictions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Public Key Re-Use for Signing both Debug and Production Code - (1291)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1291 (Public Key Re-Use for Signing both Debug and Production Code)

The same public key is used for signing both debug and production code.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Debug Messages Revealing Unnecessary Information - (1295)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1295 (Debug Messages Revealing Unnecessary Information)

The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Chaining or Granularity of Debug Components - (1296)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1296 (Incorrect Chaining or Granularity of Debug Components)

The product's debug components contain incorrect chaining or granularity of debug components.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Hardware Allows Activation of Test or Debug Logic at Runtime - (1313)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1313 (Hardware Allows Activation of Test or Debug Logic at Runtime)

During runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Management of Sensitive Trace Data - (1323)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1323 (Improper Management of Sensitive Trace Data)

Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Transmission of Sensitive Information - (319)

1194 (Hardware Design) > 1207 (Debug and Test Problems) > 319 (Cleartext Transmission of Sensitive Information)

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

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Cross-Cutting Problems - (1208)

1194 (Hardware Design) > 1208 (Cross-Cutting Problems)

Weaknesses in this category can arise in multiple areas of hardware design or can apply to a wide cross-section of components.

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 440 (Expected Behavior Violation)

A feature, API, or function does not perform according to its specification.

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1053 (Missing Documentation for Design)

The product does not have documentation that represents how it is designed.

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1059 (Insufficient Technical Documentation)

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1263 (Improper Physical Access Control)

The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1277 (Firmware Not Updateable)

The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insufficient or Incomplete Data Removal within Hardware Component - (1301)

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1301 (Insufficient or Incomplete Data Removal within Hardware Component)

The product's data removal process does not completely delete all data and potentially sensitive information within hardware components.

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1329 (Reliance on Component That is Not Updateable)

The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1330 (Remanent Data Readable after Memory Erase)

Confidential information stored in memory circuits is readable or recoverable after being cleared or erased, i.e., there is data remanence.

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1357 (Reliance on Insufficiently Trustworthy Component)

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

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Security-Relevant Feedback for Unexecuted Operations in Hardware Interface - (1429)

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1429 (Missing Security-Relevant Feedback for Unexecuted Operations in Hardware Interface)

The product has a hardware interface that silently discards operations in situations for which feedback would be security-relevant, such as the timely detection of failures or attacks.

1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1461 (Hardware Simulation / Synthesis Mismatch)

Grouping - a CWE entry that contains a set of other entries that share a common characteristic. Physical Access Issues and Concerns - (1388)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns)

Weaknesses in this category are related to concerns of physical access.

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1384 (Improper Handling of Physical or Environmental Conditions)

The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protection against Electromagnetic Fault Injection (EM-FI) - (1319)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1319 (Improper Protection against Electromagnetic Fault Injection (EM-FI))

The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protection Against Voltage and Clock Glitches - (1247)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1247 (Improper Protection Against Voltage and Clock Glitches)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1261 (Improper Handling of Single Event Upsets)

The hardware logic does not effectively handle when single-event upsets (SEUs) occur.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Faults that Lead to Instruction Skips - (1332)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1332 (Improper Handling of Faults that Lead to Instruction Skips)

The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Hardware Behavior in Exceptionally Cold Environments - (1351)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1351 (Improper Handling of Hardware Behavior in Exceptionally Cold Environments)

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)

Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Comparison Logic is Vulnerable to Power Side-Channel Attacks - (1255)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1255 (Comparison Logic is Vulnerable to Power Side-Channel Attacks)

A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protection of Physical Side Channels - (1300)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1300 (Improper Protection of Physical Side Channels)

1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1248 (Semiconductor Defects in Hardware Logic with Security-Sensitive Implications)

The security-sensitive hardware module contains semiconductor defects.

Vulnerability Mapping Notes

Usage	PROHIBITED (this CWE ID must not be used to map to real-world vulnerabilities)
Reason	View
Rationale	This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.
Comments	Use this View or other Views to search and navigate for the appropriate weakness.

Notes

Relationship

This view attempts to present hardware weaknesses in a simple and intuitive way. As such it uses a single level of abstraction. The same category could contain weaknesses that have parent/child relationships within View-1000. By exploring View-1000 relationships for the weaknesses that are included, one can find deeper relationships between some hardware weaknesses.

Other

The top level categories in this view represent commonly understood areas/terms within hardware design, and are meant to aid the user in identifying potential related weaknesses. It is possible for the same weakness to exist within multiple different categories.

View Metrics

	CWEs in this view		Total CWEs
Weaknesses	112	out of	956
Categories	13	out of	396
Views	0	out of	58
Total	125	out of	1410

Content History

Submissions
Submission Date	Submitter	Organization
2019-12-27 (CWE 4.0, 2020-02-24)	CWE Content Team	MITRE
2019-12-27 (CWE 4.0, 2020-02-24)
Contributions
Contribution Date	Contributor	Organization
2026-07-17 (CWE 5.0, 2026-10-28)		Hardware CWE Special Interest Group (HW CWE SIG)
2026-07-17 (CWE 5.0, 2026-10-28)	Discussed pros and cons of deeper versus shallower trees for this view, ultimately choosing the shallower tree.
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Other_Notes, Relationship_Notes
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Mapping_Notes
2022-06-28 (CWE 4.8, 2022-06-28)	CWE Content Team	MITRE
2022-06-28 (CWE 4.8, 2022-06-28)	updated Relationships

View Components

Weakness ID: 319

Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

View customized information:

Shows the description and diagram, platforms, mitigations, consequences, relationships, memberships, and content history. For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Description

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

Common Consequences

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

Impact

Details

Read Application Data; Modify Files or Directories

Scope: Integrity, Confidentiality

Anyone can read the information by gaining access to the channel being used for communication. 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.

Read Application Data; Modify Files or Directories; Other

Scope: Integrity, Confidentiality

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.

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.
Implementation	When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.
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.
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.
Operation	Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf, Overlaps, and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	311	Missing Encryption of Sensitive Data
	ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	5	J2EE Misconfiguration: Data Transmission Without Encryption
	ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	614	Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1428	Reliance on HTTP instead of HTTPS

Relevant to the view "Software Development" (View-699)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	199	Information Management Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
	Nature	Type	ID	Name
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	311	Missing Encryption of Sensitive Data

Relevant to the view "Architectural Concepts" (View-1008)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1013	Encrypt Data

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1207	Debug and Test Problems

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase(s)	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and Design	For 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

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

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence) Go (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence) 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)

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:

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

Selected Observed Examples

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

Reference	Description
CVE-2022-29519	Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.
CVE-2022-30312	Building Controller uses a protocol that transmits authentication credentials in plaintext.
CVE-2022-31204	Programmable Logic Controller (PLC) sends password in plaintext.
CVE-2002-1949	Passwords transmitted in cleartext.
CVE-2008-4122	Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
CVE-2008-3289	Product sends password hash in cleartext in violation of intended policy.
CVE-2008-4390	Remote management feature sends sensitive information including passwords in cleartext.
CVE-2007-5626	Backup routine sends password in cleartext in email.
CVE-2004-1852	Product transmits Blowfish encryption key in cleartext.
CVE-2008-0374	Printer sends configuration information, including administrative password, in cleartext.
CVE-2007-4961	Chain: cleartext transmission of the MD5 hash of password (CWE-319) enables attacks against a server that is susceptible to replay (CWE-294).
CVE-2007-4786	Product sends passwords in cleartext to a log server.
CVE-2005-3140	Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.

Weakness Ordinalities

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

Detection Methods

Method

Details

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

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	818	OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	858	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	859	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	934	OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	963	SFP Secondary Cluster: Exposed Data
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1029	OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1148	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1346	OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1402	Comprehensive Categorization: Encryption
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1439	OWASP Top Ten 2025 Category A04:2025 - Cryptographic Failures
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1468	Weaknesses Addressed by the OWASP Golang Secure Coding Practices Guide

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Notes

Other

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.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		Plaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011)	SEC06-J	Do 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-J	Sign then seal sensitive objects before sending them outside a trust boundary
Software Fault Patterns	SFP23	Exposed Data
ISA/IEC 62443	Part 3-3	Req SR 4.1
ISA/IEC 62443	Part 4-2	Req CR 4.1B
OWASP Golang Secure Coding Practices Guide		Communication Security

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-102	Session Sidejacking
CAPEC-117	Interception
CAPEC-383	Harvesting Information via API Event Monitoring
CAPEC-477	Signature Spoofing by Mixing Signed and Unsigned Content
CAPEC-65	Sniff Application Code

References

[REF-271]	OWASP. "Top 10 2007-Insecure Communications". 2007. <https://web.archive.org/web/20160319230109/http://www.owasp.org/index.php/Top_10_2007-A9>. (URL validated: 2025-08-04)
[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)
[REF-1566]	OWASP. "Golang Secure Coding Practices guide". Communication Security, page 50. 2024. <https://github.com/OWASP/Go-SCP>. (URL validated: 2026-10-19)

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2023-01-24 (CWE 4.10, 2023-01-31)	Accellera IP Security Assurance (IPSA) Working Group	Accellera Systems Initiative
2023-01-24 (CWE 4.10, 2023-01-31)	Submitted original contents of CWE-1324 and reviewed its integration into this entry.
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Applicable_Platforms, Observed_Examples, References, Relationships, Taxonomy_Mappings
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated Applicable_Platforms, Maintenance_Notes, Relationships, Weakness_Ordinalities
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated References
2025-04-03 (CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
2025-04-03 (CWE 4.17, 2025-04-03)	updated Common_Consequences, Description, Diagram, Other_Notes, Relationships
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Demonstrative_Examples
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Description, Mapping_Notes, Relationships
2023-04-27 (CWE 4.11, 2023-04-27)	CWE Content Team	MITRE
2023-04-27 (CWE 4.11, 2023-04-27)	updated Detection_Factors, References, Relationships
2023-01-31 (CWE 4.10, 2023-01-31)	CWE Content Team	MITRE
2023-01-31 (CWE 4.10, 2023-01-31)	updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2022-10-13 (CWE 4.9, 2022-10-13)	CWE Content Team	MITRE
2022-10-13 (CWE 4.9, 2022-10-13)	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2022-06-28 (CWE 4.8, 2022-06-28)	CWE Content Team	MITRE
2022-06-28 (CWE 4.8, 2022-06-28)	updated Relationships
2021-10-28 (CWE 4.6, 2021-10-28)	CWE Content Team	MITRE
2021-10-28 (CWE 4.6, 2021-10-28)	updated Relationships
2020-02-24 (CWE 4.0, 2020-02-24)	CWE Content Team	MITRE
2020-02-24 (CWE 4.0, 2020-02-24)	updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2019-06-20 (CWE 3.3, 2019-06-20)	CWE Content Team	MITRE
2019-06-20 (CWE 3.3, 2019-06-20)	updated Relationships, Type
2019-01-03 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2019-01-03 (CWE 3.2, 2019-01-03)	updated Relationships, Taxonomy_Mappings
2018-03-27 (CWE 3.1, 2018-03-27)	CWE Content Team	MITRE
2018-03-27 (CWE 3.1, 2018-03-27)	updated References, Relationships, Type
2018-01-23 (CWE 3.1, 2018-03-27)	CWE Content Team	MITRE
2018-01-23 (CWE 3.1, 2018-03-27)	updated Abstraction
2017-11-08 (CWE 3.0, 2017-11-08)	CWE Content Team	MITRE
2017-11-08 (CWE 3.0, 2017-11-08)	updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2017-05-03 (CWE 2.11, 2017-05-05)	CWE Content Team	MITRE
2017-05-03 (CWE 2.11, 2017-05-05)	updated Related_Attack_Patterns
2014-07-30 (CWE 2.8, 2014-07-31)	CWE Content Team	MITRE
2014-07-30 (CWE 2.8, 2014-07-31)	updated Relationships, Taxonomy_Mappings
2014-06-23 (CWE 2.7, 2014-06-23)	CWE Content Team	MITRE
2014-06-23 (CWE 2.7, 2014-06-23)	updated Relationships
2014-02-18 (CWE 2.6, 2014-02-19)	CWE Content Team	MITRE
2014-02-18 (CWE 2.6, 2014-02-19)	updated Related_Attack_Patterns
2013-07-17 (CWE 2.5, 2013-07-17)	CWE Content Team	MITRE
2013-07-17 (CWE 2.5, 2013-07-17)	updated Relationships
2013-02-21 (CWE 2.4, 2013-02-21)	CWE Content Team	MITRE
2013-02-21 (CWE 2.4, 2013-02-21)	updated Applicable_Platforms, References
2012-05-11 (CWE 2.2, 2012-05-15)	CWE Content Team	MITRE
2012-05-11 (CWE 2.2, 2012-05-15)	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-06-01 (CWE 1.13, 2011-06-01)	CWE Content Team	MITRE
2011-06-01 (CWE 1.13, 2011-06-01)	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 (CWE 1.12, 2011-03-30)	CWE Content Team	MITRE
2011-03-29 (CWE 1.12, 2011-03-30)	updated Potential_Mitigations
2010-12-13 (CWE 1.11, 2010-12-13)	CWE Content Team	MITRE
2010-12-13 (CWE 1.11, 2010-12-13)	updated Observed_Examples, Related_Attack_Patterns
2010-06-21 (CWE 1.9, 2010-06-21)	CWE Content Team	MITRE
2010-06-21 (CWE 1.9, 2010-06-21)	updated Detection_Factors, Relationships
2010-04-05 (CWE 1.8.1, 2010-04-05)	CWE Content Team	MITRE
2010-04-05 (CWE 1.8.1, 2010-04-05)	updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-02-16 (CWE 1.8, 2010-02-16)	CWE Content Team	MITRE
2010-02-16 (CWE 1.8, 2010-02-16)	updated References
2009-05-27 (CWE 1.4, 2009-05-27)	CWE Content Team	MITRE
2009-05-27 (CWE 1.4, 2009-05-27)	updated Related_Attack_Patterns
2009-03-10 (CWE 1.3, 2009-03-10)	CWE Content Team	MITRE
2009-03-10 (CWE 1.3, 2009-03-10)	updated Potential_Mitigations
2009-01-12 (CWE 1.2, 2009-01-12)	CWE Content Team	MITRE
2009-01-12 (CWE 1.2, 2009-01-12)	updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2008-09-08 (CWE 1.0, 2008-09-09)	CWE Content Team	MITRE
2008-09-08 (CWE 1.0, 2008-09-09)	updated Relationships, Taxonomy_Mappings
2008-07-01 (CWE 1.0, 2008-09-09)	Eric Dalci	Cigital
2008-07-01 (CWE 1.0, 2008-09-09)	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Plaintext Transmission of Sensitive Information

Weakness ID: 1422

View customized information:

Description

A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.

Extended Description

Software may use a variety of techniques to preserve the confidentiality of private data that is accessible within the current processor context. For example, the memory safety and type safety properties of some high-level programming languages help to prevent software written in those languages from exposing private data. As a second example, software sandboxes may co-locate multiple users' software within a single process. The processor's Instruction Set Architecture (ISA) may permit one user's software to access another user's data (because the software shares the same address space), but the sandbox prevents these accesses by using software techniques such as bounds checking.

If incorrect or stale data can be forwarded (for example, from a cache) to transient operations, then the operations' microarchitectural side effects may correspond to the data. If an attacker can trigger these transient operations and observe their side effects through a covert channel, then the attacker may be able to infer the data. For example, an attacker process may induce transient execution in a victim process that causes the victim to inadvertently access and then expose its private data via a covert channel. In the software sandbox example, an attacker sandbox may induce transient execution in its own code, allowing it to transiently access and expose data in a victim sandbox that shares the same address space.

Consequently, weaknesses that arise from incorrect/stale data forwarding might violate users' expectations of software-based memory safety and isolation techniques. If the data forwarding behavior is not properly documented by the hardware vendor, this might violate the software vendor's expectation of how the hardware should behave.

Common Consequences

Impact	Details
Read Memory	Scope: Confidentiality Likelihood: Medium

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels. Effectiveness: Limited Note: Instructions or features that constrain transient execution or suppress its side effects may impact performance.
Requirements	Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels. Effectiveness: Defense in Depth Note: Disabling specific predictors or other hardware features may result in significant performance overhead.
Requirements	Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure. Effectiveness: Moderate Note: Instructions or features that constrain transient execution or suppress its side effects may impact performance.
Requirements	Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution. Effectiveness: Limited Note: Disabling specific predictors or other hardware features may result in significant performance overhead.
Build and Compilation	Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction. Effectiveness: Incidental Note: Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].
Build and Compilation	Isolate sandboxes or managed runtimes in separate address spaces (separate processes). Effectiveness: High Note: Process isolation is also an effective strategy to mitigate many other kinds of weaknesses.
Build and Compilation	Include serialization instructions (for example, LFENCE) that prevent processor events or mis-predictions prior to the serialization instruction from causing transient execution after the serialization instruction. For some weaknesses, a serialization instruction can also prevent a processor event or a mis-prediction from occurring after the serialization instruction (for example, CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store; a serialization instruction between the store and the load may allow the store to update memory and prevent the mis-prediction from happening at all). Effectiveness: Moderate Note: When used to comprehensively mitigate a transient execution weakness, serialization instructions can introduce significant performance overhead.
Build and Compilation	Use software techniques that can mitigate the consequences of transient execution. For example, address masking can be used in some circumstances to prevent out-of-bounds transient reads. Effectiveness: Limited Note: Address masking and related software mitigation techniques have been used to harden specific code sequences that could potentially be exploited via transient execution. For example, the Linux kernel makes limited use of this technique to mitigate bounds-check bypass [REF-1390].
Build and Compilation	If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness. Effectiveness: Limited Note: This technique is only effective for software that is compiled with this mitigation.
Documentation	If a hardware feature can allow incorrect or stale data to be forwarded to transient operations, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations. Effectiveness: High

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1420	Exposure of Sensitive Information during Transient Execution

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1198	Privilege Separation and Access Control Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1201	Core and Compute Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1202	Memory and Storage Issues

Modes Of Introduction

Phase(s)

Note

Architecture and Design

This weakness can be introduced by data speculation techniques, or when the processor pipeline is designed to check exception conditions concurrently with other operations. This weakness can also persist after a CWE-1421 weakness has been mitigated. For example, suppose that a processor can forward stale data from a shared microarchitectural buffer to dependent transient operations, and furthermore suppose that the processor has been patched to flush the buffer on context switches. This mitigates the CWE-1421 weakness, but the stale-data forwarding behavior may persist as a CWE-1422 weakness unless this behavior is also patched.

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

Faulting loads in a victim domain may trigger incorrect transient forwarding, which leaves secret-dependent traces in the microarchitectural state. Consider this code sequence example from [REF-1391].

(bad code)

Example Language: C

				  void call_victim(size_t untrusted_arg) {

					*arg_copy = untrusted_arg;

					array[**trusted_ptr * 4096];

				  }

A processor with this weakness will store the value of untrusted_arg (which may be provided by an attacker) to the stack, which is trusted memory. Additionally, this store operation will save this value in some microarchitectural buffer, for example, the store buffer.

In this code sequence, trusted_ptr is dereferenced while the attacker forces a page fault. The faulting load causes the processor to mis-speculate by forwarding untrusted_arg as the (transient) load result. The processor then uses untrusted_arg for the pointer dereference. After the fault has been handled and the load has been re-issued with the correct argument, secret-dependent information stored at the address of trusted_ptr remains in microarchitectural state and can be extracted by an attacker using a vulnerable code sequence.

Example 2

Some processors try to predict when a store will forward data to a subsequent load, even when the address of the store or the load is not yet known. For example, on Intel processors this feature is called a Fast Store Forwarding Predictor [REF-1392], and on AMD processors the feature is called Predictive Store Forwarding [REF-1393]. A misprediction can cause incorrect or stale data to be forwarded from a store to a load, as illustrated in the following code snippet from [REF-1393]:

(bad code)

Example Language: C

				  void fn(int idx) {

					unsigned char v;

					idx_array[0] = 4096;

					v = array[idx_array[idx] * (idx)];

				  }

In this example, assume that the parameter idx can only be 0 or 1, and assume that idx_array initially contains all 0s. Observe that the assignment to v in line 4 will be array[0], regardless of whether idx=0 or idx=1. Now suppose that an attacker repeatedly invokes fn with idx=0 to train the store forwarding predictor to predict that the store in line 3 will forward the data 4096 to the load idx_array[idx] in line 4. Then, when the attacker invokes fn with idx=1 the predictor may cause idx_array[idx] to transiently produce the incorrect value 4096, and therefore v will transiently be assigned the value array[4096], which otherwise would not have been accessible in line 4.

Although this toy example is benign (it doesn't transmit array[4096] over a covert channel), an attacker may be able to use similar techniques to craft and train malicious code sequences to, for example, read data beyond a software sandbox boundary.

Selected Observed Examples

Reference	Description
CVE-2020-0551	A fault, microcode assist, or abort may allow transient load operations to forward malicious stale data to dependent operations executed by a victim, causing the victim to unintentionally access and potentially expose its own data over a covert channel.
CVE-2020-8698	A fast store forwarding predictor may allow store operations to forward incorrect data to transient load operations, potentially exposing data over a covert channel.

Weakness Ordinalities

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

Detection Methods

Method

Details

Automated Static Analysis

A variety of automated static analysis tools can identify potentially exploitable code sequences in software. These tools may perform the analysis on source code, on binary code, or on an intermediate code representation (for example, during compilation).

Effectiveness: Moderate

Note:Automated static analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Manual Analysis

This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state.Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods.

Effectiveness: Moderate

Note:Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Automated Analysis

Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors:

$ cat /proc/cpuinfo | grep bugs | head -n 1

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed

Effectiveness: High

Note:This method can be useful for detecting whether a processor if affected by known weaknesses, but it may not be useful for detecting unknown weaknesses.

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1416	Comprehensive Categorization: Resource Lifecycle Management

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities
Comments	Use only when the weakness arises from forwarding of incorrect/stale data, and the data is not architecturally restricted (that is, the forwarded data is accessible within the current processor context). If a weakness arises from forwarding of incorrect/stale data that is not accessible within the current processor context, then CWE-1421 may be more appropriate for the mapping task.

References

[REF-1389]	Alyssa Milburn, Ke Sun and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08. <https://arxiv.org/abs/2203.04277>. (URL validated: 2024-02-22)
[REF-1390]	The kernel development community. "Speculation". 2020-08-16. <https://docs.kernel.org/6.6/staging/speculation.html>. (URL validated: 2024-02-04)
[REF-1391]	Jo Van Bulck, Daniel Moghimi, Michael Schwarz, Moritz Lipp, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss and Frank Piessens. "LVI : Hijacking Transient Execution through Microarchitectural Load Value Injection". 2020-01-09. <https://lviattack.eu/lvi.pdf>. (URL validated: 2024-02-04)
[REF-1392]	Intel Corporation. "Fast Store Forwarding Predictor". 2022-02-08. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/fast-store-forwarding-predictor.html>. (URL validated: 2024-02-04)
[REF-1393]	AMD. "Security Analysis Of AMD Predictive Store Forwarding". 2021-03. <https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf>. (URL validated: 2024-02-04)

Content History

Submissions
Submission Date	Submitter	Organization
2023-09-19 (CWE 4.14, 2024-02-29)	Scott D. Constable	Intel Corporation
2023-09-19 (CWE 4.14, 2024-02-29)
Contributions
Contribution Date	Contributor	Organization
2024-01-22 (CWE 4.14, 2024-02-29)	David Kaplan	AMD
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett	Arm
2024-01-22 (CWE 4.14, 2024-02-29)	Members of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Jason Oberg	Cycuity
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Priya B. Iyer	Intel Corporation
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Nicole Fern	Riscure
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Relationships
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated Weakness_Ordinalities

Weakness ID: 1423

View customized information:

Description

Extended Description

Many commodity processors have Instruction Set Architecture (ISA) features that protect software components from one another. These features can include memory segmentation, virtual memory, privilege rings, trusted execution environments, and virtual machines, among others. For example, virtual memory provides each process with its own address space, which prevents processes from accessing each other's private data. Many of these features can be used to form hardware-enforced security boundaries between software components.

When separate software components (for example, two processes) share microarchitectural predictor state across a hardware boundary, code in one component may be able to influence microarchitectural predictor behavior in another component. If the predictor can cause transient execution, the shared predictor state may allow an attacker to influence transient execution in a victim, and in a manner that could allow the attacker to infer private data from the victim by monitoring observable discrepancies (CWE-203) in a covert channel [REF-1400].

Predictor state may be shared when the processor transitions from one component to another (for example, when a process makes a system call to enter the kernel). Many commodity processors have features which prevent microarchitectural predictions that occur before a boundary from influencing predictions that occur after the boundary.

Predictor state may also be shared between hardware threads, for example, sibling hardware threads on a processor that supports simultaneous multithreading (SMT). This sharing may be benign if the hardware threads are simultaneously executing in the same software component, or it could expose a weakness if one sibling is a malicious software component, and the other sibling is a victim software component. Processors that share microarchitectural predictors between hardware threads may have features which prevent microarchitectural predictions that occur on one hardware thread from influencing predictions that occur on another hardware thread.

Features that restrict predictor state sharing across transitions or between hardware threads may be always-on, on by default, or may require opt-in from software.

Common Consequences

Impact	Details
Read Memory	Scope: Confidentiality Likelihood: Medium

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
Architecture and Design	Hardware designers may choose to use microarchitectural bits to tag predictor entries. For example, each predictor entry may be tagged with a kernel-mode bit which, when set, indicates that the predictor entry was created in kernel mode. The processor can use this bit to enforce that predictions in the current mode must have been trained in the current mode. This can prevent malicious cross-mode training, such as when user-mode software attempts to create predictor entries that influence transient execution in the kernel. Predictor entry tags can also be used to associate each predictor entry with the SMT thread that created it, and thus the processor can enforce that each predictor entry can only be used by the SMT thread that created it. This can prevent an SMT thread from using predictor entries crafted by a malicious sibling SMT thread. Effectiveness: Moderate Note: Tagging can be highly effective for predictor state that is comprised of discrete elements, such as an array of recently visited branch targets. Predictor state can also have different representations that are not conducive to tagging. For example, some processors keep a compressed digest of branch history which does not contain discrete elements that can be individually tagged.
Architecture and Design	Hardware designers may choose to sanitize microarchitectural predictor state (for example, branch prediction history) when the processor transitions to a different context, for example, whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize predictor state according to the user's threat model. For example, this can allow operating system software to sanitize predictor state when performing a context switch from one process to another. Effectiveness: Moderate Note: This technique may not be able to mitigate weaknesses that arise from predictor state that is shared across SMT threads. Sanitizing predictor state on context switches may also negatively impact performance, either by removing predictor entries that could be reused when returning to the previous context, or by slowing down the context switch itself.
Implementation	System software can mitigate this weakness by invoking predictor-state-sanitizing operations (for example, the indirect branch prediction barrier on Intel x86) when switching from one context to another, according to the hardware vendor's recommendations. Effectiveness: Moderate Note: This technique may not be able to mitigate weaknesses that arise from predictor state shared across SMT threads. Sanitizing predictor state may also negatively impact performance in some circumstances.
Build and Compilation	If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated. One prominent example of this mitigation is retpoline ([REF-1414]). Effectiveness: Limited Note: This technique is only effective for software that is compiled with this mitigation. Additionally, an alternate instruction sequence may mitigate the weakness on some processors but not others, even when the processors share the same ISA. For example, retpoline has been documented as effective on some x86 processors, but not fully effective on other x86 processors.
Build and Compilation	Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions. Effectiveness: Moderate Note: Some CFI techniques may not be able to constrain transient execution, even though they are effective at constraining architectural execution. Or they may be able to provide some additional protection against a transient execution weakness, but without comprehensively mitigating the weakness. For example, Clang-CFI provides strong architectural CFI properties and can make some transient execution weaknesses more difficult to exploit [REF-1398].
Build and Compilation	Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction. Effectiveness: Incidental Note: Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].
System Configuration	Some systems may allow the user to disable predictor sharing. For example, this could be a BIOS configuration, or a model-specific register (MSR) that can be configured by the operating system or virtual machine monitor. Effectiveness: Moderate Note: Disabling predictor sharing can negatively impact performance for some workloads that benefit from shared predictor state.
Patching and Maintenance	The hardware vendor may provide a patch to, for example, sanitize predictor state when the processor transitions to a different context, or to prevent predictor entries from being shared across SMT threads. A patch may also introduce new ISA that allows software to toggle a mitigation. Effectiveness: Moderate Note: This mitigation may only be fully effective if the patch prevents predictor sharing across all contexts that are affected by the weakness. Additionally, sanitizing predictor state and/or preventing shared predictor state can negatively impact performance in some circumstances.
Documentation	If a hardware feature can allow microarchitectural predictor state to be shared between contexts, SMT threads, or other architecturally defined boundaries, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations. Effectiveness: High
Requirements	Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1420	Exposure of Sensitive Information during Transient Execution

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1198	Privilege Separation and Access Control Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1201	Core and Compute Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1202	Memory and Storage Issues

Modes Of Introduction

Phase(s)	Note
Architecture and Design	This weakness can be introduced during hardware architecture and design if predictor state is not properly isolated between modes (for example, user mode and kernel mode), if predictor state is not isolated between hardware threads, or if it is not isolated between other kinds of execution contexts supported by the processor.
Implementation	This weakness can be introduced during system software implementation if predictor-state-sanitizing operations (for example, the indirect branch prediction barrier on Intel x86) are not invoked when switching from one context to another.
System Configuration	This weakness can be introduced if the system has not been configured according to the hardware vendor's recommendations for mitigating the weakness.

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Microcontroller Hardware (Undetermined Prevalence) Processor Hardware (Undetermined Prevalence) Memory Hardware (Undetermined Prevalence) Class: System on Chip (Undetermined Prevalence)

Demonstrative Examples

Example 1

Branch Target Injection (BTI) is a vulnerability that can allow an SMT hardware thread to maliciously train the indirect branch predictor state that is shared with its sibling hardware thread. A cross-thread BTI attack requires the attacker to find a vulnerable code sequence within the victim software. For example, the authors of [REF-1415] identified the following code sequence in the Windows library ntdll.dll:

(bad code)

Example Language: x86 Assembly

						adc edi,dword ptr [ebx+edx+13BE13BDh]

						adc dl,byte ptr [edi]

						...

					indirect_branch_site:

						jmp dword ptr [rsi]   # at this point attacker knows edx, controls edi and ebx

To successfully exploit this code sequence to disclose the victim's private data, the attacker must also be able to find an indirect branch site within the victim, where the attacker controls the values in edi and ebx, and the attacker knows the value in edx as shown above at the indirect branch site.

A proof-of-concept cross-thread BTI attack might proceed as follows:

The attacker thread and victim thread must be co-scheduled on the same physical processor core.
The attacker thread must train the shared branch predictor so that when the victim thread reaches indirect_branch_site, the jmp instruction will be predicted to target example_code_sequence instead of the correct architectural target. The training procedure may vary by processor, and the attacker may need to reverse-engineer the branch predictor to identify a suitable training algorithm.
This step assumes that the attacker can control some values in the victim program, specifically the values in edi and ebx at indirect_branch_site. When the victim reaches indirect_branch_site the processor will (mis)predict example_code_sequence as the target and (transiently) execute the adc instructions. If the attacker chooses ebx so that `ebx = m
- 0x13BE13BD - edx, then the first adc will load 32 bits from address m in the victim's address space and add *m (the data loaded from) to the attacker-controlled base address in edi. The second adc instruction accesses a location in memory whose address corresponds to *m`.
The adversary uses a covert channel analysis technique such as Flush+Reload ([REF-1416]) to infer the value of the victim's private data *m.

Example 2

BTI can also allow software in one execution context to maliciously train branch predictor entries that can be used in another context. For example, on some processors user-mode software may be able to train predictor entries that can also be used after transitioning into kernel mode, such as after invoking a system call. This vulnerability does not necessarily require SMT and may instead be performed in synchronous steps, though it does require the attacker to find an exploitable code sequence in the victim's code, for example, in the kernel.

Selected Observed Examples

Reference	Description
CVE-2017-5754	(Branch Target Injection, BTI, Spectre v2). Shared microarchitectural indirect branch predictor state may allow code to influence transient execution across a process, VM, or privilege boundary, potentially exposing data that is accessible beyond the boundary.
CVE-2022-0001	(Branch History Injection, BHI, Spectre-BHB). Shared branch history state may allow user-mode code to influence transient execution in the kernel, potentially exposing kernel data over a covert channel.
CVE-2022-29901	(RSB underflow, Retbleed). Shared return stack buffer state may allow code that executes before a prediction barrier to influence transient execution after the prediction barrier, potentially exposing data that is accessible beyond the barrier over a covert channel.

Weakness Ordinalities

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

Detection Methods

Method

Details

Manual Analysis

This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may have microarchitectural predictor state that is shared between hardware threads, execution contexts (for example, user and kernel), or other components that may host mutually distrusting software (or firmware, etc.).

Effectiveness: Moderate

Note:Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Automated Analysis

$ cat /proc/cpuinfo | grep bugs | head -n 1

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed

Effectiveness: High

Note:This method can be useful for detecting whether a processor if affected by known weaknesses, but it may not be useful for detecting unknown weaknesses

Automated Analysis

This weakness can be detected in hardware by employing static or dynamic taint analysis methods [REF-1401]. These methods can label each predictor entry (or prediction history, etc.) according to the processor context that created it. Taint analysis or information flow analysis can then be applied to detect when predictor state created in one context can influence predictions made in another context.

Effectiveness: Moderate

Note:Automated static or dynamic taint analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1416	Comprehensive Categorization: Resource Lifecycle Management
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1432	Weaknesses in the 2025 CWE Most Important Hardware Weaknesses List

Vulnerability Mapping Notes

Usage

ALLOWED

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

Reason

Acceptable-Use

Rationale

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

Comments

Use only when the weakness allows code in one processor context to influence the predictions of code in another processor context via predictor state that is shared between the two contexts. For example, Branch Target Injection, an instance of CWE-1423, can be mitigated by tagging each indirect branch predictor entry according to the processor context in which the entry was created, thus preventing entries created in one context from being used in a different context. However, the mitigated indirect branch predictor can still expose different weaknesses where malicious predictor entries created in one context are used later in the same context (context tags cannot prevent this). One such example is Intra-mode Branch Target Injection. Weaknesses of this sort can map to CWE-1420.

Suggestions

CWE-ID	Comment
CWE-1420	If a weakness involves a microarchitectural predictor whose state is not shared across processor contexts, then CWE-1420 may be more appropriate for the mapping task.

References

[REF-1414]	Intel Corporation. "Retpoline: A Branch Target Injection Mitigation". 2022-08-22. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html>. (URL validated: 2023-02-13)
[REF-1415]	Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz and Yuval Yarom. "Spectre Attacks: Exploiting Speculative Execution". 2019-05. <https://spectreattack.com/spectre.pdf>. (URL validated: 2024-02-14)
[REF-1416]	Yuval Yarom and Katrina Falkner. "Flush+Reload: A High Resolution, Low Noise, L3 Cache Side-Channel Attack". 2014. <https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-yarom.pdf>. (URL validated: 2023-02-13)
[REF-1398]	The Clang Team. "Control Flow Integrity". <https://clang.llvm.org/docs/ControlFlowIntegrity.html>. (URL validated: 2024-02-13)
[REF-1389]	Alyssa Milburn, Ke Sun and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08. <https://arxiv.org/abs/2203.04277>. (URL validated: 2024-02-22)
[REF-1400]	Intel Corporation. "Refined Speculative Execution Terminology". 2022-03-11. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/refined-speculative-execution-terminology.html>. (URL validated: 2024-02-13)
[REF-1401]	Neta Bar Kama and Roope Kaivola. "Hardware Security Leak Detection by Symbolic Simulation". 2021-11. <https://ieeexplore.ieee.org/document/9617727>. (URL validated: 2024-02-13)

Content History

Submissions
Submission Date	Submitter	Organization
2023-09-19 (CWE 4.14, 2024-02-29)	Scott D. Constable	Intel Corporation
2023-09-19 (CWE 4.14, 2024-02-29)
Contributions
Contribution Date	Contributor	Organization
2024-01-22 (CWE 4.14, 2024-02-29)	David Kaplan	AMD
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett	Arm
2024-01-22 (CWE 4.14, 2024-02-29)	Members of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Jason Oberg	Cycuity
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Priya B. Iyer	Intel Corporation
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Nicole Fern	Riscure
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Observed_Examples, Relationships
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated Weakness_Ordinalities
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated Relationships

Weakness ID: 1420

Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

View customized information:

Description

A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.

Extended Description

When operations execute but do not commit to the processor's architectural state, this is commonly referred to as transient execution. This behavior can occur when the processor mis-predicts an outcome (such as a branch target), or when a processor event (such as an exception or microcode assist, etc.) is handled after younger operations have already executed. Operations that execute transiently may exhibit observable discrepancies (CWE-203) in covert channels [REF-1400] such as data caches. Observable discrepancies of this kind can be detected and analyzed using timing or power analysis techniques, which may allow an attacker to infer information about the operations that executed transiently. For example, the attacker may be able to infer confidential data that was accessed or used by those operations.

Transient execution weaknesses may be exploited using one of two methods. In the first method, the attacker generates a code sequence that exposes data through a covert channel when it is executed transiently (the attacker must also be able to trigger transient execution). Some transient execution weaknesses can only expose data that is accessible within the attacker's processor context. For example, an attacker executing code in a software sandbox may be able to use a transient execution weakness to expose data within the same address space, but outside of the attacker's sandbox. Other transient execution weaknesses can expose data that is architecturally inaccessible, that is, data protected by hardware-enforced boundaries such as page tables or privilege rings. These weaknesses are the subject of CWE-1421.

In the second exploitation method, the attacker first identifies a code sequence in a victim program that, when executed transiently, can expose data that is architecturally accessible within the victim's processor context. For instance, the attacker may search the victim program for code sequences that resemble a bounds-check bypass sequence (see Demonstrative Example 1). If the attacker can trigger a mis-prediction of the conditional branch and influence the index of the out-of-bounds array access, then the attacker may be able to infer the value of out-of-bounds data by monitoring observable discrepancies in a covert channel.

Common Consequences

Impact	Details
Read Memory	Scope: Confidentiality Likelihood: Medium

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels. Effectiveness: Limited Note: This technique has many pitfalls. For example, InvisiSpec was an early attempt to mitigate this weakness by blocking "micro-architectural covert and side channels through the multiprocessor data cache hierarchy due to speculative loads" [REF-1417]. Commodity processors and SoCs have many covert and side channels that exist outside of the data cache hierarchy. Even when some of these channels are blocked, others (such as execution ports [REF-1418]) may allow an attacker to infer confidential data. Mitigation strategies that attempt to prevent transient execution from causing observable discrepancies also have other pitfalls, for example, see [REF-1419].
Requirements	Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure. Effectiveness: Moderate Note: Instructions or features that constrain transient execution or suppress its side effects may impact performance.
Requirements	Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution. Effectiveness: Limited Note: Disabling specific predictors or other hardware features may result in significant performance overhead.
Requirements	Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels. Effectiveness: Defense in Depth Note: Specific software algorithms can be used by an attacker to compensate for a lack of a high-resolution time source [REF-1420].
Build and Compilation	Isolate sandboxes or managed runtimes in separate address spaces (separate processes). For examples, see [REF-1421]. Effectiveness: High
Build and Compilation	Include serialization instructions (for example, LFENCE) that prevent processor events or mis-predictions prior to the serialization instruction from causing transient execution after the serialization instruction. For some weaknesses, a serialization instruction can also prevent a processor event or a mis-prediction from occurring after the serialization instruction (for example, CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store; a serialization instruction between the store and the load may allow the store to update memory and prevent the prediction from happening at all). Effectiveness: Moderate Note: When used to comprehensively mitigate a transient execution weakness (for example, by inserting an LFENCE after every instruction in a program), serialization instructions can introduce significant performance overhead. On the other hand, when used to mitigate only a relatively small number of high-risk code sequences, serialization instructions may have a low or negligible impact on performance.
Build and Compilation	Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions. Effectiveness: Moderate Note: Some CFI techniques may not be able to constrain transient execution, even though they are effective at constraining architectural execution. Or they may be able to provide some additional protection against a transient execution weakness, but without comprehensively mitigating the weakness. For example, Clang-CFI provides strong architectural CFI properties and can make some transient execution weaknesses more difficult to exploit [REF-1398].
Build and Compilation	If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness. One prominent example of this mitigation is retpoline ([REF-1414]). Effectiveness: Limited Note: This technique may only be effective for software that is compiled with this mitigation. For some transient execution weaknesses, this technique may not be sufficient to protect software that is compiled without the affected instruction(s). For example, see CWE-1421.
Build and Compilation	Use software techniques that can mitigate the consequences of transient execution. For example, address masking can be used in some circumstances to prevent out-of-bounds transient reads. Effectiveness: Limited Note: Address masking and related software mitigation techniques have been used to harden specific code sequences that could potentially be exploited via transient execution. For example, the Linux kernel makes limited use of manually inserted address masks to mitigate bounds-check bypass [REF-1390]. Compiler-based techniques have also been used to automatically harden software [REF-1425].
Build and Compilation	Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction. Effectiveness: Incidental Note: Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].
Documentation	If a hardware feature can allow incorrect operations (or correct operations with incorrect data) to execute transiently, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations. Effectiveness: High

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	669	Incorrect Resource Transfer Between Spheres
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1421	Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1422	Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1423	Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution
	PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1431	Driving Intermediate Cryptographic State/Results to Hardware Module Outputs

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1198	Privilege Separation and Access Control Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1201	Core and Compute Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1202	Memory and Storage Issues

Modes Of Introduction

Phase(s)

Note

Architecture and Design

This weakness can be introduced when a computing unit (such as a CPU, GPU, accelerator, or any other processor) uses out-of-order execution, speculation, or any other microarchitectural feature that can allow microarchitectural operations to execute without committing to architectural state.

Implementation

This weakness can be introduced when sandboxes or managed runtimes are not properly isolated by using hardware-enforced boundaries. Developers of sandbox or managed runtime software should exercise caution when relying on software techniques (such as bounds checking) to prevent code in one sandbox from accessing confidential data in another sandbox. For example, an attacker sandbox may be able to trigger a processor event or mis-prediction in a manner that allows it to transiently read a victim sandbox's private data.

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

Secure programs perform bounds checking before accessing an array if the source of the array index is provided by an untrusted source such as user input. In the code below, data from array1 will not be accessed if x is out of bounds. The following code snippet is from [REF-1415]:

(bad code)

Example Language: C

if (x < array1_size)
y = array2[array1[x] * 4096];

However, if this code executes on a processor that performs conditional branch prediction the outcome of the if statement could be mis-predicted and the access on the next line will occur with a value of x that can point to an out-of-bounds location (within the program's memory).

Even though the processor does not commit the architectural effects of the mis-predicted branch, the memory accesses alter data cache state, which is not rolled back after the branch is resolved. The cache state can reveal array1[x] thereby providing a mechanism to recover the data value located at address array1 + x.

Example 2

Some managed runtimes or just-in-time (JIT) compilers may overwrite recently executed code with new code. When the instruction pointer enters the new code, the processor may inadvertently execute the stale code that had been overwritten. This can happen, for instance, when the processor issues a store that overwrites a sequence of code, but the processor fetches and executes the (stale) code before the store updates memory. Similar to the first example, the processor does not commit the stale code's architectural effects, though microarchitectural side effects can persist. Hence, confidential information accessed or used by the stale code may be inferred via an observable discrepancy in a covert channel. This vulnerability is described in more detail in [REF-1427].

Selected Observed Examples

Reference	Description
CVE-2017-5753	Microarchitectural conditional branch predictors may allow operations to execute transiently after a misprediction, potentially exposing data over a covert channel.
CVE-2021-0089	A machine clear triggered by self-modifying code may allow incorrect operations to execute transiently, potentially exposing data over a covert channel.
CVE-2022-0002	Microarchitectural indirect branch predictors may allow incorrect operations to execute transiently after a misprediction, potentially exposing data over a covert channel.

Weakness Ordinalities

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

Detection Methods

Method	Details
Manual Analysis	This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state. Academic researchers have demonstrated that new hardware weaknesses can be discovered by exhaustively analyzing a processor's machine clear (or nuke) conditions ([REF-1427]). Effectiveness: Moderate Note: Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods. Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.
Fuzzing	Academic researchers have demonstrated that this weakness can be detected in hardware using software fuzzing tools that treat the underlying hardware as a black box ([REF-1428]). Effectiveness: Opportunistic Note: Fuzzing may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.
Fuzzing	Academic researchers have demonstrated that this weakness can be detected in software using software fuzzing tools ([REF-1429]). Effectiveness: Opportunistic Note: At the time of this writing, publicly available software fuzzing tools can only detect a subset of transient execution weaknesses in software (for example, [REF-1429] can only detect instances of Spectre v1) and may produce false positives.
Automated Static Analysis	A variety of automated static analysis tools can identify potentially exploitable code sequences in software. These tools may perform the analysis on source code, on binary code, or on an intermediate code representation (for example, during compilation). Effectiveness: Limited Note: At the time of this writing, publicly available software static analysis tools can only detect a subset of transient execution weaknesses in software and may produce false positives.
Automated Analysis	Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors: $ cat /proc/cpuinfo \| grep bugs \| head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed Effectiveness: High Note: This method can be useful for detecting whether a processor is affected by known weaknesses, but it may not be useful for detecting unknown weaknesses.

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1416	Comprehensive Categorization: Resource Lifecycle Management

Vulnerability Mapping Notes

Usage	ALLOWED-WITH-REVIEW (this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason	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	A vulnerability should only map to CWE-1420 if it cannot map to any of CWE-1420's child weaknesses. Follow this diagram:

References

[REF-1389]	Alyssa Milburn, Ke Sun and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08. <https://arxiv.org/abs/2203.04277>. (URL validated: 2024-02-22)
[REF-1417]	Mengjia Yan, Jiho Choi, Dimitrios Skarlatos, Adam Morrison, Christopher W. Fletcher and Josep Torrella. "InvisiSpec: making speculative execution invisible in the cache hierarchy.". 2019-05. <https://iacoma.cs.uiuc.edu/iacoma-papers/micro18.pdf>. (URL validated: 2025-08-04)
[REF-1418]	Alejandro Cabrera Aldaya, Billy Bob Brumley, Sohaib ul Hassan, Cesar Pereida García and Nicola Tuveri. "Port Contention for Fun and Profit". 2019-05. <https://eprint.iacr.org/2018/1060.pdf>. (URL validated: 2024-02-14)
[REF-1419]	Mohammad Behnia, Prateek Sahu, Riccardo Paccagnella, Jiyong Yu, Zirui Zhao, Xiang Zou, Thomas Unterluggauer, Josep Torrellas, Carlos Rozas, Adam Morrison, Frank Mckeen, Fangfei Liu, Ron Gabor, Christopher W. Fletcher, Abhishek Basak and Alaa Alameldeen. "Speculative Interference Attacks: Breaking Invisible Speculation Schemes". 2021-04. <https://arxiv.org/abs/2007.11818>. (URL validated: 2024-02-14)
[REF-1420]	Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer and Toon Verwaest. "Spectre is here to stay: An analysis of side-channels and speculative execution". 2019-02-14. <https://arxiv.org/pdf/1902.05178>. (URL validated: 2025-08-04)
[REF-1421]	Intel Corporation. "Managed Runtime Speculative Execution Side Channel Mitigations". 2018-01-03. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/runtime-speculative-side-channel-mitigations.html>. (URL validated: 2024-02-14)
[REF-1398]	The Clang Team. "Control Flow Integrity". <https://clang.llvm.org/docs/ControlFlowIntegrity.html>. (URL validated: 2024-02-13)
[REF-1414]	Intel Corporation. "Retpoline: A Branch Target Injection Mitigation". 2022-08-22. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html>. (URL validated: 2023-02-13)
[REF-1390]	The kernel development community. "Speculation". 2020-08-16. <https://docs.kernel.org/6.6/staging/speculation.html>. (URL validated: 2024-02-04)
[REF-1425]	Chandler Carruth. "Speculative Load Hardening". <https://llvm.org/docs/SpeculativeLoadHardening.html>. (URL validated: 2024-02-14)
[REF-1427]	Hany Ragab, Enrico Barberis, Herbert Bos and Cristiano Giuffrida. "Rage Against the Machine Clear: A Systematic Analysis of Machine Clears and Their Implications for Transient Execution Attacks". 2021-08. <https://www.usenix.org/system/files/sec21-ragab.pdf>. (URL validated: 2024-02-14)
[REF-1428]	Oleksii Oleksenko, Marco Guarnieri, Boris Köpf and Mark Silberstein. "Hide and Seek with Spectres: Efficient discovery of speculative information leaks with random testing". 2023-01-18. <https://arxiv.org/pdf/2301.07642>. (URL validated: 2025-08-04)
[REF-1429]	Oleksii Oleksenko, Bohdan Trach, Mark Silberstein and Christof Fetzer. "SpecFuzz: Bringing Spectre-type vulnerabilities to the surface". 2020-08. <https://www.usenix.org/system/files/sec20-oleksenko.pdf>. (URL validated: 2024-02-14)
[REF-1415]	Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz and Yuval Yarom. "Spectre Attacks: Exploiting Speculative Execution". 2019-05. <https://spectreattack.com/spectre.pdf>. (URL validated: 2024-02-14)
[REF-1400]	Intel Corporation. "Refined Speculative Execution Terminology". 2022-03-11. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/refined-speculative-execution-terminology.html>. (URL validated: 2024-02-13)

Content History

Submissions
Submission Date	Submitter	Organization
2023-09-19 (CWE 4.14, 2024-02-29)	Scott D. Constable	Intel Corporation
2023-09-19 (CWE 4.14, 2024-02-29)
Contributions
Contribution Date	Contributor	Organization
2024-01-22 (CWE 4.14, 2024-02-29)	David Kaplan	AMD
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett	Arm
2024-01-22 (CWE 4.14, 2024-02-29)	Members of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Jason Oberg	Cycuity
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Priya B. Iyer	Intel Corporation
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Nicole Fern	Riscure
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated References, Relationships
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated References, Weakness_Ordinalities
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated References
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Mapping_Notes

Weakness ID: 1421

View customized information:

Description

Extended Description

Many commodity processors also share microarchitectural resources that cache (temporarily store) data, which may be confidential. These resources may be shared across processor contexts, including across SMT threads, privilege rings, or others.

When transient operations allow access to ISA-protected data in a shared microarchitectural resource, this might violate users' expectations of the ISA feature that is bypassed. For example, if transient operations can access a victim's private data in a shared microarchitectural resource, then the operations' microarchitectural side effects may correspond to the accessed data. If an attacker can trigger these transient operations and observe their side effects through a covert channel [REF-1400], then the attacker may be able to infer the victim's private data. Private data could include sensitive program data, OS/VMM data, page table data (such as memory addresses), system configuration data (see Demonstrative Example 3), or any other data that the attacker does not have the required privileges to access.

Common Consequences

Impact	Details
Read Memory	Scope: Confidentiality Likelihood: Medium

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	Hardware designers may choose to engineer the processor's pipeline to prevent architecturally restricted data from being used by operations that can execute transiently. Effectiveness: High
Architecture and Design	Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers. Effectiveness: Moderate Note: This can be highly effective at preventing this weakness from being exposed across different SMT threads or different processor cores. It is generally less practical to isolate these resources between different contexts (for example, user and kernel) that may execute on the same SMT thread or processor core.
Architecture and Design	Hardware designers may choose to sanitize specific microarchitectural state (for example, store buffers) when the processor transitions to a different context, such as whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize microarchitectural state according to the user or system administrator's threat model. These mitigation approaches are similar to those that address CWE-226; however, sanitizing microarchitectural state may not be the optimal or best way to mitigate this weakness on every processor design. Effectiveness: Moderate Note: Sanitizing shared state on context transitions may not be practical for all processors, especially when the amount of shared state affected by the weakness is relatively large. Additionally, this technique may not be practical unless there is a synchronous transition between two processor contexts that would allow the affected resource to be sanitized. For example, this technique alone may not suffice to mitigate asynchronous access to a resource that is shared by two SMT threads.
Architecture and Design	The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels. Effectiveness: Limited Note: This technique has many pitfalls. For example, InvisiSpec was an early attempt to mitigate this weakness by blocking "micro-architectural covert and side channels through the multiprocessor data cache hierarchy due to speculative loads" [REF-1417]. Commodity processors and SoCs have many covert and side channels that exist outside of the data cache hierarchy. Even when some of these channels are blocked, others (such as execution ports [REF-1418]) may allow an attacker to infer confidential data. Mitigation strategies that attempt to prevent transient execution from causing observable discrepancies also have other pitfalls, for example, see [REF-1419].
Architecture and Design	Software architects may design software to enforce strong isolation between different contexts. For example, kernel page table isolation (KPTI) mitigates the Meltdown vulnerability [REF-1401] by separating user-mode page tables from kernel-mode page tables, which prevents user-mode processes from using Meltdown to transiently access kernel memory [REF-1404]. Effectiveness: Limited Note: Isolating different contexts across a process boundary (or another kind of architectural boundary) may only be effective for some weaknesses.
Build and Compilation	If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness. Effectiveness: Limited Note: This technique may only be fully effective if it is applied to all software that runs on the system. Also, relatively few observed examples of this weakness have exposed data through only a single instruction.
Build and Compilation	Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction. Effectiveness: Incidental Note: Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].
Implementation	System software can mitigate this weakness by invoking state-sanitizing operations when switching from one context to another, according to the hardware vendor's recommendations. Effectiveness: Limited Note: This technique may not be able to mitigate weaknesses that arise from resource sharing across SMT threads.
System Configuration	Some systems may allow the user to disable (for example, in the BIOS) sharing of the affected resource. Effectiveness: Limited Note: Disabling resource sharing (for example, by disabling SMT) may result in significant performance overhead.
System Configuration	Some systems may allow the user to disable (for example, in the BIOS) microarchitectural features that allow transient access to architecturally restricted data. Effectiveness: Limited Note: Disabling microarchitectural features such as predictors may result in significant performance overhead.
Patching and Maintenance	The hardware vendor may provide a patch to sanitize the affected shared microarchitectural state when the processor transitions to a different context. Effectiveness: Moderate Note: This technique may not be able to mitigate weaknesses that arise from resource sharing across SMT threads.
Patching and Maintenance	This kind of patch may not be feasible or implementable for all processors or all weaknesses. Effectiveness: Limited
Requirements	Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels. Effectiveness: Defense in Depth Note: Specific software algorithms can be used by an attacker to compensate for a lack of a high-resolution time source [REF-1420].

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1420	Exposure of Sensitive Information during Transient Execution

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1198	Privilege Separation and Access Control Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1201	Core and Compute Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1202	Memory and Storage Issues

Modes Of Introduction

Phase(s)	Note
Architecture and Design	This weakness can be introduced during hardware architecture and design if a data path allows architecturally restricted data to propagate to operations that execute before an older mis-prediction or processor event (such as an exception) is caught.
Implementation	This weakness can be introduced during system software implementation if state-sanitizing operations are not invoked when switching from one context to another, according to the hardware vendor's recommendations for mitigating the weakness.
System Configuration	This weakness can be introduced if the system has not been configured according to the hardware vendor's recommendations for mitigating the weakness.
Architecture and Design	This weakness can be introduced when an access control check (for example, checking page permissions) can proceed in parallel with the access operation (for example, a load) that is being checked. If the processor can allow the access operation to execute before the check completes, this race condition may allow subsequent transient operations to expose sensitive information.

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

Some processors may perform access control checks in parallel with memory read/write operations. For example, when a user-mode program attempts to read data from memory, the processor may also need to check whether the memory address is mapped into user space or kernel space. If the processor performs the access concurrently with the check, then the access may be able to transiently read kernel data before the check completes. This race condition is demonstrated in the following code snippet from [REF-1408], with additional annotations:

(bad code)

Example Language: x86 Assembly

                                
; rcx = kernel address, rbx = probe array

xor rax, rax                # set rax to 0

retry:

mov al, byte [rcx]          # attempt to read kernel memory

shl rax, 0xc                # multiply result by page size (4KB)

jz retry                    # if the result is zero, try again

mov rbx, qword [rbx + rax]  # transmit result over a cache covert channel

Vulnerable processors may return kernel data from a shared microarchitectural resource in line 4, for example, from the processor's L1 data cache. Since this vulnerability involves a race condition, the mov in line 4 may not always return kernel data (that is, whenever the check "wins" the race), in which case this demonstration code re-attempts the access in line 6. The accessed data is multiplied by 4KB, a common page size, to make it easier to observe via a cache covert channel after the transmission in line 7. The use of cache covert channels to observe the side effects of transient execution has been described in [REF-1408].

Example 2

Many commodity processors share microarchitectural fill buffers between sibling hardware threads on simultaneous multithreaded (SMT) processors. Fill buffers can serve as temporary storage for data that passes to and from the processor's caches. Microarchitectural Fill Buffer Data Sampling (MFBDS) is a vulnerability that can allow a hardware thread to access its sibling's private data in a shared fill buffer. The access may be prohibited by the processor's ISA, but MFBDS can allow the access to occur during transient execution, in particular during a faulting operation or an operation that triggers a microcode assist.

More information on MFBDS can be found in [REF-1405] and [REF-1409].

Example 3

Some processors may allow access to system registers (for example, system coprocessor registers or model-specific registers) during transient execution. This scenario is depicted in the code snippet below. Under ordinary operating circumstances, code in exception level 0 (EL0) is not permitted to access registers that are restricted to EL1, such as TTBR0_EL1. However, on some processors an earlier mis-prediction can cause the MRS instruction to transiently read the value in an EL1 register. In this example, a conditional branch (line 2) can be mis-predicted as "not taken" while waiting for a slow load (line 1). This allows MRS (line 3) to transiently read the value in the TTBR0_EL1 register. The subsequent memory access (line 6) can allow the restricted register's value to become observable, for example, over a cache covert channel.

Code snippet is from [REF-1410]. See also [REF-1411].

(bad code)

Example Language: x86 Assembly

                                
LDR X1, [X2] ; arranged to miss in the cache

CBZ X1, over ; This will be taken 

MRS X3, TTBR0_EL1; 

LSL X3, X3, #imm 

AND X3, X3, #0xFC0

LDR X5, [X6,X3] ; X6 is an EL0 base address

over

Selected Observed Examples

Reference	Description
CVE-2017-5715	A fault may allow transient user-mode operations to access kernel data cached in the L1D, potentially exposing the data over a covert channel.
CVE-2018-3615	A fault may allow transient non-enclave operations to access SGX enclave data cached in the L1D, potentially exposing the data over a covert channel.
CVE-2019-1135	A TSX Asynchronous Abort may allow transient operations to access architecturally restricted data, potentially exposing the data over a covert channel.

Weakness Ordinalities

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

Detection Methods

Method	Details
Manual Analysis	This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state. Academic researchers have demonstrated that new hardware weaknesses can be discovered by examining publicly available patent filings, for example [REF-1405] and [REF-1406]. Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods. Effectiveness: Moderate Note:Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.
Automated Analysis	This weakness can be detected (pre-discovery) in hardware by employing static or dynamic taint analysis methods [REF-1401]. These methods can label data in one context (for example, kernel data) and perform information flow analysis (or a simulation, etc.) to determine whether tainted data can appear in another context (for example, user mode). Alternatively, stale or invalid data in shared microarchitectural resources can be marked as tainted, and the taint analysis framework can identify when transient operations encounter tainted data. Effectiveness: Moderate Note:Automated static or dynamic taint analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.
Automated Analysis	Software vendors can release tools that detect presence of known weaknesses (post-discovery) on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors: $ cat /proc/cpuinfo \| grep bugs \| head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed Effectiveness: High Note:This method can be useful for detecting whether a processor if affected by known weaknesses, but it may not be useful for detecting unknown weaknesses.
Fuzzing	Academic researchers have demonstrated that this weakness can be detected in hardware using software fuzzing tools that treat the underlying hardware as a black box ([REF-1406], [REF-1430]) Effectiveness: Opportunistic Note:Fuzzing may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1416	Comprehensive Categorization: Resource Lifecycle Management
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1432	Weaknesses in the 2025 CWE Most Important Hardware Weaknesses List

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities
Comments	If a weakness can potentially be exploited to infer data that is accessible inside or outside the current processor context, then the weakness could map to CWE-1421 and to another CWE such as CWE-1420.

References

[REF-1404]	The kernel development community. "Page Table Isolation (PTI)". 2023-01-30. <https://kernel.org/doc/html/next/x86/pti.html>. (URL validated: 2024-02-13)
[REF-1405]	Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Giorgi Maisuradze, Kaveh Razavi, Herbert Bos and Cristiano Giuffrida. "RIDL: Rogue In-Flight Data Load". 2019-05-19. <https://mdsattacks.com/files/ridl.pdf>. (URL validated: 2024-02-13)
[REF-1406]	Daniel Moghimi. "Downfall: Exploiting Speculative Data Gathering". 2023-08-09. <https://www.usenix.org/system/files/usenixsecurity23-moghimi.pdf>. (URL validated: 2024-02-13)
[REF-1401]	Neta Bar Kama and Roope Kaivola. "Hardware Security Leak Detection by Symbolic Simulation". 2021-11. <https://ieeexplore.ieee.org/document/9617727>. (URL validated: 2024-02-13)
[REF-1408]	Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom and Mike Hamburg. "Meltdown: Reading Kernel Memory from User Space". 2020-05-21. <https://meltdownattack.com/meltdown.pdf>. (URL validated: 2024-02-13)
[REF-1409]	Intel Corporation. "Microarchitectural Data Sampling". 2021-03-11. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/intel-analysis-microarchitectural-data-sampling.html>. (URL validated: 2024-02-13)
[REF-1410]	ARM. "Cache Speculation Side-channels". 2018-01. <https://armkeil.blob.core.windows.net/developer/Files/pdf/Cache_Speculation_Side-channels.pdf>. (URL validated: 2024-02-22)
[REF-1411]	Intel Corporation. "Rogue System Register Read/CVE-2018-3640/INTEL-SA-00115". 2018-05-01. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/rogue-system-register-read.html>. (URL validated: 2024-02-13)
[REF-1400]	Intel Corporation. "Refined Speculative Execution Terminology". 2022-03-11. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/refined-speculative-execution-terminology.html>. (URL validated: 2024-02-13)
[REF-1389]	Alyssa Milburn, Ke Sun and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08. <https://arxiv.org/abs/2203.04277>. (URL validated: 2024-02-22)
[REF-1430]	Daniel Moghimi, Moritz Lipp, Berk Sunar and Michael Schwarz. "Medusa: Microarchitectural: Data Leakage via Automated Attack Synthesis". 2020-08. <https://www.usenix.org/conference/usenixsecurity20/presentation/moghimi-medusa>. (URL validated: 2024-02-27)
[REF-1417]	Mengjia Yan, Jiho Choi, Dimitrios Skarlatos, Adam Morrison, Christopher W. Fletcher and Josep Torrella. "InvisiSpec: making speculative execution invisible in the cache hierarchy.". 2019-05. <https://iacoma.cs.uiuc.edu/iacoma-papers/micro18.pdf>. (URL validated: 2025-08-04)
[REF-1418]	Alejandro Cabrera Aldaya, Billy Bob Brumley, Sohaib ul Hassan, Cesar Pereida García and Nicola Tuveri. "Port Contention for Fun and Profit". 2019-05. <https://eprint.iacr.org/2018/1060.pdf>. (URL validated: 2024-02-14)
[REF-1419]	Mohammad Behnia, Prateek Sahu, Riccardo Paccagnella, Jiyong Yu, Zirui Zhao, Xiang Zou, Thomas Unterluggauer, Josep Torrellas, Carlos Rozas, Adam Morrison, Frank Mckeen, Fangfei Liu, Ron Gabor, Christopher W. Fletcher, Abhishek Basak and Alaa Alameldeen. "Speculative Interference Attacks: Breaking Invisible Speculation Schemes". 2021-04. <https://arxiv.org/abs/2007.11818>. (URL validated: 2024-02-14)
[REF-1420]	Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer and Toon Verwaest. "Spectre is here to stay: An analysis of side-channels and speculative execution". 2019-02-14. <https://arxiv.org/pdf/1902.05178>. (URL validated: 2025-08-04)

Content History

Submissions
Submission Date	Submitter	Organization
2023-09-19 (CWE 4.14, 2024-02-29)	Scott D. Constable	Intel Corporation
2023-09-19 (CWE 4.14, 2024-02-29)
Contributions
Contribution Date	Contributor	Organization
2024-01-22 (CWE 4.14, 2024-02-29)	David Kaplan	AMD
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett	Arm
2024-01-22 (CWE 4.14, 2024-02-29)	Members of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Jason Oberg	Cycuity
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Priya B. Iyer	Intel Corporation
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Nicole Fern	Riscure
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Common_Consequences, References, Relationships
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated References, Weakness_Ordinalities
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated References, Relationships

Weakness ID: 1461

View customized information:

Description

Extended Description

Hardware-description-language (HDL) code describes functionality which can be verified as correct using simulation tools. Synthesis tools then (automatically) convert this into a physically-realizable representation. Certain HDL code structures cannot be exactly represented, or have multiple valid representations from which the synthesis tool must choose. This can result in output which behaves differently to the (functionally-correct) HDL code. These "simulation/synthesis mismatches" may have security consequences.

Common Consequences

Impact	Details
Varies by Context	Scope: Other The consequences depend on the affected hardware behavior. The synthesized implementation may make different control decisions, incorrectly update protected state, expose data, or fail to enforce restrictions that appeared to operate correctly during HDL simulation.

Potential Mitigations

Phase(s)

Mitigation

Implementation & Physical Design (Hardware)

Establish and enforce HDL coding and review practices that minimize differences between simulation semantics and synthesis interpretation. Avoid HDL constructs, synthesis directives, and tool-dependent behaviors known to cause simulation/synthesis mismatch, with particular attention to security-relevant logic.

Effectiveness: High

Note:

Avoidance of the patterns of code which can result in these errors removes the opportunity for error. However, in some cases (notably state machine encodings) this can be very difficult to achieve efficiently.

Implementation & Physical Design (Hardware)

For security-critical logic, preserve intentional redundancy that is required for security. Examples may include redundant logic, triple modular redundancy (TMR) structures, Hamming-distance state encodings, or state-machine recovery logic. Use synthesis constraints, preservation attributes, carefully controlled structural implementation, or manual implementation of selected critical blocks to prevent this redundancy from being merged, re-encoded, or optimized away.

Effectiveness: High

Note:

This mitigation removes the structures which cause the problem, at the expense of additional design and verification effort, and additional risk of inclusion of other functional errors.

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	435	Improper Interaction Between Multiple Correctly-Behaving Entities

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1199	General Circuit and Logic Design Concerns
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1208	Cross-Cutting Problems

Modes Of Introduction

Phase(s)	Note
Implementation & Physical Design (Hardware)	This weakness can be introduced when HDL constructs, assignment ordering, synthesis directives, or tool-dependent semantics are used whose simulation behavior may not match synthesis interpretation. These constructs may behave correctly during HDL simulation but produce different security-relevant behavior in the synthesized implementation.
Implementation & Physical Design (Hardware)	This weakness can be introduced or exposed during synthesis when the synthesis tool applies assumptions, optimizations, or transformations to HDL structures that cannot be physically implemented exactly as the simulation semantics dictate, or that permit multiple (valid) hardware implementations. The resulting netlist may behave differently from the model that was verified during simulation.

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Verilog (Undetermined Prevalence) VHDL (Undetermined Prevalence) Class: Hardware Description Language (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: System on Chip (Undetermined Prevalence)

Demonstrative Examples

Example 1

A hardware designer implements an access control latch which takes in lock and unlock signals (which are only active for a single cycle) and a reset signal, and outputs an unlocked state signal. During operation, the unlocked signal is synchronously set high by the unlock input and set low by the lock input. The unlocked signal also intended to be low from startup and set low by reset.

(bad code)

Example Language: Verilog

			module lock_control (

			  input  wire clk,

			  input  wire reset,

			  input  wire lock,

			  input  wire unlock,

			  output reg  unlocked

			);

			  reg unlocked_next = 1'b0;

			  always @(lock or unlock or unlocked) begin

				if (reset == 1'b1) begin

				  unlocked_next = 1'b1; 

				end else if (lock == 1'b1) begin

				  unlocked_next = 1'b0; 

				end else if (unlock == 1'b1) begin

				  unlocked_next = 1'b1; 

				end else begin

				  unlocked_next = unlocked; 

				end

			  end

			  always @(posedge clk) begin

				unlocked <= unlocked_next;

			  end

			endmodule

The following VHDL example is written for VHDL-93 or later.

(bad code)

Example Language: VHDL

			library ieee;

			use ieee.std_logic_1164.all;

			entity lock_control is

			  port (

				clk      : in  std_logic;

				reset    : in  std_logic;

				lock     : in  std_logic;

				unlock   : in  std_logic;

				unlocked : out std_logic

			  );

			end entity lock_control;

			architecture behavioral of lock_control is

			  signal unlocked_reg  : std_logic:=’0’;

			  signal unlocked_next : std_logic;

			begin

			  process(lock, unlock, unlocked_reg)

			  begin

				if reset = '1' then

                  unlocked_next <= '1';

				elsif lock = '1' then

                  unlocked_next <= '0';

				elsif unlock = '1' then

                  unlocked_next <= '1';

				else

                  unlocked_next <= unlocked_reg;

				end if;

			  end process;

			  process(clk)

			  begin

				if rising_edge(clk) then

                  unlocked_reg <= unlocked_next;

				end if;

			  end process;

			  unlocked <= unlocked_reg;

			end architecture behavioral;

The always block is intended to describe combinational logic for unlocked_next, which depends on four signals (lock, unlock, unlocked and reset). However, the sensitivity list is missing reset.

During pre-synthesis RTL simulation, this tells the simulator not to rerun the block when reset changes (only when the other signals change). The signal unlocked_next defaults to 1’b0 so the simulation sees the expected locked state and so the tests of the state after reset will pass.

Synthesis tools assume a complete sensitivity list and will therefore infer logic including the reset signal. When reset is high, the unlocked _next signal is (erroneously) set to 1’b1. This is a bug (as reset should force a non-unlocked state), which would be expected to be found in simulation. The design uses a two-process state machine style which masks this bug in the code during simulation, but allows it to propagate to the synthesized implementation.

The synthesized hardware exits reset in an insecure state (with unlocked set to 1’b1) and remains in that state until one of the lock/unlock signals changes state. An adversary can take advantage of this by exploiting whatever logic makes use of this signal to set itself to a secure state.

(good code)

Example Language: Algorithm

			For combinational logic, ensure that simulation is
			triggered by every signal read by the block. This can be
			done by listing both inputs explicitly, but this is not
			recommended.
			

			A safer and more maintainable approach is to use (in
			Verilog) always @*, which tells the simulator to include
			all signals used inside the block. In SystemVerilog, use
			always_comb. In VHDL use process(all).
			

Example 2

A hardware developer is debugging logic which requires the system to be in an unprotected mode. In order to enable their work, they have (temporarily) removed some code related to the "protected_mode_enabled" flag in a way that does not cause the simulations to fail.

(bad code)

Example Language: VHDL

                                
			-- The following VHDL example is written for VHDL-93 or later.

			signal secure     : boolean; -- implicitly initialized to ‘false’

			signal policy_ok  : boolean;

			signal lock_ready : boolean;

			...

			-- synthesis translate_off

			secure <= security_check(policy_ok, lock_ready); -- TODO: restore this after debugging

			-- synthesis translate_on

			protected_mode_enabled <= secure;

(bad code)

Example Language: Verilog

			reg secure; 

			wire policy_ok;

			wire lock_ready;

			wire protected_mode_enabled;

			...

			always @(*) begin

			  secure = 1'b0; // default value

			  // synopsys translate_off

			  secure = security_check(policy_ok, lock_ready); // TODO: restore this after debugging

			  // synopsys translate_on

			end

			assign protected_mode_enabled = secure;

The design assigns the security-relevant secure signal using logic that is hidden from synthesis by translate_off / translate_on or equivalent synthesis exclusion directives. Simulation tools treat these directives as comments and include the enclosed assignment, so simulation updates secure according to security_check(policy_ok, lock_ready) and appears to validate the intended protected-mode behavior.

Synthesis tools omit the code between the exclusion directives. The synthesized implementation therefore does not contain the same assignment that was exercised during simulation. This creates a simulation/synthesis mismatch in security-relevant behavior: the HDL model used for verification enables or disables protected mode using logic that is absent from the synthesized hardware.

Because the synthesized implementation does not include the same logic that was present during simulation, the hardware defaults to an insecure state. An attacker can take advantage of this to execute activities which would normally require some form of authorization, even though simulation results suggested that protected mode would be enforced.

(good code)

Example Language: Algorithm

		  Do not place security-relevant assignments inside
		  synthesis-excluded regions. Any logic that affects
		  protected-mode behavior should be represented consistently
		  in both simulation and synthesis.
		  

		  Limit synthesis translate_off / translate_on regions to
		  simulation-only code that cannot assign, modify, override,
		  or mask security-sensitive signals.
		  

		  Carefully review all uses of translate_on/off directives.
		  Ensure that developers can efficiently authorize their
		  activities during development work, to avoid the temptation
		  to bypass security features in this way.
		  

(good code)

Example Language: VHDL

                                
		  -- The following VHDL example is written for VHDL-93 or later.

		  signal secure     : boolean; -- implicitly initialized to ‘false’

		  signal policy_ok  : boolean;

		  signal lock_ready : boolean;

		  ...

		  secure <= security_check(policy_ok, lock_ready);

		  protected_mode_enabled <= secure;

(good code)

Example Language: Verilog

		  reg secure;

		  wire policy_ok;

		  wire lock_ready;

		  wire protected_mode_enabled;

		  ...

		  always @(*) begin

			secure = security_check(policy_ok, lock_ready);

		  end

		  assign protected_mode_enabled = secure;

Example 3

A hardware developer is designing a controller that manages whether protected configuration registers can be written. The controller includes states for reset handling, user-level operation, and privileged operation.

(bad code)

Example Language: VHDL

		  -- The following VHDL example is written for VHDL-93 or later.

		  type t_priv_state is (RESET, USER_ONLY, PRIVILEGED);

		  signal priv_state       : t_priv_state := RESET;

		  signal auth_passed      : boolean := false;

		  signal privilege_revoke : boolean := false;

		  ...

		  process(clk, reset_n)

		  begin

			if reset_n = '0' then

			  priv_state <= RESET;

			elsif rising_edge(clk) then

			  case priv_state is

				when RESET =>

				  priv_state <= USER_ONLY;

				when USER_ONLY =>

				  if auth_passed then

					priv_state <= PRIVILEGED;

				  end if;

				when PRIVILEGED =>

				  if privilege_revoke then

					priv_state <= USER_ONLY;

				  end if;

				when others =>

				  priv_state <= USER_ONLY; -- intended recovery for unexpected encodings

				end case;

			  end if;

			end process;

			protected_cfg_write_en <= (priv_state = PRIVILEGED);

(bad code)

Example Language: Verilog

			localparam RESET      = 2'b00;

			localparam USER_ONLY  = 2'b01;

			localparam PRIVILEGED = 2'b10;

			reg [1:0] priv_state    = RESET;

			wire      auth_passed;       // Implicitly 1-bit (boolean equivalent)

			wire      privilege_revoke;  // Implicitly 1-bit (boolean equivalent)

			wire      clk;

			wire      reset_n;

			wire      protected_cfg_write_en;

			...

			always @(posedge clk or negedge reset_n) begin

			  if (!reset_n) begin

				priv_state <= RESET;

			  end else begin

				case (priv_state)

				  RESET: begin

					priv_state <= USER_ONLY;

				  end

				  USER_ONLY: begin

					if (auth_passed) begin

                      priv_state <= PRIVILEGED;

					end

				  end

				  PRIVILEGED: begin

					if (privilege_revoke) begin

                      priv_state <= USER_ONLY;

					end

				  end

				  default: begin

					priv_state <= USER_ONLY; // intended recovery for unexpected encodings

				  end

				endcase

			  end

			end

			assign protected_cfg_write_en = (priv_state == PRIVILEGED);

The design relies on a VHDL others choice or Verilog default branch to express recovery behavior for state values not explicitly listed in the state transition logic. In RTL simulation, the intended behavior is that unexpected controller states will transition to USER_ONLY, where protected configuration writes are blocked.

The error is assuming that this RTL-level recovery behavior will necessarily be preserved after synthesis. During synthesis, the state machine may be encoded, optimized, or transformed based on the states considered reachable during normal operation. As a result, logic associated with unused or faulty hardware encodings may be removed or altered, and the synthesized implementation may not preserve the same recovery behavior that appeared in RTL simulation.

If the synthesized implementation does not preserve the unexpected-state recovery behavior, the hardware may fail to return to USER_ONLY after a fault, reset anomaly, voltage glitch, clock disturbance, or other condition that places the state storage into an unintended encoding.

An attacker who can induce or influence such conditions may be able to leave protected configuration writes enabled, or cause them to become enabled, even though simulation suggested that unexpected state values would be forced into a state where those writes are blocked.

(good code)

Example Language: Algorithm

			  Do not rely on a VHDL others choice or Verilog default
			  branch to guarantee post-synthesis recovery behavior for
			  security-critical state machines. If recovery from
			  unexpected state encodings affects access to protected
			  configuration registers, the implementation should not
			  depend on synthesis inferring and preserving that
			  behavior from RTL alone.
			

			  For this type of security-critical controller, implement
			  the state machine using a carefully-controlled
			  structural or hand-synthesized representation where the
			  relevant state elements, reset behavior, transition
			  logic, and fail-closed recovery behavior are
			  explicit. Be careful that the synthesiser does not infer
			  a state machine from the crafted logic, and “undo” the
			  work. Review the resulting gate-level or structural
			  implementation to confirm that unintended encodings are
			  handled as required.

			  Perform post-synthesis simulations where faults are
			  injected into the state registers and confirm the
			  behavior.

			  Perform formal analysis to prove that the behavior of
			  these critical blocks has not been altered by the
			  synthesis process.

			  After the implementation is verified and validated,
			  preserve it during integration so later synthesis or
			  whole-design optimization does not re-encode, merge,
			  remove, or otherwise transform the security-critical
			  recovery logic.

			  This approach is costly and design-specific, but it is
			  appropriate when relying on ordinary RTL synthesis would
			  create unacceptable security risk.
			

Selected Observed Examples

Reference	Description
CVE-2025-51678	The synthesized netlist incorrectly calculates memory addresses and fetches co-processor instructions, potentially causing unintended memory accesses or incorrect custom-instruction execution.
CVE-2025-51677	Debug-load requests should return complete load store unit (LSU) data, but the synthesized netlist returned incomplete data, potentially causing incorrect interpretation of memory state.
CVE-2025-51679	Instruction execution should update program-counter state correctly, but the synthesized netlist produced incomplete or undefined updates, potentially causing unintended control flow.
CVE-2025-51675	The program counter should update when the next-program-counter value changes, but the synthesized netlist allowed stale PC state, potentially causing incorrect instruction fetches or stalls.

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses) This is a resultant weakness as the primary would be something like bad RTL coding practices or Synthesis optimization that then would result in a mismatch.

Detection Methods

Method	Details
Automated Static Analysis - Source Code	HDL linting, rule-based static analysis, and HDL checker tools can examine source code for structures that may be interpreted differently by simulation and synthesis tools. They may identify synthesis-sensitive coding patterns associated with this weakness. Effectiveness: Moderate Note: This method can be useful for detecting potential coding issues, but it may not reveal whether these constructs result in observable behavioral divergence after synthesis. Moreover, a user may suppress or bypass these warnings and still produce the erroneous synthesized hardware implementation. This method can give false positives.
Manual Analysis	Synthesis warning review can examine synthesis logs and reports for tool messages associated with possible simulation/synthesis mismatch. It may identify ignored constructs, unsupported HDL semantics, synthesis assumptions, or optimizations that could affect security-relevant behavior. Effectiveness: Limited Note: Can reveal potential synthesis issues but relies on engineers interpreting warnings. Moreover, a user may suppress or bypass these warnings and still produce the erroneous synthesized hardware implementation.
Formal Verification	HDL-source-to-netlist formal equivalence checking can examine the simulated model and synthesized netlist for behavioral mismatch associated with this weakness. It may identify non-equivalent outputs, failed compare-points, state-mapping issues, or counterexamples under the checked constraints. Effectiveness: High Note: Formal equivalence checking can be effective at the IP level for identifying mismatches between the source-code model and synthesized implementation. However, effectiveness may decrease as design complexity grows, particularly at the SoC level, due to state-space expansion and difficulty mapping non-equivalent points. Synthesis optimizations may merge, eliminate, or rename signals, which can also produce false positives or require additional setup to account for expected transformations.
Simulation / Emulation	Cross-simulation across HDL-source and post-synthesis models can examine both abstraction levels for observable behavioral divergence associated with this weakness. It may identify mismatches when security-relevant behaviors are explicitly exercised. Effectiveness: High Note: This method can be useful for detecting observable behavioral mismatches, but it may not exercise all execution scenarios and should be combined with other detection methods to improve coverage.
Fuzzing	Coverage-guided differential fuzzing can examine HDL source code and synthesized implementation models for behavioral divergence associated with this weakness. It may identify generated inputs or state conditions that expose synthesis-induced mismatches. Effectiveness: High Note: This method can be useful for detecting previously unknown synthesis-induced behavioral mismatches by exploring diverse execution paths through coverage-guided input generation. However, it may not exercise every reachable design state and should be combined with other detection methods to improve coverage.

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1398	Comprehensive Categorization: Component Interaction

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)
Reasons	Frequently-Resultant, 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	Since this entry is often resultant, there might be other CWEs that are more appropriate as the root cause, although there might be some gaps. Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

References

[REF-1552]	Don Mills and Clifford E. Cummings. "RTL Coding Styles That Yield Simulation and Synthesis Mismatches". 1999. <https://www.researchgate.net/profile/Clifford-Cummings/publication/228554783_RTL_Coding_Styles_That_Yield_Simulation_and_Synthesis_Mismatches/links/54bfe9760cf21674ce9ca726/RTL-Coding-Styles-That-Yield-Simulation-and-Synthesis-Mismatches.pdf>.
[REF-1553]	Raghul Saravanan, Sudipta Paria, Aritra Dasgupta, Venkat Nitin Patnala, Swarup Bhunia and Sai Manoj P. D.. "SynFuzz: Leveraging Fuzzing of Netlist to Detect Synthesis Bugs". 2025-04-26. <https://arxiv.org/abs/2504.18812>.
[REF-1554]	Mike Turpin. "The Dangers of Living with an X (bugs hidden in your Verilog)". 2003-10-14. <https://developer.arm.com/documentation/arp0009/a/?lang=en>.
[REF-1555]	Stuart Sutherland and Don Mills. "Standard Gotchas: Subtleties in the Verilog and SystemVerilog Standards That Every Engineer Should Know". 2006. <https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_paper.pdf>.
[REF-1556]	Flavien Solt and Kaveh Razavi. "Lost in Translation: Enabling Confused Deputy Attacks on EDA Software with TransFuzz". 2025-08. <https://www.usenix.org/conference/usenixsecurity25/presentation/solt>. (URL validated: 2026-10-19) Media types: Common-Proprietary-Text; Video
[REF-1557]	Don Mills. "Yet Another Latch and Gotchas Paper". 2012. <https://lcdm-eng.com/papers/snug12_Paper_final.pdf>.
[REF-1558]	Clifford E. Cummings. "“full_case parallel_case”, the Evil Twins of Verilog Synthesis". 1999. <https://csg.csail.mit.edu/6.375/6_375_2009_www/papers/cummings-case-snug99.pdf>.

Content History

Submissions
Submission Date	Submitter	Organization
2025-05-20 (CWE 5.0, 2026-10-28)	Raghul Saravanan	George Mason University
2025-05-20 (CWE 5.0, 2026-10-28)
2025-05-20 (CWE 5.0, 2026-10-28)	Sudipta Paria	University of Florida
2025-05-20 (CWE 5.0, 2026-10-28)
Contributions
Contribution Date	Contributor	Organization
2026-03-30 (CWE 5.0, 2026-10-28)	CWE Ad Hoc RTL WG
2026-03-30 (CWE 5.0, 2026-10-28)	Participated in a series of meetings betwee March 2026 and September 26, in which members contributed significant feedback related to this entry as it evolved before publication in CWE 5.0.
2026-03-30 (CWE 5.0, 2026-10-28)	MITRE
2026-03-30 (CWE 5.0, 2026-10-28)	Guided evolution of the name and description for this entry, followed by suggestions for mitigations, demonstrative examples, and detection methods. Note: some content development was AI-assisted, with expert review and editing by MITRE and members of the CWE Ad Hoc RTL WG.

Weakness ID: 1300

View customized information:

Description

Extended Description

Physical side channels have been well-studied for decades in the context of breaking implementations of cryptographic algorithms or other attacks against security features. These side channels may be easily observed by an adversary with physical access to the device, or using a tool that is in close proximity. If the adversary can monitor hardware operation and correlate its data processing with power, EME, and acoustic measurements, the adversary might be able to recover of secret keys and data.

Common Consequences

Impact	Details
Read Memory; Read Application Data	Scope: Confidentiality An adversary could monitor and measure physical phenomena to detect patterns and make inferences, even if it is not possible to extract the information in the digital domain.

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	Apply blinding or masking techniques to implementations of cryptographic algorithms.
Implementation	Add shielding or tamper-resistant protections to the device to increase the difficulty of obtaining measurements of the side-channel.

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	203	Observable Discrepancy
	ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	1255	Comparison Logic is Vulnerable to Power Side-Channel Attacks

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1205	Security Primitives and Cryptography Issues
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1388	Physical Access Issues and Concerns

Modes Of Introduction

Phase(s)	Note
Implementation

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

Consider a device that checks a passcode to unlock the screen.

(bad code)

Example Language: Algorithm

                                As each character of
		    the PIN number is entered, a correct character
		    exhibits one current pulse shape while an
		    incorrect character exhibits a different current
		    pulse shape.
                            

PIN numbers used to unlock a cell phone should not exhibit any characteristics about themselves. This creates a side channel. An attacker could monitor the pulses using an oscilloscope or other method. Once the first character is correctly guessed (based on the oscilloscope readings), they can then move to the next character, which is much more efficient than the brute force method of guessing every possible sequence of characters.

(good code)

Example Language: Algorithm

                                Rather than comparing
		    each character to the correct PIN value as it is
		    entered, the device could accumulate the PIN in a
		    register, and do the comparison all at once at the
		    end. Alternatively, the components for the
		    comparison could be modified so that the current
		    pulse shape is the same regardless of the
		    correctness of the entered
		    character.
                            

Example 2

Consider the device vulnerability CVE-2021-3011, which affects certain microcontrollers [REF-1221]. The Google Titan Security Key is used for two-factor authentication using cryptographic algorithms. The device uses an internal secret key for this purpose and exchanges information based on this key for the authentication. If this internal secret key and the encryption algorithm were known to an adversary, the key function could be duplicated, allowing the adversary to masquerade as the legitimate user.

(bad code)

Example Language: Other

                                The local method of extracting the secret key consists of plugging the key into a USB port and using electromagnetic (EM) sniffing tools and computers.
                            

(good code)

Example Language: Other

                                Several solutions could have been considered by the manufacturer. For example, the manufacturer could shield the circuitry in the key or add randomized delays, indirect calculations with random values involved, or randomly ordered calculations to make extraction much more difficult. The manufacturer could use a combination of these techniques.
                            

Example 3

The code snippet provided here is part of the modular exponentiation module found in the HACK@DAC'21 Openpiton System-on-Chip (SoC), specifically within the RSA peripheral [REF-1368]. Modular exponentiation, denoted as "a^b mod n," is a crucial operation in the RSA public/private key encryption. In RSA encryption, where 'c' represents ciphertext, 'm' stands for a message, and 'd' corresponds to the private key, the decryption process is carried out using this modular exponentiation as follows: m = c^d mod n, where 'n' is the result of multiplying two large prime numbers.

(bad code)

Example Language: SystemVerilog

                                
				...

				module mod_exp

					...

					`UPDATE: begin

						if (exponent_reg != 'd0) begin
if (exponent_reg[0])

								result_reg <= result_next;

							base_reg <= base_next;

							exponent_reg <= exponent_next;

							state <= `UPDATE;

					...

				endmodule

The vulnerable code shows a buggy implementation of binary exponentiation where it updates the result register (result_reg) only when the corresponding exponent bit (exponent_reg[0]) is set to 1. However, when this exponent bit is 0, the output register is not updated. It's important to note that this implementation introduces a physical power side-channel vulnerability within the RSA core. This vulnerability could expose the private exponent to a determined physical attacker. Such exposure of the private exponent could lead to a complete compromise of the private key.

To address mitigation requirements, the developer can develop the module by minimizing dependency on conditions, particularly those reliant on secret keys. In situations where branching is unavoidable, developers can implement masking mechanisms to obfuscate the power consumption patterns exhibited by the module (see good code example). Additionally, certain algorithms, such as the Karatsuba algorithm, can be implemented as illustrative examples of side-channel resistant algorithms, as they necessitate only a limited number of branch conditions [REF-1369].

(good code)

Example Language: SystemVerilog

                                
			...

				module mod_exp

					...

					`UPDATE: begin

						if (exponent_reg != 'd0) begin
if (exponent_reg[0]) begin

								result_reg <= result_next;

end else begin

								mask_reg <= result_next;

end

							base_reg <= base_next;

							exponent_reg <= exponent_next;

							state <= `UPDATE;

					...

				endmodule

Selected Observed Examples

Reference	Description
CVE-2022-35888	Power side-channels leak secret information from processor
CVE-2021-3011	electromagnetic-wave side-channel in security-related microcontrollers allows extraction of private key
CVE-2019-14353	Crypto hardware wallet's power consumption relates to total number of pixels illuminated, creating a side channel in the USB connection that allows attackers to determine secrets displayed such as PIN numbers and passwords
CVE-2020-27211	Chain: microcontroller system-on-chip uses a register value stored in flash to set product protection state on the memory bus, but it does not contain protection against fault injection (CWE-1319), which leads to an incorrect initialization of the memory bus (CWE-1419), leading the product to be in an unprotected state.
CVE-2013-4576	message encryption software uses certain instruction sequences that allow RSA key extraction using a chosen-ciphertext attack and acoustic cryptanalysis
CVE-2020-28368	virtualization product allows recovery of AES keys from the guest OS using a side channel attack against a power/energy monitoring interface.
CVE-2019-18673	power consumption varies based on number of pixels being illuminated in a display, allowing reading of secrets such as the PIN by using the USB interface to measure power consumption

Weakness Ordinalities

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

Detection Methods

Method

Details

Manual Analysis

Perform a set of leakage detection tests such as the procedure outlined in the Test Vector Leakage Assessment (TVLA) test requirements for AES [REF-1230]. TVLA is the basis for the ISO standard 17825 [REF-1229]. A separate methodology is provided by [REF-1228]. Note that sole reliance on this method might not yield expected results [REF-1239] [REF-1240].

Effectiveness: Moderate

Manual Analysis

Post-silicon, perform full side-channel attacks (penetration testing) covering as many known leakage models as possible against test code.

Effectiveness: Moderate

Manual Analysis

Pre-silicon - while the aforementioned TVLA methods can be performed post-silicon, models of device power consumption or other physical emanations can be built from information present at various stages of the hardware design process before fabrication. TVLA or known side-channel attacks can be applied to these simulated traces and countermeasures applied before tape-out. Academic research in this field includes [REF-1231] [REF-1232] [REF-1233].

Effectiveness: Moderate

Functional Areas

Power

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1343	Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1417	Comprehensive Categorization: Sensitive Information Exposure
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1432	Weaknesses in the 2025 CWE Most Important Hardware Weaknesses List

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-189	Black Box Reverse Engineering
CAPEC-699	Eavesdropping on a Monitor

References

[REF-1117]	Paul Kocher, Joshua Jaffe and Benjamin Jun. "Introduction to differential power analysis and related attacks". 1998. <https://www.rambus.com/wp-content/uploads/2015/08/DPATechInfo.pdf>.
[REF-1118]	Dakshi Agrawal, Bruce Archambeault, Josyula R. Rao and Pankaj Rohatgi. "The EM Side-Channel(s)". 2007-08-24. <https://link.springer.com/content/pdf/10.1007/3-540-36400-5_4.pdf>. (URL validated: 2023-04-07)
[REF-1119]	Daniel Genkin, Adi Shamir and Eran Tromer. "RSA key extraction via low-bandwidth acoustic cryptanalysis". 2014-06-13. <https://www.iacr.org/archive/crypto2014/86160149/86160149.pdf>.
[REF-1120]	Colin O'Flynn. "Power Analysis for Cheapskates". 2013-01-24. <https://media.blackhat.com/eu-13/briefings/OFlynn/bh-eu-13-for-cheapstakes-oflynn-wp.pdf>.
[REF-1055]	Peter Gutmann. "Data Remanence in Semiconductor Devices". 10th USENIX Security Symposium. 2001-08. <https://www.usenix.org/legacy/events/sec01/full_papers/gutmann/gutmann.pdf>.
[REF-1218]	Graham Cluley. "This Black Box Can Brute Force Crack iPhone PIN Passcodes". The Mac Security Blog. 2015-03-16. <https://www.intego.com/mac-security-blog/iphone-pin-pass-code/>.
[REF-1221]	Victor Lomne and Thomas Roche. "A Side Journey to Titan". 2021-01-07. <https://web.archive.org/web/20210107182441/https://ninjalab.io/wp-content/uploads/2021/01/a_side_journey_to_titan.pdf>. (URL validated: 2023-04-07)
[REF-1228]	Gilbert Goodwill, Benjamin Jun, Josh Jaffe and Pankaj Rohatgi. "A testing methodology for side-channel resistance validation". 2011. <https://csrc.nist.gov/csrc/media/events/non-invasive-attack-testing-workshop/documents/08_goodwill.pdf>.
[REF-1229]	ISO/IEC. "ISO/IEC 17825:2016: Testing methods for the mitigation of non-invasive attack classes against cryptographic modules". 2016. <https://www.iso.org/standard/60612.html>.
[REF-1230]	Cryptography Research Inc.. "Test Vector Leakage Assessment (TVLA) Derived Test Requirements (DTR) with AES". 2015-08. <https://www.rambus.com/wp-content/uploads/2015/08/TVLA-DTR-with-AES.pdf>.
[REF-1231]	Danilo Šijaˇci´, Josep Balasch, Bohan Yang, Santosh Ghosh and Ingrid Verbauwhede. "Towards efficient and automated side-channel evaluations at design time". pp. 305-319. Journal of Cryptographic Engineering, 10(4). 2020. <https://www.esat.kuleuven.be/cosic/publications/article-3204.pdf>.
[REF-1232]	Amit Kumar, Cody Scarborough, Ali Yilmaz and Michael Orshansky. "Efficient simulation of EM side-channel attack resilience". pp. 123-130. IEEE/ACM International Conference on Computer-Aided Design (ICCAD). 2017. <https://dl.acm.org/doi/pdf/10.5555/3199700.3199717>. (URL validated: 2025-07-29)
[REF-1233]	Yuan Yao, Tuna Tufan, Tarun Kathuria, Baris Ege, Ulkuhan Guler and Patrick Schaumont. "Pre-silicon Architecture Correlation Analysis (PACA): Identifying and Mitigating the Source of Side-channel Leakage at Gate-level". IACR Cryptology ePrint Archive. 2021-04-21. <https://eprint.iacr.org/2021/530.pdf>.
[REF-1234]	Elisabeth Oswald, Thomas Popp and Stefan Mangard. "Power Analysis Attacks - Revealing the Secrets of Smart Cards". 2007. <https://link.springer.com/book/10.1007/978-0-387-38162-6>. (URL validated: 2023-04-07)
[REF-1235]	David Oswald, Bastian Richter and Christof Paar. "Side-Channel Attacks on the Yubikey 2 One-Time Password Generator". 2013-06-14. <https://informatik.rub.de/veroeffentlichungenbkp/seceng/veroeffentlichungen/2013/pdfs/2013_Side_Channel_Attacks_on_the_Yubikey_2_One-Time_Password_Generator.pdf>. (URL validated: 2025-07-29)
[REF-1239]	François-Xavier Standaert. "How (not) to Use Welch's T-test in Side-Channel Security Evaluations". IACR Cryptology ePrint Archive. 2017-02-15. <https://eprint.iacr.org/2017/138.pdf>.
[REF-1240]	Carolyn Whitnall and Elisabeth Oswald. "A Critical Analysis of ISO 17825 ('Testing methods for the mitigation of non-invasive attack classes against cryptographic modules')". IACR Cryptology ePrint Archive. 2019-09-10. <https://eprint.iacr.org/2019/1013.pdf>.
[REF-1285]	Texas Instruments. "Physical Security Attacks Against Silicon Devices". 2022-01-31. <https://www.ti.com/lit/an/swra739/swra739.pdf?ts=1644234570420>.
[REF-1286]	Lennert Wouters, Benedikt Gierlichs and Bart Preneel. "On The Susceptibility of Texas Instruments SimpleLink Platform Microcontrollers to Non-Invasive Physical Attacks". 1.2 / 5. 2022-03-14. <https://eprint.iacr.org/2022/328.pdf>.
[REF-1368]	"mod_exp.v". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/b9ecdf6068445d76d6bee692d163fededf7a9d9b/piton/design/chip/tile/ariane/src/rsa/mod_exp.v#L46:L47>. (URL validated: 2023-07-15)
[REF-1369]	"Fix CWE-1300". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/37e42f724c14b8e4cc8f6e13462c12a492778219/piton/design/chip/tile/ariane/src/rsa/mod_exp.v#L47:L51>. (URL validated: 2023-09-29)

Content History

Submissions
Submission Date	Submitter	Organization
2020-05-29 (CWE 4.2, 2020-08-20)	Nicole Fern	Cycuity (originally submitted as Tortuga Logic)
2020-05-29 (CWE 4.2, 2020-08-20)
Contributions
Contribution Date	Contributor	Organization
2023-06-21 (CWE 4.14, 2024-02-29)	Chen Chen, Rahul Kande, Jeyavijayan Rajendran	Texas A&M University
2023-06-21 (CWE 4.14, 2024-02-29)	suggested demonstrative example
2023-06-21 (CWE 4.14, 2024-02-29)	Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza Sadeghi	Technical University of Darmstadt
2023-06-21 (CWE 4.14, 2024-02-29)	suggested demonstrative example
2021-10-13 (CWE 4.6, 2021-10-28)	Nicole Fern	Riscure
2021-10-13 (CWE 4.6, 2021-10-28)	Provided detection methods, observed examples, and references
2021-10-11 (CWE 4.6, 2021-10-28)	Anders Nordstrom, Alric Althoff	Cycuity (originally submitted as Tortuga Logic)
2021-10-11 (CWE 4.6, 2021-10-28)	Provided detection methods, observed examples, and references
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, References, Relationships
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated References, Relationships
2025-04-03 (CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
2025-04-03 (CWE 4.17, 2025-04-03)	updated Demonstrative_Examples
2023-10-26 (CWE 4.13, 2023-10-26)	CWE Content Team	MITRE
2023-10-26 (CWE 4.13, 2023-10-26)	updated Demonstrative_Examples, Observed_Examples, References
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Mapping_Notes
2023-04-27 (CWE 4.11, 2023-04-27)	CWE Content Team	MITRE
2023-04-27 (CWE 4.11, 2023-04-27)	updated References, Relationships
2023-01-31 (CWE 4.10, 2023-01-31)	CWE Content Team	MITRE
2023-01-31 (CWE 4.10, 2023-01-31)	updated Related_Attack_Patterns
2022-10-13 (CWE 4.9, 2022-10-13)	CWE Content Team	MITRE
2022-10-13 (CWE 4.9, 2022-10-13)	updated References, Relationships
2022-06-28 (CWE 4.8, 2022-06-28)	CWE Content Team	MITRE
2022-06-28 (CWE 4.8, 2022-06-28)	updated Relationships
2021-10-28 (CWE 4.6, 2021-10-28)	CWE Content Team	MITRE
2021-10-28 (CWE 4.6, 2021-10-28)	updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Observed_Examples, References, Relationships, Weakness_Ordinalities
2021-07-20 (CWE 4.5, 2021-07-20)	CWE Content Team	MITRE
2021-07-20 (CWE 4.5, 2021-07-20)	updated Related_Attack_Patterns
2021-03-15 (CWE 4.4, 2021-03-15)	CWE Content Team	MITRE
2021-03-15 (CWE 4.4, 2021-03-15)	updated Functional_Areas, Maintenance_Notes
Previous Entry Names
Change Date	Previous Entry Name
2021-10-28	Improper Protection Against Physical Side Channels

Weakness ID: 1476

View customized information:

Description

Technical Nuance

Here, the word "speculatively" refers to the fact that the interconnect propagates the request assuming that the manager will at some point provide the data, thus releasing the use of the bus.

Common Consequences

Impact

Details

DoS: Prevent Access

Scope: Availability

Likelihood: High

The technical impact could include Memory-access delays, I/O access delays, deadline miss, etc.

The attacker can leverage this weakness to generate unbounded delays and denial of service (DoS) in the access of shared resources. The system interconnect might be left in an inconsistent state, requiring a partial or full reset of the network, according to the implementation. The scenario may play out as follows. The interconnect receives a write request from a controller initiator (e.g., sending the header to the interconnect for writing N words of data, with N ranging from 1 to the maximum burst length allowed). The interconnect then speculatively propagates the request to the target peripheral through the shared bus before the corresponding data are received at the interconnect. Here, the word "speculatively" refers to the fact that the interconnect propagates the request, assuming that the controller will at some point provide the data, thus releasing the use of the bus. This speculatively reserves the bus to the manager transaction issuer, which is left free to delay its data provisioning phase. This reserves the whole bus path between the initiator and the target peripheral until all of the words associated with the request are provided by the controller. If the interconnect assumes a cooperative behavior from the controller, it is implicitly trusting that the controller will complete the transaction and release the bus for use from the other controllers. A malicious, faulty, or misbehaving manager module can generate a denial-of-service condition in preventing access to the write data link from all of the other managers in the system, and unboundedly inhibit the write access to one or multiple peripherals in the system (i.e., memories, I/Os, etc.).

Potential Mitigations

Phase(s)

Mitigation

Hardware Architecture (Hardware); Hardware Microarchitecture (Hardware)

SoC architects can use a switching methodology stopping stalls from being propagated to the interconnect, such as Cut-and-Forward [REF-1585][REF-1587] or Store-and-Forward. Alternatively, a monitoring and recovery module can be added between the interconnect and each manager module to detect stalls introduced by the module and restore a safe state in the interconnect after a stall has been detected [REF-1586].

Effectiveness: High

Note:

The architect should evaluate which methodology better suits the target platform, trading off performance and resource consumption impact [REF-1585][REF-1586][REF-1587].

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	841	Improper Enforcement of Behavioral Workflow
	Overlaps	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1264	Hardware Logic with Insecure De-Synchronization between Control and Data Channels

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1203	Peripherals, On-chip Fabric, and Interface/IO Problems

Background Details

Some products may use an architecture with a shared bus that is accessible by multiple devices, in which these devices can issue requests that utilize the shared bus. There may be an on-chip interconnect based on a protocol that manages the devices' requests to the bus and enforces the ordering of requests and data. When a device makes a request, the bus might indefinitely lock the write access to a shared output link until the initiating device finishes its transaction. If the initiating device does not finish the transaction quickly enough, this can prevent other devices from using the bus, causing a denial of service.

A "manager module" is a hardware component that initiates transactions on the interconnect, such as a processor, DMA engine, or hardware accelerator.

Modes Of Introduction

Phase(s)

Note

Hardware Requirements (Hardware)

This occurs if the on-chip communication interconnect is based on a multi-channel on-chip communication standard assuming cooperative behavior among the manager modules AND an unsafe switching methodology (e.g., cut-through) is in use. Some switching methodologies may be susceptible to this weakness in modern on-chip multi-channel communication standards, such as the cut-through switching policy, a switching methodology for high performance commonly implemented at the interconnect level. In cut-through, a request is propagated independently on the receipt at the interconnect level of the corresponding data. If the manager module issuing a write request delays the provisioning of the corresponding data, the other manager modules experience delays in accessing the bus. Such delays are capable of generating denial of service.

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Architectures	ARM (Undetermined Prevalence) Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Bus/Interface Hardware (Undetermined Prevalence) Communication Hardware (Undetermined Prevalence) Class: System on Chip (Undetermined Prevalence)

Demonstrative Examples

Example 1

In a system-on-chip, multiple hardware components may communicate with shared resources through an interconnect. A manager initiates transactions, while a target is a shared resource such as memory or a peripheral. A shared write path is the portion of the interconnect used by multiple managers to send write data to the same target.

To reduce buffering requirements and propagation latency, an interconnect may use cut-through switching. In protocols where the write request and corresponding write data are transferred independently, the interconnect can forward the request before all of the associated write data have arrived.

(a) Manager A issues a multi-word write request.
(b) The interconnect forwards the request to the shared target before receiving all corresponding write data. The shared write path is reserved for Manager A until its data transfer completes.
(c) Manager A delays or stops sending the remaining data. The transaction remains incomplete, and the shared write path remains reserved.
(d) Manager B attempts to use the same shared path but cannot proceed until Manager A completes the data transfer or a recovery mechanism safely releases the path.

In these diagrams, "reserved" refers to the shared write path serving the target, rather than every operation or route to that target.

The interconnect reserves the shared write path before the data required to complete the transaction are available. In the problematic design shown here, other managers cannot use that shared write path until the corresponding data transfer completes. Thus, the interconnect depends on Manager A to continue making forward progress. If Manager A stalls, the stall propagates into the shared portion of the interconnect and prevents competing transactions from using that shared write path.

(attack code)

A faulty or malicious manager can delay or
		stop providing the remaining write data. If the
		interconnect does not enforce bounded progress or
		provide a recovery mechanism, the manager can hold the
		shared write path indefinitely and cause a denial of
		service for competing write transactions that require
		the same shared write path.

(good code)

Example Language: Other

The interconnect should avoid reserving the
		shared write path until the data needed to complete
		the forwarded transaction are available.

One approach is store-and-forward switching the interconnect buffers the request and all corresponding write data before forwarding the request, preventing a manager's input-side stall from propagating into the shared write path. If Manager A delays or stops sending data, its incomplete transaction remains in the input buffer, and the shared write path remains available to transactions from other managers.

(a) Manager A issues a multi-word write request.
(b) The interconnect buffers the request and waits for all corresponding write data. The request has not been forwarded, and the shared write path is not yet reserved for Manager A.
(c) After all data have been received and buffered, the interconnect forwards the request to the shared target.
(d) The interconnect forwards the buffered data without waiting for additional data from Manager A. Completion of the data transfer releases the shared write path. The target completes the write and returns a response through the interconnect to Manager A.

Store-and-forward requires storage for an entire transaction, increasing buffer capacity and hardware area. It also adds buffering latency because forwarding begins only after all corresponding data have arrived. [REF-1585]

(good code)

Example Language: Other

Cut-and-forward is a second preventive approach. It divides a
		transaction into smaller transactions and forwards each only after all
		data for that chunk have been buffered. Like store-and-forward, it
		prevents a manager's data-provisioning stall from reserving the shared
		write path. [REF-1585]

		Cut-and-forward applies the same principle at a smaller chunk
		granularity.  In Figure 3, a four-word write is divided into two
		chunks of two words each. The interconnect creates the shorter
		transactions and combines their responses, so Manager A continues to
		issue and receive a response for the original transaction. [REF-1585]
		

(a) Manager A issues a four-word write request.
(b) The interconnect buffers the request and begins receiving the corresponding write data. The request has not been forwarded, so the shared write path is not yet reserved for this transaction.
(c) After the first two words have been buffered, the interconnect creates a two-word write request and forwards it with the complete first chunk to the shared target. While forwarding this chunk, the interconnect can receive and buffer the next two words.
(d) After the remaining two words have been buffered, the interconnect creates and forwards a second two-word write transaction with the complete second chunk.
(e) The shared target completes the two shorter transactions and returns a separate response for each one.
(f) The interconnect waits for both responses, combines them into the single response expected for the original transaction, and returns that response to Manager A.

The shared write path is reserved only when a complete chunk is ready. If Manager A delays data for a later chunk, the incomplete chunk remains in the input buffer; the path is not held while waiting for those data and remains available to other managers. Smaller chunks reduce buffering requirements and forwarding delay but increase target-side transaction and response overhead. Larger chunks reduce that overhead but require more buffering and increase the delay before forwarding begins. [REF-1585]

(good code)

Example Language: Other

		A watchdog with protocol-aware recovery is a third,
		separate mitigation approach. It limits the duration
		of a stall by restoring the shared path to a usable
		state. It does not prevent the stall from entering the
		shared path: other managers may remain blocked until
		detection and recovery complete. Detection alone does
		not release the path. [REF-1586]

The behavior illustrated here has been demonstrated in AXI-based interconnects. The weakness is not inherently specific to AXI and can arise in other interconnect protocols with equivalent request/data separation, ordering, resource-commitment, and progress properties. The diagrams omit signal-level details to focus on the shared write path and transaction sequence. [REF-1585][REF-1586]

Selected Observed Examples

Reference	Description
[REF-1586]	Certain commercial AXI interconnect IPs could allow a manager to cause bus stalls.

Detection Methods

Method

Details

Architecture or Design Review

Instances of this issue can be detected by manual review of the switching policy implemented in the interconnect and the deployed on-chip communication standard.

Effectiveness: Opportunistic

Note:

Manual review requires to have a full description of the architecture of the interconnect. This information might not be available when a third-party interconnect is used.

Formal Verification

Instances of this issue can be found in manager modules by using property-based verification specifically targeting the detection of stalls propagated to the shared resources [REF-1588].

Effectiveness: High

Simulation / Emulation

Instances of this issue can be found in simulation by synthetically generating stalls at the input of the interconnect and evaluating if the interconnect propagates the stalls at the output or not.

Effectiveness: Moderate

Note:

Simulations should be capable of triggering the stalls. Not all of the Verification IP for on-chip communications might be capable of triggering this issue.

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1410	Comprehensive Categorization: Insufficient Control Flow Management

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

References

[REF-1585]	Francesco Restuccia and Ryan Kastner. "Cut and Forward: Safe and Secure Communication for FPGA System on Chips". 2022. <https://ieeexplore.ieee.org/document/9852740>. (URL validated: 2026-10-22) Alternative URL: <https://frestucc.github.io/papers/Cut-and-forward-Safe-and-secure-communication-for-fpga-system-on-chips.pdf>. (URL validated: 2026-10-22)
[REF-1586]	Francesco Restuccia, Alessandro Biondi, Mauro Marinoni and Giorgio Buttazzo. "Safely Preventing Unbounded Delays During Bus Transactions in FPGA-based SoC". 2020. <https://ieeexplore.ieee.org/abstract/document/9114758>. (URL validated: 2026-10-22) Alternative URL: <https://frestucc.github.io/papers/Safely-preventing-unbounded-delays-during-bus-transactions-in-FPGA-based-SoC.pdf>. (URL validated: 2026-10-22)
[REF-1587]	Thomas Benz, Alessandro Ottaviano, Robert Balas, Angelo Garofalo, Francesco Restuccia, Alessandro Biondi and Luca Benini. "[AXI-REALM: A lightweight and modular interconnect extension for traffic regulation and monitoring of heterogeneous real-time SoCs". 2024. <https://ieeexplore.ieee.org/document/10546511>. (URL validated: 2026-10-22) Alternative URL: <https://arxiv.org/abs/2501.10161>. (URL validated: 2026-10-22)
[REF-1588]	Andres Meza, Francesco Restuccia, Ryan Kastner and Jason Oberg. "Safety verification of third-party hardware modules via information flow tracking". 2022. <https://kastner.ucsd.edu/wp-content/uploads/2022/08/admin/rage22-safety.pdf>. (URL validated: 2026-10-22)

Content History

Submissions
Submission Date	Submitter	Organization
2022-08-25 (CWE 5.0, 2026-10-28)	Francesco Restuccia	University of California San Diego
2022-08-25 (CWE 5.0, 2026-10-28)

Weakness ID: 276

View customized information:

Description

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

Common Consequences

Impact	Details
Read Application Data; Modify Application Data	Scope: Confidentiality, Integrity

Potential Mitigations

Phase(s)

Mitigation

Architecture and Design; Operation

The architecture needs to access and modification attributes for files to only those users who actually require those actions.

Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	732	Incorrect Permission Assignment for Critical Resource

Relevant to the view "Software Development" (View-699)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	275	Permission Issues

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
	Nature	Type	ID	Name
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	732	Incorrect Permission Assignment for Critical Resource

Relevant to the view "Architectural Concepts" (View-1008)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1011	Authorize Actors

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1198	Privilege Separation and Access Control Issues

Modes Of Introduction

Phase(s)	Note
Architecture and Design
Implementation
Installation; Operation

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Selected Observed Examples

Reference	Description
CVE-2005-1941	Executables installed world-writable.
CVE-2002-1713	Home directories installed world-readable.
CVE-2001-1550	World-writable log files allow information loss; world-readable file has cleartext passwords.
CVE-2002-1711	World-readable directory.
CVE-2002-1844	Windows product uses insecure permissions when installing on Solaris (genesis: port error).
CVE-2001-0497	Insecure permissions for a shared secret key file. Overlaps cryptographic problem.
CVE-1999-0426	Default permissions of a device allow IP spoofing.

Weakness Ordinalities

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

Detection Methods

Method	Details
Automated Static Analysis - Binary or Bytecode	According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Inter-application Flow Analysis Effectiveness: SOAR Partial
Manual Static Analysis - Binary or Bytecode	According to SOAR [REF-1479], 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 [REF-1479], 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 Web Application Scanner Web Services Scanner Database Scanners Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation	According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Host Application Interface Scanner Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer Automated Monitored Execution Forced Path Execution Effectiveness: High
Manual Static Analysis - Source Code	According to SOAR [REF-1479], 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 [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Context-configured Source Code Weakness Analyzer Effectiveness: SOAR Partial
Automated Static Analysis	According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Configuration Checker Effectiveness: SOAR Partial
Architecture or Design Review	According to SOAR [REF-1479], 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

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	743	CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	857	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	877	CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	946	SFP Secondary Cluster: Insecure Resource Permissions
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1147	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1345	OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1376	ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1436	OWASP Top Ten 2025 Category A01:2025 - Broken Access Control

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Notes

Maintenance

As of CWE 4.19, this entry is being considered for deprecation or significant revision. Its name and description are inconsistent. The name is more general, and the description is more specific. The description emphasizes the installation phase only; mentions only files; and emphasizes modification of those files. The name applies to any type of resource, does not mention the specific permissions, and could be relevant to any SDLC phase.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		Insecure Default Permissions
CERT C Secure Coding	FIO06-C	Create files with appropriate access permissions
The CERT Oracle Secure Coding Standard for Java (2011)	FIO01-J	Create files with appropriate access permission
ISA/IEC 62443	Part 2-4	Req SP.03.08
ISA/IEC 62443	Part 4-2	Req CR 2.1

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-1	Accessing Functionality Not Properly Constrained by ACLs
CAPEC-127	Directory Indexing
CAPEC-81	Web Server Logs Tampering

References

[REF-62]	Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Insecure Defaults", Page 69. 1st Edition. Addison Wesley. 2006.
[REF-1479]	Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler and Rama S. Moorthy. "State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation". 2014-07. <https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx>. (URL validated: 2025-09-05)
[REF-1479]	Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler and Rama S. Moorthy. "State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation". 2014-07. <https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx>. (URL validated: 2025-09-05)

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2024-09-29 (CWE 4.19, 2025-12-11)	Abhi Balakrishnan
2024-09-29 (CWE 4.19, 2025-12-11)	Contributed usability diagram concepts used by the CWE team
2023-04-25 (CWE 4.11, 2023-04-27)	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023-04-25 (CWE 4.11, 2023-04-27)	Suggested mappings to ISA/IEC 62443.
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Time_of_Introduction
2026-01-21 (CWE 4.19.1, 2026-01-21)	CWE Content Team	MITRE
2026-01-21 (CWE 4.19.1, 2026-01-21)	updated Relationships
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated Diagram, Maintenance_Notes, Relationships
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated Detection_Factors, References
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Mapping_Notes, Relationships
2023-04-27 (CWE 4.11, 2023-04-27)	CWE Content Team	MITRE
2023-04-27 (CWE 4.11, 2023-04-27)	updated Relationships, Taxonomy_Mappings
2023-01-31 (CWE 4.10, 2023-01-31)	CWE Content Team	MITRE
2023-01-31 (CWE 4.10, 2023-01-31)	updated Applicable_Platforms
2022-06-28 (CWE 4.8, 2022-06-28)	CWE Content Team	MITRE
2022-06-28 (CWE 4.8, 2022-06-28)	updated Relationships
2022-04-28 (CWE 4.7, 2022-04-28)	CWE Content Team	MITRE
2022-04-28 (CWE 4.7, 2022-04-28)	updated Relationships
2021-10-28 (CWE 4.6, 2021-10-28)	CWE Content Team	MITRE
2021-10-28 (CWE 4.6, 2021-10-28)	updated Relationships
2021-07-20 (CWE 4.5, 2021-07-20)	CWE Content Team	MITRE
2021-07-20 (CWE 4.5, 2021-07-20)	updated Relationships
2020-12-10 (CWE 4.3, 2020-12-10)	CWE Content Team	MITRE
2020-12-10 (CWE 4.3, 2020-12-10)	updated Potential_Mitigations
2020-08-20 (CWE 4.2, 2020-08-20)	CWE Content Team	MITRE
2020-08-20 (CWE 4.2, 2020-08-20)	updated Description, Modes_of_Introduction, Potential_Mitigations
2020-02-24 (CWE 4.0, 2020-02-24)	CWE Content Team	MITRE
2020-02-24 (CWE 4.0, 2020-02-24)	updated Applicable_Platforms, Description, Detection_Factors, Relationships
2019-06-20 (CWE 3.3, 2019-06-20)	CWE Content Team	MITRE
2019-06-20 (CWE 3.3, 2019-06-20)	updated Relationships, Type
2019-01-03 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2019-01-03 (CWE 3.2, 2019-01-03)	updated Relationships, Taxonomy_Mappings
2017-11-08 (CWE 3.0, 2017-11-08)	CWE Content Team	MITRE
2017-11-08 (CWE 3.0, 2017-11-08)	updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2017-05-03 (CWE 2.11, 2017-05-05)	CWE Content Team	MITRE
2017-05-03 (CWE 2.11, 2017-05-05)	updated Related_Attack_Patterns
2014-07-30 (CWE 2.8, 2014-07-31)	CWE Content Team	MITRE
2014-07-30 (CWE 2.8, 2014-07-31)	updated Detection_Factors, Relationships
2012-10-30 (CWE 2.3, 2012-10-30)	CWE Content Team	MITRE
2012-10-30 (CWE 2.3, 2012-10-30)	updated Potential_Mitigations
2012-05-11 (CWE 2.2, 2012-05-15)	CWE Content Team	MITRE
2012-05-11 (CWE 2.2, 2012-05-15)	updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-09-13 (CWE 2.1, 2011-09-13)	CWE Content Team	MITRE
2011-09-13 (CWE 2.1, 2011-09-13)	updated Relationships, Taxonomy_Mappings
2011-06-01 (CWE 1.13, 2011-06-01)	CWE Content Team	MITRE
2011-06-01 (CWE 1.13, 2011-06-01)	updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-05-27 (CWE 1.4, 2009-05-27)	CWE Content Team	MITRE
2009-05-27 (CWE 1.4, 2009-05-27)	updated Description, Name
2008-11-24 (CWE 1.1, 2008-11-25)	CWE Content Team	MITRE
2008-11-24 (CWE 1.1, 2008-11-25)	updated Relationships, Taxonomy_Mappings
2008-09-08 (CWE 1.0, 2008-09-09)	CWE Content Team	MITRE
2008-09-08 (CWE 1.0, 2008-09-09)	updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-07-01 (CWE 1.0, 2008-09-09)	Eric Dalci	Cigital
2008-07-01 (CWE 1.0, 2008-09-09)	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2009-05-27	Insecure Default Permissions

Weakness ID: 1429

View customized information:

Description

The product has a hardware interface that silently discards operations in situations for which feedback would be security-relevant, such as the timely detection of failures or attacks.

Extended Description

While some systems intentionally withhold feedback as a security measure, this approach must be strictly controlled to ensure it does not obscure operational failures that require prompt detection and remediation. Without these essential confirmations, failures go undetected, increasing the risk of data loss, security vulnerabilities, and overall system instability. Even when withholding feedback is an intentional part of a security policy designed, for example, to prevent attackers from gleaning sensitive internal details, the absence of expected feedback becomes a critical weakness when it masks operational failures that require prompt detection and remediation.

For instance, certain encryption algorithms always return ciphertext regardless of errors to prevent attackers from gaining insight into internal state details. However, if such an algorithm fails to generate the expected ciphertext and provides no error feedback, the system cannot distinguish between a legitimate output and a malfunction. This can lead to undetected cryptographic failures, potentially compromising data security and system reliability. Without proper notification, a critical failure might remain hidden, undermining both the reliability and security of the process.

Therefore, this weakness captures issues across various hardware interfaces where operations are discarded without any feedback, error handling, or logging. Such omissions can lead to data loss, security vulnerabilities, and system instability, with potential impacts ranging from minor to catastrophic.

For some kinds of hardware products, some errors may be correctly identified and subsequently discarded, and the lack of feedback may have been an intentional design decision. However, this could result in a weakness if system operators or other authorized entities are not provided feedback about security-critical operations or failures that could prevent the operators from detecting and responding to an attack.

For example:

In a System-on-Chip (SoC) platform, write operations to reserved memory addresses might be correctly identified as invalid and subsequently discarded. However, if no feedback is provided to system operators, they may misinterpret the device's state, failing to recognize conditions that could lead to broader failures or security vulnerabilities. For example, if an attacker attempts unauthorized writes to protected regions, the system may silently discard these writes without alerting security mechanisms. This lack of feedback could obscure intrusion attempts or misconfigurations, increasing the risk of unnoticed system compromise
Microcontroller Interrupt Systems: When interrupts are silently ignored due to priority conflicts or internal errors without notifying higher-level control, it becomes challenging to diagnose system failures or detect potential security breaches in a timely manner.
Network Interface Controllers: Dropping packets - perhaps due to buffer overflows - without any error feedback can not only cause data loss but may also contribute to exploitable timing discrepancies that reveal sensitive internal processing details.

Common Consequences

Impact	Details
Read Memory; Read Files or Directories	Scope: Confidentiality Likelihood: Medium Critical data may be exposed if operations are unexecuted or discarded silently, allowing attackers to exploit the lack of feedback.
Modify Memory; Modify Files or Directories	Scope: Integrity Likelihood: Medium Operations may proceed based on incorrect assumptions, potentially causing data corruption or incorrect system behavior. In integrity-sensitive contexts, failing to signal that an operation did not occur as expected can mask errors that disrupt data consistency. Without feedback, the mitigation measures that should ensure updates have been performed cannot be verified, leaving the system vulnerable to both accidental and malicious data alterations.
DoS: Resource Consumption (Memory); DoS: Crash, Exit, or Restart	Scope: Availability Likelihood: High Unhandled discarded operations can lead to resource exhaustion, triggering system crashes or denial of service. For availability, consistent feedback is crucial. Without proper notification of discarded operations, administrators or other authorized entities might miss early warning signs of resource imbalances. This delayed detection could allow a DoS condition to develop, compromising the system's ability to serve legitimate requests and maintain continuous operations.

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	Incorporate logging and feedback mechanisms during the design phase to ensure proper handling of discarded operations. Effectiveness: High Note: Addressing the issue at the design stage prevents the weakness from manifesting later.
Implementation	Developers should ensure that every critical operation includes proper logging or error feedback mechanisms. Effectiveness: Moderate Note: Implementation-level checks complement design-phase measures.

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	223	Omission of Security-relevant Information
	PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	392	Missing Report of Error Condition

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1208	Cross-Cutting Problems

Modes Of Introduction

Phase(s)	Note
Architecture and Design	This weakness can be introduced during the architecture and design phase when the system does not incorporate proper mechanisms for error reporting or feedback for discarded operations, such as when handling reserved addresses or unexecuted instructions.
Implementation	It can also arise during implementation if developers fail to include appropriate feedback or logging for critical operations. This leads to silent failures in certain scenarios like interrupt handling or network buffer overflows.
Requirements	A further layer of complexity emerges when considering specifications. The weakness may stem either from ambiguous product design specifications that fail to delineate when feedback should occur or from implementations that do not adhere to existing requirements. In either case, the result is the same: feedback that is critical for detecting operational failures or security breaches is missing.

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	C (Undetermined Prevalence) C++ (Undetermined Prevalence) Verilog (Undetermined Prevalence) Class: Hardware Description Language (Undetermined Prevalence) Class: Not Language-Specific (Undetermined Prevalence)
Architectures	ARM (Undetermined Prevalence) x86 (Undetermined Prevalence) Class: Embedded (Undetermined Prevalence)
Technologies	Security Hardware (Undetermined Prevalence) Processor Hardware (Undetermined Prevalence) Microcontroller Hardware (Undetermined Prevalence) Class: System on Chip (Undetermined Prevalence)

Demonstrative Examples

Example 1

This code creates an interrupt handler. If the interrupt's priority is lower than the currently active one, the interrupt is discarded without any feedback, perhaps due to resource constraints.

(bad code)

Example Language: C

					  void interrupt_handler(int irq) {

						if (irq_priority[irq] < current_priority) {

						  return;

						}

						process_interrupt(irq);

					  }

The omission of feedback for the dropped lower-priority interrupt can cause developers to misinterpret the state of the system, leading to incorrect assumptions and potential system failures, such as missed sensor readings.

Attackers might leverage this lack of visibility to induce conditions that lead to timing side-channels. For example, an attacker could intentionally flood the system with high-priority interrupts, forcing the system to discard lower-priority interrupts consistently. If these discarded interrupts correspond to processes executing critical security functions (e.g., cryptographic key handling), an attacker might measure system timing variations to infer when and how those functions are executing. This creates a timing side channel that could be used to extract sensitive information. Moreover, since these lower-priority interrupts are not reported, the system remains unaware that critical tasks such as sensor data collection or maintenance routines, are being starved of execution. Over time, this can lead to functional failures or watchdog time resets in real-time systems.

One way to address this problem could be to use structured logging to provide visibility into discarded interrupts. This allows administrators, developers, or other authorized entities to track missed interrupts and optimize the system.

(good code)

Example Language: C

					  // Priority threshold for active interrupts

					  int current_priority = 3;

					  // Simulated priority levels for different IRQs

					  int irq_priority[5] = {1, 2, 3, 4, 5};

					  void process_interrupt(int irq) {

						printf("Processing interrupt %d\n", irq);

					  }

					  void interrupt_handler(int irq) {

						if (irq_priority[irq] < current_priority) {

						  // Log the dropped interrupt using structured feedback

						  fprintf(stderr, "Warning: Interrupt %d dropped (Priority: %d < Current: %d)\n", 

							irq, irq_priority[irq], current_priority);

						  exit(EXIT_FAILURE);  // Exit with failure status to indicate a critical issue.

						}

						process_interrupt(irq);

					  }

Example 2

Consider a SoC design with these component IPs:

IP 1. Execution Core <--> IP 2 SoC Fabric (NoC, tile etc. ) <--> IP 3 Memory Controller <--> External/ internal memory.

The Core executes operations that trigger transactions that traverse the HW fabric links to read/write to the final memory module.

There can be unexpected errors in each link. For adding reliability and redundancy, features like ECCs are used in these transactions. Error correction capabilities have to define how many error bits can be detected and which errors can be corrected, and which are uncorrectable errors. In design, often the severity level and response on different errors is allowed to be configured by system firmware modules like BIOS.

(bad code)

Example Language: Other

                                
					If an uncorrectable error occurs, the design does not explicitly
					trigger an alert back to the execution core.

For system security, if an uncorrectable error occurs but is not reported to the execution core and handled before the core attempts to consume the data that is read/written through the corrupted transactions, then this could enable silent data corruption (SDC) attacks.

In the case of confidential compute technologies where system firmware is not a trusted component, error handling controls can be misconfigured to trigger this weakness and attack the assets protected by confidential compute.

(good code)

Example Language: Other

                                
					Modify the design so that any uncorrectable error triggers an alert
					back to the execution core and gets handled before the core can
					consume the data read/written through the corrupted transactions.
					Update design access control policies to ensure that alerts sent to
					execution core on uncorrectable errors cannot be disabled or masked by
					untrusted software/firmware.
				  
                            

Selected Observed Examples

Reference	Description
[REF-1468]	Open source silicon root of trust (RoT) product does not immediately report when an integrity check fails for memory requests, causing the product to accept and continue processing data [REF-1468]

Weakness Ordinalities

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

Detection Methods

Method

Details

Automated Static Analysis - Source Code

Scans code for missing error handling or feedback mechanisms.

Effectiveness: High

Note:

This identifies common issues early in the development phase.

Manual Static Analysis - Source Code

Experts manually inspect the code for unhandled operations.

Effectiveness: Moderate

Note:

Useful for identifying design-level omissions.

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1413	Comprehensive Categorization: Protection Mechanism Failure

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

References

[REF-1468]

GregAC. "OpenTitan issue: [rv_core_ibex] Bus errors on integrity check failure". 2022-03-09.
<https://github.com/lowRISC/opentitan/issues/11336>. (URL validated: 2025-04-02)

Content History

Submissions
Submission Date	Submitter	Organization
2023-12-20 (CWE 4.17, 2025-04-03)	Amisha Srivastava	University of Texas at Dallas
2023-12-20 (CWE 4.17, 2025-04-03)
Contributions
Contribution Date	Contributor	Organization
2025-03-25 (CWE 4.17, 2025-04-03)	Hareesh Khattri	Intel Corporation
2025-03-25 (CWE 4.17, 2025-04-03)	Contributed an observed example and a demonstrative example.
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Demonstrative_Examples, Detection_Factors
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated Demonstrative_Examples, Weakness_Ordinalities

Weakness ID: 203

View customized information:

Description

The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor.

Dimensions

The Dimensions table provides information about the different dimensions associated with this weakness. The Type identifies the dimension type, while the Value provides the specific value for that dimension.

Type	Value
Behavior-Property	Discrepancy
Behavior-Property	Observable

Alternate Terms

Side Channel Attack

Observable Discrepancies are at the root of side channel attacks.

Common Consequences

Impact	Details
Read Application Data; Bypass Protection Mechanism	Scope: Confidentiality, Access Control An attacker can gain access to sensitive information about the system, including authentication information that may allow an attacker to gain access to the system. Other security-relevant information about the operation or internal state of the product may be revealed to an unauthorized actor, such as whether a particular operation was successful or not.
Read Application Data	Scope: Confidentiality In some cases, discrepancies can be used by attackers to form a side channel. When cryptographic primitives are vulnerable to side-channel attacks, this could be used to reveal unencrypted plaintext in the worst case.

Potential Mitigations

Phase(s)

Mitigation

Architecture and Design

Strategy: Separation of Privilege

Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.

If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.

Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	200	Exposure of Sensitive Information to an Unauthorized Actor
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	204	Observable Response Discrepancy
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	205	Observable Behavioral Discrepancy
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	208	Observable Timing Discrepancy
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1300	Improper Protection of Physical Side Channels
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1303	Non-Transparent Sharing of Microarchitectural Resources

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
	Nature	Type	ID	Name
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	200	Exposure of Sensitive Information to an Unauthorized Actor

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1205	Security Primitives and Cryptography Issues

Background Details

Discrepancies may be observable based on timing, control flow, communications (such as replies or requests), or general behavior.

Modes Of Introduction

Phase(s)	Note
Architecture and Design
Implementation

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.

(bad code)

Example Language: Perl

my $username=param('username');
                  
my $password=param('password');
                  
if (IsValidUsername($username) == 1)
                  
{
                  if (IsValidPassword($username, $password) == 1)
                  
{
                  print "Login Successful";
                  
}
                  
else
                  
{
                  print "Login Failed - incorrect password";
                  
}
                  
}
                  
else
                  
{
                  print "Login Failed - unknown username";
                  
}

In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.

While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:

(result)

"Login Failed - incorrect username or password"

Example 2

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.

Example 3

Non-uniform processing time causes a timing channel.

(bad code)

Example Language: Algorithm

                                Suppose an algorithm for implementing an encryption routine works fine per se, but the time taken to output the result of the encryption routine depends on a relationship between the input plaintext and the key (e.g., suppose, if the plaintext is similar to the key, it would run very fast).
                            

In the example above, an attacker may vary the inputs, then observe differences between processing times (since different plaintexts take different time). This could be used to infer information about the key.

(good code)

Example Language: Algorithm

                                Artificial delays may be added to ensure that all calculations take equal time to execute.
                            

Example 4

Suppose memory access patterns for an encryption routine are dependent on the secret key.

An attacker can recover the key by knowing if specific memory locations have been accessed or not. The value stored at those memory locations is irrelevant. The encryption routine's memory accesses will affect the state of the processor cache. If cache resources are shared across contexts, after the encryption routine completes, an attacker in different execution context can discover which memory locations the routine accessed by measuring the time it takes for their own memory accesses to complete.

Selected Observed Examples

Reference	Description
CVE-2020-8695	Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.
CVE-2019-14353	Crypto hardware wallet's power consumption relates to total number of pixels illuminated, creating a side channel in the USB connection that allows attackers to determine secrets displayed such as PIN numbers and passwords
CVE-2019-10071	Java-oriented framework compares HMAC signatures using String.equals() instead of a constant-time algorithm, causing timing discrepancies
CVE-2002-2094	This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal.
CVE-2001-1483	Enumeration of valid usernames based on inconsistent responses
CVE-2001-1528	Account number enumeration via inconsistent responses.
CVE-2004-2150	User enumeration via discrepancies in error messages.
CVE-2005-1650	User enumeration via discrepancies in error messages.
CVE-2004-0294	Bulletin Board displays different error messages when a user exists or not, which makes it easier for remote attackers to identify valid users and conduct a brute force password guessing attack.
CVE-2004-0243	Operating System, when direct remote login is disabled, displays a different message if the password is correct, which allows remote attackers to guess the password via brute force methods.
CVE-2002-0514	Product allows remote attackers to determine if a port is being filtered because the response packet TTL is different than the default TTL.
CVE-2002-0515	Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs.
CVE-2002-0208	Product modifies TCP/IP stack and ICMP error messages in unusual ways that show the product is in use.
CVE-2004-2252	Behavioral infoleak by responding to SYN-FIN packets.
CVE-2001-1387	Product may generate different responses than specified by the administrator, possibly leading to an information leak.
CVE-2004-0778	Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to be returned.
CVE-2004-1428	FTP server generates an error message if the user name does not exist instead of prompting for a password, which allows remote attackers to determine valid usernames.
CVE-2003-0078	SSL implementation does not perform a MAC computation if an incorrect block cipher padding is used, which causes an information leak (timing discrepancy) that may make it easier to launch cryptographic attacks that rely on distinguishing between padding and MAC verification errors, possibly leading to extraction of the original plaintext, aka the "Vaudenay timing attack."
CVE-2000-1117	Virtual machine allows malicious web site operators to determine the existence of files on the client by measuring delays in the execution of the getSystemResource method.
CVE-2003-0637	Product uses a shorter timeout for a non-existent user than a valid user, which makes it easier for remote attackers to guess usernames and conduct brute force password guessing.
CVE-2003-0190	Product immediately sends an error message when a user does not exist, which allows remote attackers to determine valid usernames via a timing attack.
CVE-2004-1602	FTP server responds in a different amount of time when a given username exists, which allows remote attackers to identify valid usernames by timing the server response.
CVE-2005-0918	Browser allows remote attackers to determine the existence of arbitrary files by setting the src property to the target filename and using Javascript to determine if the web page immediately stops loading, which indicates whether the file exists or not.

Weakness Ordinalities

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

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	717	OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	728	OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	967	SFP Secondary Cluster: State Disclosure
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1417	Comprehensive Categorization: Sensitive Information Exposure

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Discrepancy Information Leaks
OWASP Top Ten 2007	A6	CWE More Specific	Information Leakage and Improper Error Handling
OWASP Top Ten 2004	A7	CWE More Specific	Improper Error Handling

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-189	Black Box Reverse Engineering

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2020-06-03 (CWE 4.5, 2021-07-20)	Nicole Fern	Cycuity (originally submitted as Tortuga Logic)
2020-06-03 (CWE 4.5, 2021-07-20)	Provided Demonstrative Example for cache timing attack
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Demonstrative_Examples, Dimensions, Relationships
2026-04-30 (CWE 4.20, 2026-04-30)	CWE Content Team	MITRE
2026-04-30 (CWE 4.20, 2026-04-30)	updated Background_Details, Common_Consequences, Description, Diagram
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated Weakness_Ordinalities
2025-04-03 (CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
2025-04-03 (CWE 4.17, 2025-04-03)	updated Demonstrative_Examples
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Demonstrative_Examples
2023-10-26 (CWE 4.13, 2023-10-26)	CWE Content Team	MITRE
2023-10-26 (CWE 4.13, 2023-10-26)	updated Observed_Examples
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Mapping_Notes
2023-04-27 (CWE 4.11, 2023-04-27)	CWE Content Team	MITRE
2023-04-27 (CWE 4.11, 2023-04-27)	updated Relationships
2021-10-28 (CWE 4.6, 2021-10-28)	CWE Content Team	MITRE
2021-10-28 (CWE 4.6, 2021-10-28)	updated Observed_Examples
2021-07-20 (CWE 4.5, 2021-07-20)	CWE Content Team	MITRE
2021-07-20 (CWE 4.5, 2021-07-20)	updated Demonstrative_Examples
2020-12-10 (CWE 4.3, 2020-12-10)	CWE Content Team	MITRE
2020-12-10 (CWE 4.3, 2020-12-10)	updated Common_Consequences, Demonstrative_Examples, Description, Name, Potential_Mitigations, Research_Gaps
2020-08-20 (CWE 4.2, 2020-08-20)	CWE Content Team	MITRE
2020-08-20 (CWE 4.2, 2020-08-20)	updated Alternate_Terms, Common_Consequences, Demonstrative_Examples, Description, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships, Research_Gaps
2020-02-24 (CWE 4.0, 2020-02-24)	CWE Content Team	MITRE
2020-02-24 (CWE 4.0, 2020-02-24)	updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, Relationships
2019-06-20 (CWE 3.3, 2019-06-20)	CWE Content Team	MITRE
2019-06-20 (CWE 3.3, 2019-06-20)	updated Relationships, Type
2017-11-08 (CWE 3.0, 2017-11-08)	CWE Content Team	MITRE
2017-11-08 (CWE 3.0, 2017-11-08)	updated Applicable_Platforms
2014-07-30 (CWE 2.8, 2014-07-31)	CWE Content Team	MITRE
2014-07-30 (CWE 2.8, 2014-07-31)	updated Relationships
2012-10-30 (CWE 2.3, 2012-10-30)	CWE Content Team	MITRE
2012-10-30 (CWE 2.3, 2012-10-30)	updated Potential_Mitigations
2012-05-11 (CWE 2.2, 2012-05-15)	CWE Content Team	MITRE
2012-05-11 (CWE 2.2, 2012-05-15)	updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships
2011-06-01 (CWE 1.13, 2011-06-01)	CWE Content Team	MITRE
2011-06-01 (CWE 1.13, 2011-06-01)	updated Common_Consequences
2009-12-28 (CWE 1.7, 2009-12-28)	CWE Content Team	MITRE
2009-12-28 (CWE 1.7, 2009-12-28)	updated Description, Name
2008-09-08 (CWE 1.0, 2008-09-09)	CWE Content Team	MITRE
2008-09-08 (CWE 1.0, 2008-09-09)	updated Relationships, Taxonomy_Mappings
2008-07-01 (CWE 1.0, 2008-09-09)	Eric Dalci	Cigital
2008-07-01 (CWE 1.0, 2008-09-09)	updated Potential_Mitigations, Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2020-12-10	Observable Differences in Behavior to Error Inputs
2020-08-20	Observable Discrepancy
2020-02-24	Information Exposure Through Discrepancy
2009-12-28	Discrepancy Information Leaks

Weakness ID: 1191

View customized information:

Description

The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.

Extended Description

If authorization, authentication, or some other form of access control is not implemented or not implemented correctly, a user may be able to bypass on-chip protection mechanisms through the debug interface.

Dimensions

Type	Value
Behavior-Type	Access Control
Behavior-Property	Improper
Technology	On-Chip Debug and Test Interface

Common Consequences

Impact	Details
Read Application Data	Scope: Confidentiality Likelihood: High
Read Memory	Scope: Confidentiality Likelihood: High
Execute Unauthorized Code or Commands	Scope: Authorization Likelihood: High
Modify Memory	Scope: Integrity Likelihood: High
Modify Application Data	Scope: Integrity Likelihood: High
Bypass Protection Mechanism	Scope: Access Control Likelihood: High

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	Strategy: Separation of Privilege If feasible, the manufacturer should disable the JTAG interface or implement authentication and authorization for the JTAG interface. If authentication logic is added, it should be resistant to timing attacks. Security-sensitive data stored in registers, such as keys, etc. should be cleared when entering debug mode. Effectiveness: High

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control
	PeerOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1263	Improper Physical Access Control

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1207	Debug and Test Problems
	PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1299	Missing Protection Mechanism for Alternate Hardware Interface

Background Details

A device's internal information may be accessed through a scan chain of interconnected internal registers, usually through a JTAG interface. The JTAG interface provides access to these registers in a serial fashion in the form of a scan chain for the purposes of debugging programs running on a device. Since almost all information contained within a device may be accessed over this interface, device manufacturers typically insert some form of authentication and authorization to prevent unintended use of this sensitive information. This mechanism is implemented in addition to on-chip protections that are already present.

Modes Of Introduction

Phase(s)	Note
Architecture and Design	Sometimes, designers choose not to expose the debug pins on the motherboard. Instead, they choose to hide these pins in the intermediate layers of the board. This is primarily done to work around the lack of debug authorization inside the chip. In such a scenario (without debug authorization), when the debug interface is exposed, chip internals are accessible to an attacker.
Implementation

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

A home, WiFi-router device implements a login prompt which prevents an unauthorized user from issuing any commands on the device until appropriate credentials are provided. The credentials are protected on the device and are checked for strength against attack.

(bad code)

Example Language: Other

If the JTAG interface on this device is not hidden by the manufacturer, the interface may be identified using tools such as JTAGulator. If it is hidden but not disabled, it can be exposed by physically wiring to the board.
By issuing a "halt" command before the OS starts, the unauthorized user pauses the watchdog timer and prevents the router from restarting (once the watchdog timer would have expired). Having paused the router, an unauthorized user is able to execute code and inspect and modify data in the device, even extracting all of the router's firmware. This allows the user to examine the router and potentially exploit it.

JTAG is useful to chip and device manufacturers during design, testing, and production and is included in nearly every product. Without proper authentication and authorization, the interface may allow tampering with a product.

(good code)

Example Language: Other

                                In order to prevent exposing the debugging interface, manufacturers might try to obfuscate the JTAG interface or blow device internal fuses to disable the JTAG interface. Adding authentication and authorization to this interface makes use by unauthorized individuals much more difficult.
                            

Example 2

The following example code is a snippet from the JTAG wrapper module in the RISC-V debug module of the HACK@DAC'21 Openpiton SoC [REF-1355]. To make sure that the JTAG is accessed securely, the developers have included a primary authentication mechanism based on a password.

The developers employed a Finite State Machine (FSM) to implement this authentication. When a user intends to read from or write to the JTAG module, they must input a password.

In the subsequent state of the FSM module, the entered password undergoes Hash-based Message Authentication Code (HMAC) calculation using an internal HMAC submodule. Once the HMAC for the entered password is computed by the HMAC submodule, the FSM transitions to the next state, where it compares the computed HMAC with the expected HMAC for the password.

If the computed HMAC matches the expected HMAC, the FSM grants the user permission to perform read or write operations on the JTAG module. [REF-1352]

(bad code)

Example Language: SystemVerilog

...
PassChkValid: begin
if(hashValid) begin
if(exp_hash == pass_hash) begin
pass_check = 1'b1;
end else beginpass_check = 1'b0;
end

						state_d = Idle;

					end else begin
						state_d = PassChkValid;

					end

				end

			...

However, in the given vulnerable part of the code, the JTAG module has not defined a limitation for several continuous wrong password attempts. This omission poses a significant security risk, allowing attackers to carry out brute-force attacks without restrictions.

Without a limitation on wrong password attempts, an attacker can repeatedly guess different passwords until they gain unauthorized access to the JTAG module. This leads to various malicious activities, such as unauthorized read from or write to debug module interface.

To mitigate the mentioned vulnerability, developers need to implement a restriction on the number of consecutive incorrect password attempts allowed by the JTAG module, which can achieve by incorporating a mechanism that temporarily locks the module after a certain number of failed attempts.[REF-1353][REF-1354]

(good code)

Example Language: SystemVerilog

...

			case (state_q)
				Idle: begin

				...
					else if ( (dm::dtm_op_e'(dmi.op) == dm::DTM_PASS) && (miss_pass_check_cnt_q != 2'b11) )

					begin
						state_d = Write;
pass_mode = 1'b1;

					end

				...

				end

				...
PassChkValid: begin
if(hashValid) begin
if(exp_hash == pass_hash) begin
pass_check = 1'b1;

							end else begin
							pass_check = 1'b0;

							miss_pass_check_cnt_d = miss_pass_check_cnt_q + 1
							

							end

							state_d = Idle;
							

						end else begin
							state_d = PassChkValid;

						end

					end

				...

Example 3

The example code below is taken from the JTAG access control mechanism of the HACK@DAC'21 buggy OpenPiton SoC [REF-1364]. Access to JTAG allows users to access sensitive information in the system. Hence, access to JTAG is controlled using cryptographic authentication of the users. In this example (see the vulnerable code source), the password checker uses HMAC-SHA256 for authentication. It takes a 512-bit secret message from the user, hashes it using HMAC, and compares its output with the expected output to determine the authenticity of the user.

(bad code)

Example Language: SystemVerilog

                                
		...
logic [31-1:0] data_d, data_q;

		...
logic [512-1:0] pass_data;

		...

			Write: begin

				...

					if (pass_mode) begin

							pass_data = { {60{8'h00}}, data_d};

							state_d = PassChk;

							pass_mode = 1'b0;

					...

			end

		...

The vulnerable code shows an incorrect implementation of the HMAC authentication where it only uses the least significant 32 bits of the secret message for the authentication (the remaining 480 bits are hard coded as zeros). As a result, the system is susceptible to brute-force attacks on the access control mechanism of JTAG, where the attacker only needs to determine 32 bits of the secret message instead of 512 bits.

To mitigate this issue, remove the zero padding and use all 512 bits of the secret message for HMAC authentication [REF-1365].

(good code)

Example Language: SystemVerilog

                                
		...
logic [512-1:0] data_d, data_q;

		...

		logic [512-1:0] pass_data;

		...

			Write: begin

				...

					if (pass_mode) begin

							pass_data = data_d;

							state_d = PassChk;

							pass_mode = 1'b0;

					...

			end

		...

Selected Observed Examples

Reference	Description
CVE-2019-18827	Chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys

Weakness Ordinalities

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

Detection Methods

Method

Details

Dynamic Analysis with Manual Results Interpretation

Authentication and authorization of debug and test interfaces should be part of the architecture and design review process. Withholding of private register documentation from the debug and test interface public specification ("Security by obscurity") should not be considered as sufficient security.

Dynamic Analysis with Manual Results Interpretation

Dynamic tests should be done in the pre-silicon and post-silicon stages to verify that the debug and test interfaces are not open by default.

Fuzzing

Tests that fuzz Debug and Test Interfaces should ensure that no access without appropriate authentication and authorization is possible.

Effectiveness: Moderate

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1343	Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1432	Weaknesses in the 2025 CWE Most Important Hardware Weaknesses List

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Notes

Relationship

CWE-1191 and CWE-1244 both involve physical debug access, but the weaknesses are different. CWE-1191 is effectively about missing authorization for a debug interface, i.e. JTAG. CWE-1244 is about providing internal assets with the wrong debug access level, exposing the asset to untrusted debug agents.

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-1	Accessing Functionality Not Properly Constrained by ACLs
CAPEC-180	Exploiting Incorrectly Configured Access Control Security Levels

References

[REF-1037]	Kurt Rosenfeld and Ramesh Karri. "Attacks and Defenses for JTAG". 2010-02. <https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5406671>. Access restrictions: Proprietary-Subscription
[REF-1043]	Gopal Vishwakarma and Wonjun Lee. "Exploiting JTAG and Its Mitigation in IOT: A Survey". 2018-12-03. <https://www.mdpi.com/1999-5903/10/12/121/pdf>. (URL validated: 2023-04-07)
[REF-1084]	Gopal Vishwakarma and Wonjun Lee. "JTAG Explained (finally!): Why "IoT", Software Security Engineers, and Manufacturers Should Care". <https://www.mdpi.com/1999-5903/10/12/121/pdf>. (URL validated: 2023-04-07)
[REF-1085]	Bob Molyneaux, Mark McDermott and Anil Sabbavarapu. "Design for Testability & Design for Debug". <https://web.archive.org/web/20180412225956/http://users.ece.utexas.edu/~mcdermot/vlsi-2/Lecture_17.pdf>. (URL validated: 2025-08-04)
[REF-1355]	Florian Zaruba. "dmi_jtag.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/71103971e8204de6a61afc17d3653292517d32bf/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L192:L204>. (URL validated: 2023-09-18)
[REF-1354]	Florian Zaruba. "Fix CWE-1191 in dmi_jtag.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/58f984d492fdb0369c82ef10fcbbaa4b9850f9fb/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L200>. (URL validated: 2023-09-18)
[REF-1353]	Florian Zaruba. "Fix CWE-1191 in dmi_jtag.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/58f984d492fdb0369c82ef10fcbbaa4b9850f9fb/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L131>. (URL validated: 2023-09-18)
[REF-1352]	Florian Zaruba. "dmi_jtag.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/71103971e8204de6a61afc17d3653292517d32bf/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L118:L204>. (URL validated: 2023-09-18)
[REF-1364]	"dmi_jtag.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/71103971e8204de6a61afc17d3653292517d32bf/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L82>. (URL validated: 2023-07-15)
[REF-1365]	"fix cwe_1205 in dmi_jtag.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/c4f4b832218b50c406dbf9f425d3b654117c1355/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L158>. (URL validated: 2023-07-22)

Content History

Submissions
Submission Date	Submitter	Organization
2019-10-15 (CWE 4.0, 2020-02-24)	Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi	Intel Corporation
2019-10-15 (CWE 4.0, 2020-02-24)
Contributions
Contribution Date	Contributor	Organization
2023-06-21 (CWE 4.14, 2024-02-29)	Shaza Zeitouni, Mohamadreza Rostami, Pouya Mahmoody, Ahmad-Reza Sadeghi	Technical University of Darmstadt
2023-06-21 (CWE 4.14, 2024-02-29)	suggested demonstrative example
2023-06-21 (CWE 4.14, 2024-02-29)	Rahul Kande, Chen Chen, Jeyavijayan Rajendran	Texas A&M University
2023-06-21 (CWE 4.14, 2024-02-29)	suggested demonstrative example
2021-10-27 (CWE 4.9, 2022-10-13)	Arun Kanuparthi	Intel Corporation
2021-10-27 (CWE 4.9, 2022-10-13)	suggested additional detail in extended description
2021-10-22 (CWE 4.6, 2021-10-28)	Hareesh Khattri	Intel Corporation
2021-10-22 (CWE 4.6, 2021-10-28)	clarified differences between CWE-1191 and CWE-1244
2021-10-20 (CWE 4.6, 2021-10-28)	Narasimha Kumar V Mangipudi	Lattice Semiconductor
2021-10-20 (CWE 4.6, 2021-10-28)	reviewed content changes
2021-10-18 (CWE 4.6, 2021-10-28)	Parbati K. Manna	Intel Corporation
2021-10-18 (CWE 4.6, 2021-10-28)	provided detection methods
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Background_Details, Demonstrative_Examples, Description, Dimensions, Modes_of_Introduction
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated References, Relationships
2023-10-26 (CWE 4.13, 2023-10-26)	CWE Content Team	MITRE
2023-10-26 (CWE 4.13, 2023-10-26)	updated Demonstrative_Examples, References
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Mapping_Notes
2023-04-27 (CWE 4.11, 2023-04-27)	CWE Content Team	MITRE
2023-04-27 (CWE 4.11, 2023-04-27)	updated References, Relationships
2022-10-13 (CWE 4.9, 2022-10-13)	CWE Content Team	MITRE
2022-10-13 (CWE 4.9, 2022-10-13)	updated Description, Related_Attack_Patterns
2022-04-28 (CWE 4.7, 2022-04-28)	CWE Content Team	MITRE
2022-04-28 (CWE 4.7, 2022-04-28)	updated Related_Attack_Patterns
2021-10-28 (CWE 4.6, 2021-10-28)	CWE Content Team	MITRE
2021-10-28 (CWE 4.6, 2021-10-28)	updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Potential_Mitigations, Relationship_Notes, Relationships, Weakness_Ordinalities
2021-03-15 (CWE 4.4, 2021-03-15)	CWE Content Team	MITRE
2021-03-15 (CWE 4.4, 2021-03-15)	updated Maintenance_Notes
2020-08-20 (CWE 4.2, 2020-08-20)	CWE Content Team	MITRE
2020-08-20 (CWE 4.2, 2020-08-20)	updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-06-25 (CWE 4.1, 2020-06-25)	CWE Content Team	MITRE
2020-06-25 (CWE 4.1, 2020-06-25)	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, References, Relationships
Previous Entry Names
Change Date	Previous Entry Name
2021-10-28	Exposed Chip Debug and Test Interface With Insufficient or Missing Authorization
2020-08-20	Exposed Chip Debug and or Test Interface With Insufficient Access Control
2020-02-26	Exposed Chip Debug Interface With Insufficient Access Control

Weakness ID: 226

View customized information:

Description

Extended Description

When resources are released, they can be made available for reuse. For example, after memory is de-allocated, an operating system may make the memory available to another process, or disk space may be reallocated when a file is deleted. Since removing information requires time and additional resources, operating systems do not usually clear the previously written information.

Even when the resource is reused by the same process, this weakness can arise when new data is not as large as the old data, which leaves portions of the old data still available. Equivalent errors can occur in other situations where the length of data is variable but the associated data structure is not. If memory is not cleared after use, the information may be read by less trustworthy parties when the memory is reallocated.

This weakness can apply in hardware, such as when a device or system switches between power, sleep, or debug states during normal operation, or when execution changes to different users or privilege levels.

Common Consequences

Impact	Details
Read Application Data	Scope: Confidentiality

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design; Implementation	During critical state transitions, information not needed in the next state should be removed or overwritten with fixed patterns (such as all 0's) or random data, before the transition to the next state. Effectiveness: High
Architecture and Design; Implementation	When releasing, de-allocating, or deleting a resource, overwrite its data and relevant metadata with fixed patterns or random data. Be cautious about complex resource types whose underlying representation might be non-contiguous or change at a low level, such as how a file might be split into different chunks on a file system, even though "logical" file positions are contiguous at the application layer. Such resource types might require invocation of special modes or APIs to tell the underlying operating system to perform the necessary clearing, such as SDelete (Secure Delete) on Windows, although the appropriate functionality might not be available at the application layer. Effectiveness: High
Implementation	Be careful using vfork() and fork() in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use.

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	212	Improper Removal of Sensitive Information Before Storage or Transfer
	ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	459	Incomplete Cleanup
	ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	244	Improper Clearing of Heap Memory Before Release
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1272	Sensitive Information Uncleared Before Debug/Power State Transition
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1301	Insufficient or Incomplete Data Removal within Hardware Component
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1342	Information Exposure through Microarchitectural State after Transient Execution
	CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	201	Insertion of Sensitive Information Into Sent Data

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1202	Memory and Storage Issues

Modes Of Introduction

Phase(s)	Note
Implementation

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

This example shows how an attacker can take advantage of an incorrect state transition.

Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in state B. The device reads the keys, performs operations using those keys, then transitions to state B, where those private keys should no longer be accessible.

(bad code)

Example Language: Other

During the transition from A to B, the device does not scrub the memory.

After the transition to state B, even though the private keys are no longer accessible directly from the fuses in state B, they can be accessed indirectly by reading the memory that contains the private keys.

(good code)

Example Language: Other

                                For transition from state A to state B, remove information which should not be available once the transition is complete.
                            

Example 2

The following code calls realloc() on a buffer containing sensitive data:

(bad code)

Example Language: C

cleartext_buffer = get_secret();...
cleartext_buffer = realloc(cleartext_buffer, 1024);
...
scrub_memory(cleartext_buffer, 1024);

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so it could return a pointer to a different part of memory. The memory that was originally allocated for cleartext_buffer could still contain an uncleared copy of the data.

Example 3

The following example code is excerpted from the AES wrapper/interface, aes0_wrapper, module of one of the AES engines (AES0) in the Hack@DAC'21 buggy OpenPiton System-on-Chip (SoC). Note that this SoC contains three distinct AES engines. Within this wrapper module, four 32-bit registers are utilized to store the message intended for encryption, referred to as p_c[i]. Using the AXI Lite interface, these registers are filled with the 128-bit message to be encrypted.

(bad code)

Example Language: SystemVerilog

		   module aes0_wrapper #(...)(...);

		   ...

		   always @(posedge clk_i)

			 begin

			   if(~(rst_ni && ~rst_1)) //clear p_c[i] at reset

				 begin

                   start <= 0;

                   p_c[0] <= 0;

                   p_c[1] <= 0;

                   p_c[2] <= 0;

                   p_c[3] <= 0;

                   ...

				 end

			   else if(en && we)

				 case(address[8:3])

                   0:

                     start  <= reglk_ctrl_i[1] ? start  : wdata[0];

                   1:

                     p_c[3] <= reglk_ctrl_i[3] ? p_c[3] : wdata[31:0];

                   2:

                     p_c[2] <= reglk_ctrl_i[3] ? p_c[2] : wdata[31:0];

                   3:

                     p_c[1] <= reglk_ctrl_i[3] ? p_c[1] : wdata[31:0];

                   4:

                     p_c[0] <= reglk_ctrl_i[3] ? p_c[0] : wdata[31:0];

                   ...

				 endcase

			   end // always @ (posedge wb_clk_i)

			 endmodule

The above code snippet [REF-1402] illustrates an instance of a vulnerable implementation of the AES wrapper module, where p_c[i] registers are cleared at reset. Otherwise, p_c[i]registers either maintain their old values (if reglk_ctrl_i[3]is true) or get filled through the AXI signal wdata. Note that p_c[i]registers can be read through the AXI Lite interface (not shown in snippet). However, p_c[i] registers are never cleared after their usage once the AES engine has completed the encryption process of the message. In a multi-user or multi-process environment, not clearing registers may result in the attacker process accessing data left by the victim, leading to data leakage or unintentional information disclosure.

To fix this issue, it is essential to ensure that these internal registers are cleared in a timely manner after their usage, i.e., the encryption process is complete. This is illustrated below by monitoring the assertion of the cipher text valid signal, ct_valid [REF-1403].

(good code)

Example Language: SystemVerilog

		   module aes0_wrapper #(...)(...);

		   ...

		   always @(posedge clk_i)

			 begin

			   if(~(rst_ni && ~rst_1)) //clear p_c[i] at reset

				 ...

else if(ct_valid) //encryption process complete, clear p_c[i]
begin

				   p_c[0] <= 0;

				   p_c[1] <= 0;

				   p_c[2] <= 0;

				   p_c[3] <= 0;

end

			   else if(en && we)

				 case(address[8:3])

				 ...

				 endcase

			   end // always @ (posedge wb_clk_i)

			 endmodule

Selected Observed Examples

Reference	Description
CVE-2019-3733	Cryptography library does not clear heap memory before release
CVE-2003-0001	Ethernet NIC drivers do not pad frames with null bytes, leading to infoleak from malformed packets.
CVE-2003-0291	router does not clear information from DHCP packets that have been previously used
CVE-2005-1406	Products do not fully clear memory buffers when less data is stored into the buffer than previous.
CVE-2005-1858	Products do not fully clear memory buffers when less data is stored into the buffer than previous.
CVE-2005-3180	Products do not fully clear memory buffers when less data is stored into the buffer than previous.
CVE-2005-3276	Product does not clear a data structure before writing to part of it, yielding information leak of previously used memory.
CVE-2002-2077	Memory not properly cleared before reuse.

Weakness Ordinalities

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

Detection Methods

Method

Details

Manual Analysis

Write a known pattern into each sensitive location. Trigger the release of the resource or cause the desired state transition to occur. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the product needs to be fixed. Note that this test can likely be automated.

Effectiveness: High

Automated Static Analysis

Effectiveness: High

Functional Areas

Memory Management
Networking

Affected Resources

Memory

Memberships

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	729	OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	963	SFP Secondary Cluster: Exposed Data
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1416	Comprehensive Categorization: Resource Lifecycle Management
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1432	Weaknesses in the 2025 CWE Most Important Hardware Weaknesses List

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Notes

Relationship

There is a close association between CWE-226 and CWE-212. The difference is partially that of perspective. CWE-226 is geared towards the final stage of the resource lifecycle, in which the resource is deleted, eliminated, expired, or otherwise released for reuse. Technically, this involves a transfer to a different control sphere, in which the original contents of the resource are no longer relevant. CWE-212, however, is intended for sensitive data in resources that are intentionally shared with others, so they are still active. This distinction is useful from the perspective of the CWE research view (CWE-1000).

Research Gap

This is frequently found for network packets, but it can also exist in local memory allocation, files, etc.

Maintenance

This entry needs modification to clarify the differences with CWE-212. The description also combines two problems that are distinct from the CWE research perspective: the inadvertent transfer of information to another sphere, and improper initialization/shutdown. Some of the associated taxonomy mappings reflect these different uses.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		Sensitive Information Uncleared Before Use
CERT C Secure Coding	MEM03-C	Clear sensitive information stored in reusable resources returned for reuse
Software Fault Patterns	SFP23	Exposed Data

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-37	Retrieve Embedded Sensitive Data

References

[REF-1402]	"aes0_wrapper.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/65d0ffdab7426da4509c98d62e163bcce642f651/piton/design/chip/tile/ariane/src/aes0/aes0_wrapper.sv#L84C2-L90C29>. (URL validated: 2024-02-14)
[REF-1403]	"Fix for aes0_wrapper". 2023-11-29. <https://github.com/HACK-EVENT/hackatdac21/blob/0034dff6852365a8c4e36590a47ea8b088d725ae/piton/design/chip/tile/ariane/src/aes0/aes0_wrapper.sv#L96C1-L102C16>. (URL validated: 2024-02-14)

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2023-11-29 (CWE 4.14, 2024-02-29)	Rahul Kande, Chen Chen, Jeyavijayan Rajendran	Texas A&M University
2023-11-29 (CWE 4.14, 2024-02-29)	suggested demonstrative example
2023-11-29 (CWE 4.14, 2024-02-29)	Mohamadreza Rostami, Shaza Zeitouni, Ahmad-Reza Sadeghi	Technical University of Darmstadt
2023-11-29 (CWE 4.14, 2024-02-29)	suggested demonstrative example
Modifications
Modification Date	Modifier	Organization
2026-10-28 (CWE 5.0, 2026-10-28)	CWE Content Team	MITRE
2026-10-28 (CWE 5.0, 2026-10-28)	updated Demonstrative_Examples, Description, Potential_Mitigations, Relationships
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated Relationships
2025-04-03 (CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
2025-04-03 (CWE 4.17, 2025-04-03)	updated Demonstrative_Examples
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Demonstrative_Examples, Observed_Examples, References
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Mapping_Notes
2023-04-27 (CWE 4.11, 2023-04-27)	CWE Content Team	MITRE
2023-04-27 (CWE 4.11, 2023-04-27)	updated Detection_Factors, Relationships, Time_of_Introduction
2021-10-28 (CWE 4.6, 2021-10-28)	CWE Content Team	MITRE
2021-10-28 (CWE 4.6, 2021-10-28)	updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Potential_Mitigations, Relationships, Research_Gaps
2020-08-20 (CWE 4.2, 2020-08-20)	CWE Content Team	MITRE
2020-08-20 (CWE 4.2, 2020-08-20)	updated Description, Name, Related_Attack_Patterns, Relationships
2020-02-24 (CWE 4.0, 2020-02-24)	CWE Content Team	MITRE
2020-02-24 (CWE 4.0, 2020-02-24)	updated Applicable_Platforms, Description, Name, Relationships, Time_of_Introduction, Weakness_Ordinalities
2017-11-08 (CWE 3.0, 2017-11-08)	CWE Content Team	MITRE
2017-11-08 (CWE 3.0, 2017-11-08)	updated Causal_Nature, Functional_Areas, Relationships, Taxonomy_Mappings
2014-07-30 (CWE 2.8, 2014-07-31)	CWE Content Team	MITRE
2014-07-30 (CWE 2.8, 2014-07-31)	updated Relationships, Taxonomy_Mappings
2012-05-11 (CWE 2.2, 2012-05-15)	CWE Content Team	MITRE
2012-05-11 (CWE 2.2, 2012-05-15)	updated Relationships, Taxonomy_Mappings
2011-09-13 (CWE 2.1, 2011-09-13)	CWE Content Team	MITRE
2011-09-13 (CWE 2.1, 2011-09-13)	updated Relationships, Taxonomy_Mappings
2011-06-01 (CWE 1.13, 2011-06-01)	CWE Content Team	MITRE
2011-06-01 (CWE 1.13, 2011-06-01)	updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-12-13 (CWE 1.11, 2010-12-13)	CWE Content Team	MITRE
2010-12-13 (CWE 1.11, 2010-12-13)	updated Description
2010-09-27 (CWE 1.10, 2010-09-27)	CWE Content Team	MITRE
2010-09-27 (CWE 1.10, 2010-09-27)	updated Relationships
2010-02-16 (CWE 1.8, 2010-02-16)	CWE Content Team	MITRE
2010-02-16 (CWE 1.8, 2010-02-16)	updated Applicable_Platforms, Maintenance_Notes, Relationship_Notes
2009-10-29 (CWE 1.6, 2009-10-29)	CWE Content Team	MITRE
2009-10-29 (CWE 1.6, 2009-10-29)	updated Description, Other_Notes
2009-05-27 (CWE 1.4, 2009-05-27)	CWE Content Team	MITRE
2009-05-27 (CWE 1.4, 2009-05-27)	updated Relationships
2009-03-10 (CWE 1.3, 2009-03-10)	CWE Content Team	MITRE
2009-03-10 (CWE 1.3, 2009-03-10)	updated Relationships
2008-11-24 (CWE 1.1, 2008-11-25)	CWE Content Team	MITRE
2008-11-24 (CWE 1.1, 2008-11-25)	updated Relationships, Taxonomy_Mappings
2008-10-14 (CWE 1.0.1, 2008-10-14)	CWE Content Team	MITRE
2008-10-14 (CWE 1.0.1, 2008-10-14)	updated Relationships
2008-09-08 (CWE 1.0, 2008-09-09)	CWE Content Team	MITRE
2008-09-08 (CWE 1.0, 2008-09-09)	updated Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-07-01 (CWE 1.0, 2008-09-09)	Eric Dalci	Cigital
2008-07-01 (CWE 1.0, 2008-09-09)	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2020-08-20	Sensitive Information Uncleared in Resource Before Release for Reuse
2020-02-24	Sensitive Information Uncleared Before Release
2008-04-11	Sensitive Information Uncleared Before Use

Weakness ID: 1240

View customized information:

Description

To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.

Extended Description

Cryptographic protocols and systems depend on cryptographic primitives (and associated algorithms) as their basic building blocks. Some common examples of primitives are digital signatures, one-way hash functions, ciphers, and public key cryptography; however, the notion of "primitive" can vary depending on point of view. See "Terminology Notes" for further explanation of some concepts.

Cryptographic primitives are defined to accomplish one very specific task in a precisely defined and mathematically reliable fashion. For example, suppose that for a specific cryptographic primitive (such as an encryption routine), the consensus is that the primitive can only be broken after trying out N different inputs (where the larger the value of N, the stronger the cryptography). For an encryption scheme like AES-256, one would expect N to be so large as to be infeasible to execute in a reasonable amount of time.

If a vulnerability is ever found that shows that one can break a cryptographic primitive in significantly less than the expected number of attempts, then that primitive is considered weakened (or sometimes in extreme cases, colloquially it is "broken"). As a result, anything using this cryptographic primitive would now be considered insecure or risky. Thus, even breaking or weakening a seemingly small cryptographic primitive has the potential to render the whole system vulnerable, due to its reliance on the primitive. A historical example can be found in TLS when using DES. One would colloquially call DES the cryptographic primitive for transport encryption in this version of TLS. In the past, DES was considered strong, because no weaknesses were found in it; importantly, DES has a key length of 56 bits. Trying N=2^56 keys was considered impractical for most actors. Unfortunately, attacking a system with 56-bit keys is now practical via brute force, which makes defeating DES encryption practical. It is now practical for an adversary to read any information sent under this version of TLS and use this information to attack the system. As a result, it can be claimed that this use of TLS is weak, and that any system depending on TLS with DES could potentially render the entire system vulnerable to attack.

Cryptographic primitives and associated algorithms are only considered safe after extensive research and review from experienced cryptographers from academia, industry, and government entities looking for any possible flaws. Furthermore, cryptographic primitives and associated algorithms are frequently reevaluated for safety when new mathematical and attack techniques are discovered. As a result and over time, even well-known cryptographic primitives can lose their compliance status with the discovery of novel attacks that might either defeat the algorithm or reduce its robustness significantly.

If ad-hoc cryptographic primitives are implemented, it is almost certain that the implementation will be vulnerable to attacks that are well understood by cryptographers, resulting in the exposure of sensitive information and other consequences.

This weakness is even more difficult to manage for hardware-implemented deployment of cryptographic algorithms. First, because hardware is not patchable as easily as software, any flaw discovered after release and production typically cannot be fixed without a recall of the product. Secondly, the hardware product is often expected to work for years, during which time computation power available to the attacker only increases. Therefore, for hardware implementations of cryptographic primitives, it is absolutely essential that only strong, proven cryptographic primitives are used.

Common Consequences

Impact	Details
Read Application Data	Scope: Confidentiality Likelihood: High Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.

Potential Mitigations

Phase(s)	Mitigation
Requirements	Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267]. Effectiveness: High
Architecture and Design	Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267]. Effectiveness: High
Architecture and Design	Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak. Effectiveness: Discouraged Common Practice
Architecture and Design	Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you "know" it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this. Effectiveness: Discouraged Common Practice
Architecture and Design	Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation ("cryptographic agility"). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level. Effectiveness: Defense in Depth
Architecture and Design	Do not use outdated or non-compliant cryptography algorithms. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong [REF-267]. Effectiveness: Discouraged Common Practice
Architecture and Design; Implementation	Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator. Effectiveness: Discouraged Common Practice
Architecture and Design; Implementation	Do not use a checksum as a substitute for a cryptographically generated hash. Effectiveness: Discouraged Common Practice
Architecture and Design	Strategy: Libraries or Frameworks Use a vetted cryptographic library or framework. Industry-standard implementations will save development time and are more likely to avoid errors that can occur during implementation of cryptographic algorithms. However, the library/framework could be used incorrectly during implementation. Effectiveness: High
Architecture and Design; Implementation	When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for the prevention of common attacks. Effectiveness: Moderate
Architecture and Design; Implementation	Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant. Effectiveness: Moderate

Relationships

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	327	Use of a Broken or Risky Cryptographic Algorithm
	ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	325	Missing Cryptographic Step

Relevant to the view "Software Development" (View-699)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	310	Cryptographic Issues

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1205	Security Primitives and Cryptography Issues

Modes Of Introduction

Phase(s)	Note
Architecture and Design	This weakness is primarily introduced during the architecture and design phase as risky primitives are included.
Implementation	Even in cases where the Architectural phase properly specifies a cryptographically secure design, the design may be changed during implementation due to unforeseen constraints.

Applicable Platforms

Type	Applicable Platforms	Notes
Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: System on Chip (Undetermined Prevalence)

Demonstrative Examples

Example 1

Re-using random values may compromise security.

(bad code)

Example Language: Other

                                Suppose an Encryption algorithm needs a random value for a key. Instead of using a DRNG (Deterministic Random Number Generator), the designer uses a linear-feedback shift register (LFSR) to generate the value.
                            

While an LFSR may provide pseudo-random number generation service, the entropy (measure of randomness) of the resulting output may be less than that of an accepted DRNG (like that used in dev/urandom). Thus, using an LFSR weakens the strength of the cryptographic system, because it may be possible for an attacker to guess the LFSR output and subsequently the encryption key.

(good code)

Example Language: Other

                                If a cryptographic algorithm expects a random number as its input, provide one. Do not provide a pseudo-random value.
                            

Selected Observed Examples

Reference	Description
CVE-2020-4778	software uses MD5, which is less safe than the default SHA-256 used by related products
CVE-2005-2946	Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
CVE-2019-3907	identity card uses MD5 hash of a salt and password
CVE-2021-34687	personal key is transmitted over the network using a substitution cipher
CVE-2020-14254	product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.
CVE-2019-1543	SSL/TLS library generates 16-byte nonces but reduces them to 12 byte nonces for the ChaCha20-Poly1305 cipher, converting them in a way that violates the cipher's requirements for unique nonces.
CVE-2017-9267	LDAP interface allows use of weak ciphers
CVE-2017-7971	SCADA product allows "use of outdated cipher suites"
CVE-2020-6616	Chip implementing Bluetooth uses a low-entropy PRNG instead of a hardware RNG, allowing spoofing.
CVE-2019-1715	security product has insufficient entropy in the DRBG, allowing collisions and private key discovery
CVE-2014-4192	Dual_EC_DRBG implementation in RSA toolkit does not correctly handle certain byte requests, simplifying plaintext recovery
CVE-2007-6755	Recommendation for Dual_EC_DRBG algorithm contains point Q constants that could simplify decryption

Weakness Ordinalities

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

Detection Methods

Method	Details
Architecture or Design Review	Review requirements, documentation, and product design to ensure that primitives are consistent with the strongest-available recommendations from trusted parties. If the product appears to be using custom or proprietary implementations that have not had sufficient public review and approval, then this is a significant concern. Effectiveness: High
Manual Analysis	Analyze the product to ensure that implementations for each primitive do not contain any known vulnerabilities and are not using any known-weak algorithms, including MD4, MD5, SHA1, DES, etc. Effectiveness: Moderate
Dynamic Analysis with Manual Results Interpretation	For hardware, during the implementation (pre-Silicon / post-Silicon) phase, dynamic tests should be done to ensure that outputs from cryptographic routines are indeed working properly, such as test vectors provided by NIST [REF-1236]. Effectiveness: Moderate
Dynamic Analysis with Manual Results Interpretation	It needs to be determined if the output of a cryptographic primitive is lacking entropy, which is one clear sign that something went wrong with the crypto implementation. There exist many methods of measuring the entropy of a bytestream, from sophisticated ones (like calculating Shannon's entropy of a sequence of characters) to crude ones (by compressing it and comparing the size of the original bytestream vs. the compressed - a truly random byte stream should not be compressible and hence the uncompressed and compressed bytestreams should be nearly identical in size). Effectiveness: Moderate

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1343	Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1402	Comprehensive Categorization: Encryption
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1439	OWASP Top Ten 2025 Category A04:2025 - Cryptographic Failures

Vulnerability Mapping Notes

Usage	ALLOWED (this CWE ID may be used to map to real-world vulnerabilities)
Reason	Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Notes

Terminology

Terminology for cryptography varies widely, from informal and colloquial to mathematically-defined, with different precision and formalism depending on whether the stakeholder is a developer, cryptologist, etc. Yet there is a need for CWE to be self-consistent while remaining understandable and acceptable to multiple audiences.

As of CWE 4.6, CWE terminology around "primitives" and "algorithms" is emerging as shown by the following example, subject to future consultation and agreement within the CWE and cryptography communities. Suppose one wishes to send encrypted data using a CLI tool such as OpenSSL. One might choose to use AES with a 256-bit key and require tamper protection (GCM mode, for instance). For compatibility's sake, one might also choose the ciphertext to be formatted to the PKCS#5 standard. In this case, the "cryptographic system" would be AES-256-GCM with PKCS#5 formatting. The "cryptographic function" would be AES-256 in the GCM mode of operation, and the "algorithm" would be AES. Colloquially, one would say that AES (and sometimes AES-256) is the "cryptographic primitive," because it is the algorithm that realizes the concept of symmetric encryption (without modes of operation or other protocol related modifications). In practice, developers and architects typically refer to base cryptographic algorithms (AES, SHA, etc.) as cryptographic primitives.

Maintenance

Since CWE 4.4, various cryptography-related entries, including CWE-327 and CWE-1240, have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-97	Cryptanalysis

References

[REF-267]	Information Technology Laboratory, National Institute of Standards and Technology. "FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf>. (URL validated: 2025-05-21)
[REF-1227]	Wikipedia. "Cryptographic primitive". <https://en.wikipedia.org/wiki/Cryptographic_primitive>.
[REF-1192]	Information Technology Laboratory, National Institute of Standards and Technology. "FIPS PUB 140-3: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2019-03-22. <https://csrc.nist.gov/publications/detail/fips/140/3/final>.
[REF-1236]	NIST. "CAVP Testing: Individual Component Testing". Test Vectors. <https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/component-testing>.

Content History

Submissions
Submission Date	Submitter	Organization
2020-02-10 (CWE 4.0, 2020-02-24)	Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi	Intel Corporation
2020-02-10 (CWE 4.0, 2020-02-24)
Contributions
Contribution Date	Contributor	Organization
2026-04-16 (CWE 5.0, 2026-10-28)	Jason Oberg	Arteris
2026-04-16 (CWE 5.0, 2026-10-28)	Suggested additional HW relationships to help distinguish between different HW CWEs, and/or expose the user to alternatives.
2021-10-18 (CWE 4.6, 2021-10-28)	Parbati K. Manna	Intel Corporation
2021-10-18 (CWE 4.6, 2021-10-28)	provided detection methods and observed examples
Modifications
Modification Date	Modifier	Organization
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated Relationships
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated References
2025-04-03 (CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
2025-04-03 (CWE 4.17, 2025-04-03)	updated Demonstrative_Examples
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Mapping_Notes
2023-04-27 (CWE 4.11, 2023-04-27)	CWE Content Team	MITRE
2023-04-27 (CWE 4.11, 2023-04-27)	updated References, Relationships
2021-10-28 (CWE 4.6, 2021-10-28)	CWE Content Team	MITRE
2021-10-28 (CWE 4.6, 2021-10-28)	updated Background_Details, Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Terminology_Notes, Weakness_Ordinalities
2021-07-20 (CWE 4.5, 2021-07-20)	CWE Content Team	MITRE
2021-07-20 (CWE 4.5, 2021-07-20)	updated Maintenance_Notes, Research_Gaps
2020-08-20 (CWE 4.2, 2020-08-20)	CWE Content Team	MITRE
2020-08-20 (CWE 4.2, 2020-08-20)	updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns, Research_Gaps
Previous Entry Names
Change Date	Previous Entry Name
2021-10-28	Use of a Risky Cryptographic Primitive

Common Weakness Enumeration

CWE VIEW: Hardware Design

View Components

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

Edit Custom Filter

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

Edit Custom Filter

CWE-319: Cleartext Transmission of Sensitive Information

Edit Custom Filter

CWE-1255: Comparison Logic is Vulnerable to Power Side-Channel Attacks

Edit Custom Filter

CWE Grouping: Core and Compute Issues

CWE-1252: CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations

Edit Custom Filter

CWE Grouping: Cross-Cutting Problems

CWE-1279: Cryptographic Operations are Run Before Supporting Units are Ready

Edit Custom Filter

CWE Grouping: Debug and Test Problems

CWE-1295: Debug Messages Revealing Unnecessary Information

Edit Custom Filter

CWE-1273: Device Unlock Credential Sharing

Edit Custom Filter

CWE-1190: DMA Device Enabled Too Early in Boot Phase

Edit Custom Filter

CWE-1431: Driving Intermediate Cryptographic State/Results to Hardware Module Outputs

Edit Custom Filter

CWE-440: Expected Behavior Violation

Edit Custom Filter

CWE-1422: Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution

Edit Custom Filter

CWE-1423: Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution

Edit Custom Filter

CWE-1420: Exposure of Sensitive Information during Transient Execution

Edit Custom Filter

CWE-1421: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution

Edit Custom Filter

CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information

Edit Custom Filter

CWE-1316: Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges

Edit Custom Filter

CWE-1209: Failure to Disable Reserved Bits

Edit Custom Filter

CWE-1277: Firmware Not Updateable

Edit Custom Filter

CWE Grouping: General Circuit and Logic Design Concerns

CWE-1270: Generation of Incorrect Security Tokens

Edit Custom Filter

CWE-1313: Hardware Allows Activation of Test or Debug Logic at Runtime

Edit Custom Filter

CWE-1276: Hardware Child Block Incorrectly Connected to Parent System

Edit Custom Filter

CWE-1234: Hardware Internal or Debug Modes Allow Override of Locks

Edit Custom Filter

CWE-1298: Hardware Logic Contains Race Conditions

Edit Custom Filter

CWE-1264: Hardware Logic with Insecure De-Synchronization between Control and Data Channels

Edit Custom Filter

CWE-1461: Hardware Simulation / Synthesis Mismatch

Edit Custom Filter

CWE-1257: Improper Access Control Applied to Mirrored or Aliased Memory Regions

Edit Custom Filter

CWE-1262: Improper Access Control for Register Interface

Edit Custom Filter

CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code

Edit Custom Filter

CWE-1317: Improper Access Control in Fabric Bridge

Edit Custom Filter

CWE-1245: Improper Finite State Machines (FSMs) in Hardware Logic

Edit Custom Filter

CWE-1332: Improper Handling of Faults that Lead to Instruction Skips

Edit Custom Filter

CWE-1351: Improper Handling of Hardware Behavior in Exceptionally Cold Environments

Edit Custom Filter

CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges

Edit Custom Filter

CWE-1384: Improper Handling of Physical or Environmental Conditions

Edit Custom Filter

CWE-1261: Improper Handling of Single Event Upsets

Edit Custom Filter

CWE-1192: Improper Identifier for IP Block used in System-On-Chip (SOC)