CWE-1326: Missing Immutable Root of Trust in Hardware

Definition

What is CWE-1326?

This vulnerability occurs when a hardware chip lacks a permanent, unchangeable root of trust. Without this immutable foundation, attackers can bypass secure boot protections and run unauthorized or malicious code during the system startup process.

Secure boot in a System-on-Chip (SoC) relies on verifying signed boot code using a trusted key. The chip must also check critical hardware settings, like a 'secure boot enabled' fuse. Together, this code and configuration data form the Root of Trust (RoT), which is the absolute starting point for all security. If an attacker can modify this RoT, they can compromise the entire boot chain. To prevent this, the RoT must be stored in immutable memory, such as locked fuses or one-time-programmable (OTP) memory, after initial provisioning. This ensures the foundational security data cannot be rewritten. It's important to distinguish this from components like ROM, which should support secure, authenticated update mechanisms for authorized patches in the field, while the core RoT itself remains permanently fixed.

Real-world impact

Real-world CVEs caused by CWE-1326

No public CVE references are linked to this CWE in MITRE's catalog yet.

How attackers exploit it

Step-by-step attacker path

1
The RoT is stored in memory. This memory can be modified by an adversary. For example, if an SoC implements "Secure Boot" by storing the boot code in an off-chip/on-chip flash, the contents of the flash can be modified by using a flash programmer. Similarly, if the boot code is stored in ROM (Read-Only Memory) but the public key or the hash of the public key (used to enable "Secure Boot") is stored in Flash or a memory that is susceptible to modifications or writes, the implementation is vulnerable.
2
In general, if the boot code, key materials and data that enable "Secure Boot" are all mutable, the implementation is vulnerable.
3
Good architecture defines RoT as immutable in hardware. One of the best ways to achieve immutability is to store boot code, public key or hash of the public key and other relevant data in Read-Only Memory (ROM) or One-Time Programmable (OTP) memory that prevents further programming or writes.
4
The example code below is a snippet from the bootrom of the HACK@DAC'19 buggy OpenPiton SoC [REF-1348]. The contents of the bootrom are critical in implementing the hardware root of trust.
5
It performs security-critical functions such as defining the system's device tree, validating the hardware cryptographic accelerators in the system, etc. Hence, write access to bootrom should be strictly limited to authorized users or removed completely so that bootrom is immutable. In this example (see the vulnerable code source), the boot instructions are stored in bootrom memory, mem. This memory can be read using the read address, addr_i, but write access should be restricted or removed.

Vulnerable code example

Vulnerable Verilog

It performs security-critical functions such as defining the system's device tree, validating the hardware cryptographic accelerators in the system, etc. Hence, write access to bootrom should be strictly limited to authorized users or removed completely so that bootrom is immutable. In this example (see the vulnerable code source), the boot instructions are stored in bootrom memory, mem. This memory can be read using the read address, addr_i, but write access should be restricted or removed.

Vulnerable Verilog

...
  	always_ff @(posedge clk_i) begin
  		if (req_i) begin
  			if (!we_i) begin
  				raddr_q <= addr_i[$clog2(RomSize)-1+3:3];
  			 end else begin 
```
mem[addr_i[$clog2(RomSize)-1+3:3]] <= wdata_i;**  end end end ...

```
   // this prevents spurious Xes from propagating into the speculative fetch stage of the core 
  assign rdata_o = (raddr_q < RomSize) ? mem[raddr_q] : '0;
   ...

Secure code example

Secure Verilog

To mitigate this issue, remove the write access to bootrom memory. [REF-1349]

Secure Verilog

...
  	always_ff @(posedge clk_i) begin
```
if (req_i) begin** 
  		
  		```
  			raddr_q <= addr_i[$clog2(RomSize)-1+3:3];
  		 end
  	 end
   ...
   // this prevents spurious Xes from propagating into the speculative fetch stage of the core 
  assign rdata_o = (raddr_q < RomSize) ? mem[raddr_q] : '0;
   ...

What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.

Prevention checklist

How to prevent CWE-1326

Architecture and Design When architecting the system, the RoT should be designated for storage in a memory that does not allow further programming/writes.
Implementation During implementation and test, the RoT memory location should be demonstrated to not allow further programming/writes.

Detection signals

How to detect CWE-1326

Automated Dynamic Analysis High

Automated testing can verify that RoT components are immutable.

Architecture or Design Review High

Root of trust elements and memory should be part of architecture and design reviews.

Frequently asked questions

What is CWE-1326?

This vulnerability occurs when a hardware chip lacks a permanent, unchangeable root of trust. Without this immutable foundation, attackers can bypass secure boot protections and run unauthorized or malicious code during the system startup process.

How serious is CWE-1326?

MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.

What languages or platforms are affected by CWE-1326?

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Security Hardware, Not Technology-Specific.

How can I prevent CWE-1326?

When architecting the system, the RoT should be designated for storage in a memory that does not allow further programming/writes. During implementation and test, the RoT memory location should be demonstrated to not allow further programming/writes.

How does Plexicus detect and fix CWE-1326?

Plexicus's SAST engine matches the data-flow signature for CWE-1326 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-1326?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1326.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Related weaknesses

Weaknesses related to CWE-1326

CWE-693 Parent

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.

Get started free Book a demo

Missing Immutable Root of Trust in Hardware

What is CWE-1326?

Real-world CVEs caused by CWE-1326

Step-by-step attacker path

Vulnerable Verilog

Secure Verilog

How to prevent CWE-1326

How to detect CWE-1326

Plexicus auto-detects CWE-1326 and opens a fix PR in under 60 seconds.

Frequently asked questions

Weaknesses related to CWE-1326

Protection Mechanism Failure

Inadequate Detection or Handling of Adversarial Input Perturbations in Automated Recognition Mechanism

Semiconductor Defects in Hardware Logic with Security-Sensitive Implications

Incorrect Selection of Fuse Values

Product Released in Non-Release Configuration

Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques

Public Key Re-Use for Signing both Debug and Production Code

Missing Support for Security Features in On-chip Fabrics or Buses

Improper Protection against Electromagnetic Fault Injection (EM-FI)

Further reading

Don't Let Security
Weigh You Down.

Missing Immutable Root of Trust in Hardware

What is CWE-1326?

Real-world CVEs caused by CWE-1326

Step-by-step attacker path

Vulnerable Verilog

Secure Verilog

How to prevent CWE-1326

How to detect CWE-1326

Plexicus auto-detects CWE-1326 and opens a fix PR in under 60 seconds.

Frequently asked questions

Weaknesses related to CWE-1326

Protection Mechanism Failure

Inadequate Detection or Handling of Adversarial Input Perturbations in Automated Recognition Mechanism

Semiconductor Defects in Hardware Logic with Security-Sensitive Implications

Incorrect Selection of Fuse Values

Product Released in Non-Release Configuration

Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques

Public Key Re-Use for Signing both Debug and Production Code

Missing Support for Security Features in On-chip Fabrics or Buses

Improper Protection against Electromagnetic Fault Injection (EM-FI)

Further reading

Don't Let SecurityWeigh You Down.

Don't Let Security
Weigh You Down.