The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.

Reserved bits are labeled as such so they can be allocated for a later purpose. They are not to do anything in the current design. However, designers might want to use these bits to debug or control/configure a future capability to help minimize time to market (TTM). If the logic being controlled by these bits is still enabled in production, an adversary could use the logic to induce unwanted/unsupported behavior in the hardware.

Primary

Architecture and Design
The Designer and Implementer have to make a conscious choice to do this.

Implementation
The Designer and Implementer have to make a conscious choice to do this.

Documentation
If documentation labels anything "for future use", "reserved", or the like, such labeling could indicate to an attacker a potential attack point.

Confidentiality
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation
Varies by Context
This type of weakness all depends on the capabilities of the logic being controlled or configured by the reserved bits.

Architecture and Design
Implementation

Include a feature to disable reserved bits.

Integration

Any writes to these reserve bits are blocked (e.g., ignored, access-protected, etc.), or an exception can be asserted.

Assume a hardware Intellectual Property (IP) has address space 0x0-0x0F for its configuration registers, with the last one labeled reserved (i.e. 0x0F). Therefore inside the Finite State Machine (FSM), the code is as follows:

reg gpio_out = 0; //gpio should remain low for normal operation

case (register_address)

4'b1111 : //0x0F

begin

gpio_out = 1;

end

An adversary may perform writes to reserved address space in hopes of changing the behavior of the hardware. In the code above, the GPIO pin should remain low for normal operation. However, it can be asserted by accessing the reserved address space (0x0F). This may be a concern if the GPIO state is being used as an indicator of health (e.g. if asserted the hardware may respond by shutting down or resetting the system, which may not be the correct action the system should perform).
In the code below, the condition "register_address = 0X0F" is commented out, and a default is provided that will catch any values of register_address not explicitly accounted for and take no action with regards to gpio_out. This means that an attacker who is able to write 0X0F to register_address will not enable any undocumented "features" in the process.

reg gpio_out = 0; //gpio should remain low for normal operation

case (register_address)

//4'b1111 : //0x0F
default: gpio_out = gpio_out;

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.

Brent Sherman
Intel Corporation
2020-02-06
4.0
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2021-10-28
updated Potential_Mitigations

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples

CWE Content Team
MITRE
2023-01-31
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
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities