auren-research/cyber-sec huggingface dataset:
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.

CPUs provide a special bit that supports exclusivity of write and execute operations. This bit is used to segregate areas of memory to either mark them as code (instructions, which can be executed) or data (which should not be executed). In this way, if a user can write to a region of memory, the user cannot execute from that region and vice versa. This exclusivity provided by special hardware bit is leveraged by the operating system to protect executable space. While this bit is available in most modern processors by default, in some CPUs the exclusivity is implemented via a memory-protection unit (MPU) and memory-management unit (MMU) in which memory regions can be carved out with exact read, write, and execute permissions. However, if the CPU does not have an MMU/MPU, then there is no write exclusivity.

Primary

Architecture and Design

Confidentiality
Integrity
Execute Unauthorized Code or Commands
Without configuring exclusivity of operations via segregated areas of memory, an attacker may be able to inject malicious code onto memory and later execute it.

Architecture and Design

Implement a dedicated bit that can be leveraged by the Operating System to mark data areas as non-executable. If such a bit is not available in the CPU, implement MMU/MPU (memory management unit / memory protection unit).

Integration

If MMU/MPU are not available, then the firewalls need to be implemented in the SoC interconnect to mimic the write-exclusivity operation.

MCS51 Microcontroller (based on 8051) does not have a special bit to support write exclusivity. It also does not have an MMU/MPU support. The Cortex-M CPU has an optional MPU that supports up to 8 regions.

The optional MPU is not configured.

If the MPU is not configured, then an attacker will be able to inject malicious data into memory and execute it.

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

Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi
Intel Corporation
2020-02-13
4.0
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2022-04-28
updated Applicable_Platforms, Related_Attack_Patterns

CWE Content Team
MITRE
2022-06-28
updated Applicable_Platforms

CWE Content Team
MITRE
2023-04-27
updated References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Common_Consequences, Description, Weakness_Ordinalities
The logic level used to set a system to a secure state relies on a fuse being unblown.

Fuses are often used to store secret data, including security configuration data. When not blown, a fuse is considered to store a logic 0, and, when blown, it indicates a logic 1. Fuses are generally considered to be one-directional, i.e., once blown to logic 1, it cannot be reset to logic 0.

Primary

Architecture and Design

Implementation

Access Control
Authorization
Bypass Protection Mechanism
Gain Privileges or Assume Identity
If the logic used to determine system-security state (by leveraging the values sensed from the fuses) uses negative logic, an attacker might blow the fuse and drive the system to an insecure state.

Availability
DoS: Crash, Exit, or Restart

Confidentiality
Read Memory

Integrity
Modify Memory
Execute Unauthorized Code or Commands

Architecture and Design
Logic should be designed in a way that blown fuses do not put the product into an insecure state that can be leveraged by an attacker.

A chip implements a secure boot and uses the sensed value of a fuse
"do_secure_boot" to determine whether to perform a secure boot or not. If this fuse
value is "0", the system performs secure boot. Otherwise, it does not perform secure
boot.
An attacker blows the "do_secure_boot" fuse to "1". After reset, the attacker loads a custom
bootloader, and, since the fuse value is now "1", the system does not perform secure boot,
and the attacker can execute their custom firmware image.
Since by default, a fuse-configuration value is a "0", an attacker can blow it to a "1" with
inexpensive hardware.
If the logic is reversed, an attacker cannot easily reset the fuse. Note that, with
specialized and expensive equipment, an attacker with full physical access might be able to "unblow" the fuse
value to a "0".

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

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

Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi
Intel Corporation
2019-10-15
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Applicable_Platforms, Demonstrative_Examples, Description

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2021-10-28
updated Description

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Common_Consequences, Description, Weakness_Ordinalities
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.

Technology trends such as CMOS-transistor down-sizing, use of
new materials, and system-on-chip architectures continue to increase the
sensitivity of systems to soft errors. These errors are random, and
their causes might be internal (e.g., interconnect coupling) or external
(e.g., cosmic radiation). These soft errors are not permanent in nature
and cause temporary bit flips known as single-event upsets (SEUs).
SEUs are induced errors in circuits caused when charged particles lose
energy by ionizing the medium through which they pass, leaving behind a
wake of electron-hole pairs that cause temporary failures. If these
failures occur in security-sensitive modules in a chip, it might
compromise the security guarantees of the chip. For instance, these
temporary failures could be bit flips that change the privilege of
a regular user to root.

Primary

Architecture and Design

Implementation

