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

A System-on-Chip (SoC) implements secure boot or verified boot. It might support a security version number, which prevents downgrading the current firmware to a vulnerable version. Once downgraded to a previous version, an adversary can launch exploits on the SoC and thus compromise the security of the SoC. These downgrade attacks are also referred to as roll-back attacks.
The security version number must be stored securely and persistently across power-on resets. A common weakness is that the security version number is modifiable by an adversary, allowing roll-back or downgrade attacks or, under certain circumstances, preventing upgrades (i.e. Denial-of-Service on upgrades). In both cases, the SoC is in a vulnerable state.

Primary

Architecture and Design

Implementation
Such issues could be introduced during hardware architecture and design, and can be identified later during testing or system configuration phases.

Confidentiality
Integrity
Authentication
Authorization
Other
High
Impact includes roll-back or downgrade to a vulnerable version of the firmware or DoS (prevent upgrades).

Automated Dynamic Analysis
Mutability of stored security version numbers and programming with older firmware images should be part of automated testing.
High

Architecture or Design Review
Anti-roll-back features should be reviewed as part of Architecture or Design review.
High

Architecture and Design
When architecting the system, security version data should be designated for storage in registers that are either read-only or have access controls that prevent modification by an untrusted agent.

Implementation
During implementation and test, security version data should be demonstrated to be read-only and access controls should be validated.

A new version of firmware is signed with a security version number higher than the previous version. During the firmware update process the SoC checks for the security version number and upgrades the SoC firmware with the latest version. This security version number is stored in persistent memory upon successful upgrade for use across power-on resets.
In general, if the security version number is mutable, the implementation is vulnerable. A mutable security version number allows an adversary to change the security version to a lower value to allow roll-back or to a higher value to prevent future upgrades.
The security version number should be stored in immutable hardware such as fuses, and the writes to these fuses should be highly access-controlled with appropriate authentication and authorization protections.

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
Intel Corporation
2020-04-25
4.3
2020-12-10

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2021-10-28
updated Demonstrative_Examples

CWE Content Team
MITRE
2022-04-28
updated Applicable_Platforms

CWE Content Team
MITRE
2022-06-28
updated Applicable_Platforms

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