Availability
Access Control
DoS: Crash, Exit, or Restart
DoS: Instability
Gain Privileges or Assume Identity
Bypass Protection Mechanism

Architecture and Design

Implement triple-modular redundancy around security-sensitive modules.

Architecture and Design

SEUs mostly affect SRAMs. For SRAMs storing security-critical data, implement Error-Correcting-Codes (ECC) and Address Interleaving.

This is an example from [REF-1089]. See the reference for full details of this issue.
Parity is error detecting but not error correcting.
Due to single-event upsets, bits are flipped in memories. As a result, memory-parity checks fail, which results in restart and a temporary denial of service of two to three minutes.
Using error-correcting codes could have avoided the restart caused by SEUs.

In 2016, a security researcher, who was also a patient using a pacemaker, was on an airplane when a bit flip occurred in the pacemaker, likely due to the higher prevalence of cosmic radiation at such heights. The pacemaker was designed to account for bit flips and went into a default safe mode, which still forced the patient to go to a hospital to get it reset. The bit flip also inadvertently enabled the researcher to access the crash file, perform reverse engineering, and detect a hard-coded key. [REF-1101]

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

Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi
Intel Corporation
2020-02-12
4.1
2020-02-24

CWE Content Team
MITRE
2022-04-28
updated Relationships

CWE Content Team
MITRE
2022-06-28
updated Relationships

CWE Content Team
MITRE
2023-04-27
updated References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Demonstrative_Examples, Weakness_Ordinalities
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.
Sections of a product intended to have restricted access may be inadvertently or intentionally rendered accessible when the implemented physical protections are insufficient. The specific requirements around how robust the design of the physical protection mechanism needs to be depends on the type of product being protected. Selecting the correct physical protection mechanism and properly enforcing it through implementation and manufacturing are critical to the overall physical security of the product.

Primary

Architecture and Design
This weakness can arise if design decisions are made that do not align with the intended physical protection of the product.

Manufacturing
While the architecture and design phase of the product may have accurately met the intended robustness for product physical protections, this phase may introduce the weakness through errors in physically manufacturing the product.

Confidentiality
Integrity
Access Control
Varies by Context

Architecture and Design
Specific protection requirements depend strongly on contextual factors including the level of acceptable risk associated with compromise to the product's protection mechanism. Designers could incorporate anti-tampering measures that protect against or detect when the product has been tampered with.

Testing
The testing phase of the lifecycle should establish a method for determining whether the protection mechanism is sufficient to prevent unauthorized access.

Manufacturing
Ensure that all protection mechanisms are fully activated at the time of manufacturing and distribution.

Allowed-with-Review
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit

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

CWE Content Team
MITRE
2020-05-28
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Common_Consequences, Description, Modes_of_Introduction, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships

CWE Content Team
MITRE
2020-12-10
updated Potential_Mitigations

CWE Content Team
MITRE
2021-07-20
updated Relationships

CWE Content Team
MITRE
2021-10-28
updated Description

CWE Content Team
MITRE
2022-10-13
updated Relationships

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes, Relationships

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities

Insufficient Physical Protection Mechanism
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.

When a product is decommissioned - i.e., taken out of service - best practices or regulatory requirements may require the administrator to remove or overwrite sensitive data first, i.e. "scrubbing." Improper scrubbing of sensitive data from a decommissioned device leaves that data vulnerable to acquisition by a malicious actor. Sensitive data may include, but is not limited to, device/manufacturer proprietary information, user/device credentials, network configurations, and other forms of sensitive data.

Primary

Architecture and Design

Policy

Implementation

Confidentiality
Read Memory

Architecture and Design

Functionality to completely scrub data from a product at the conclusion of its lifecycle should be part of the design phase. Trying to add this function on top of an existing architecture could lead to incomplete removal of sensitive information/data.

Policy

The manufacturer should describe the location(s) where sensitive data is stored and the policies and procedures for its removal. This information may be conveyed, for example, in an Administrators Guide or a Statement of Volatility.

Implementation

If the capability to wipe sensitive data isn't built-in, the manufacturer may need to provide a utility to scrub sensitive data from storage if that data is located in a place which is non-accessible by the administrator. One example of this could be when sensitive data is stored on an EEPROM for which there is no user/admin interface provided by the system.

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

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

Paul A. Wortman
Wells Fargo
2020-05-28
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Potential_Mitigations, Related_Attack_Patterns

CWE Content Team
MITRE
2023-01-31
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities
Security-critical logic is not set to a known value on reset.

When the device is first brought out of reset, the state of registers will be indeterminate if they have not been initialized by the logic. Before the registers are initialized, there will be a window during which the device is in an insecure state and may be vulnerable to attack.

Primary

Implementation

Access Control
Authentication
Authorization
Varies by Context

Implementation
Design checks should be performed to identify any uninitialized flip-flops used for security-critical functions.

Architecture and Design
All registers holding security-critical information should be set to a specific value on reset.

Shown below is a positive clock edge triggered flip-flop used to implement a lock bit for test and debug interface. When the circuit is first brought out of reset, the state of the flip-flop will be unknown until the enable input and D-input signals update the flip-flop state. In this example, an attacker can reset the device until the test and debug interface is unlocked and access the test interface until the lock signal is driven to a known state by the logic.

always @(posedge clk) begin

if (en) lock_jtag <= d;

end

The flip-flop can be set to a known value (0 or 1) on reset, but requires that the logic explicitly update the output of the flip-flop if the reset signal is active.

always @(posedge clk) begin

if (~reset) lock_jtag <= 0;
else if (en) lock_jtag <= d;

end

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

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

Nicole Fern
Cycuity (originally submitted as Tortuga Logic)
2020-05-15
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Common_Consequences, Demonstrative_Examples, Description, Modes_of_Introduction, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships

CWE Content Team
MITRE
2021-03-15
updated Name, Type

CWE Content Team
MITRE
2021-10-28
updated Weakness_Ordinalities

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples

CWE Content Team
MITRE
2023-01-31
updated Relationships

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

Missing Known Value on Reset for Registers Holding Security Settings
Unitialized Value on Reset for Registers Holding Security Settings
Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.
Many cryptographic hardware units depend upon other hardware units to supply information to them to produce a securely encrypted result. For example, a cryptographic unit that depends on an external random-number-generator (RNG) unit for entropy must wait until the RNG unit is producing random numbers. If a cryptographic unit retrieves a private encryption key from a fuse unit, the fuse unit must be up and running before a key may be supplied.

Primary

Architecture and Design

Implementation
The decision to continue using a cryptographic unit even though the input units to it are not producing valid data will compromise the encrypted result.

Access Control
Confidentiality
Integrity
Availability
Accountability
Authentication
Authorization
Non-Repudiation
Varies by Context

Architecture and Design
Best practices should be used to design cryptographic systems.

Implementation
Continuously ensuring that cryptographic inputs are supplying valid information is necessary to ensure that the encrypted output is secure.

The following pseudocode illustrates the weak encryption resulting from the use of a pseudo-random-number generator output.

If random_number_generator_self_test_passed() == TRUE
then Seed = get_random_number_from_RNG()
else Seed = hardcoded_number

In the example above, first a check of RNG ready is performed. If the check fails, the RNG is ignored and a hard coded value is used instead. The hard coded value severely weakens the encrypted output.

If random_number_generator_self_test_passed() == TRUE
then Seed = get_random_number_from_RNG()
else enter_error_state()

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

Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi
Intel Corporation
2020-02-12
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Name, Potential_Mitigations, Related_Attack_Patterns

CWE Content Team
MITRE
2021-03-15
updated Maintenance_Notes

CWE Content Team
MITRE
2022-04-28
updated Applicable_Platforms

CWE Content Team
MITRE
2022-06-28
updated Applicable_Platforms

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Relationships

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Relationships

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities

Cryptographic Primitives used without Successful Self-Test
A product's hardware-based access control check occurs after the asset has been accessed.

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

Primary

Implementation

Access Control
Confidentiality
Integrity
Modify Memory
Read Memory
Modify Application Data
Read Application Data
Gain Privileges or Assume Identity
Bypass Protection Mechanism

Implementation
Implement the access control check first. Access should only be given to asset if agent is authorized.

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

module foo_bar(data_out, usr_id, data_in, clk, rst_n);
output reg [7:0] data_out;
input wire [2:0] usr_id;
input wire [7:0] data_in;
input wire clk, rst_n;
wire grant_access;
always @ (posedge clk or negedge rst_n)
begin

if (!rst_n)

data_out = 0;

else

data_out = (grant_access) ? data_in : data_out;
assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;

end
endmodule

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

always @ (posedge clk or negedge rst_n)
begin

if (!rst_n)

data_out = 0;

else

assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;
data_out = (grant_access) ? data_in : data_out;

end
endmodule

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

Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi
Intel Corporation
2020-02-12
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Applicable_Platforms, Demonstrative_Examples, Description, Related_Attack_Patterns

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Demonstrative_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities