CWE-1326 Base Draft

Missing Immutable Root of Trust in Hardware

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…

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.
Auswirkungen in der Praxis

Real-world CVEs caused by CWE-1326

Bisher sind in MITREs Katalog keine öffentlichen CVE-Referenzen mit dieser CWE verknüpft.

Wie Angreifer es ausnutzen

Angreiferpfad Schritt für Schritt

  1. 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. 2

    In general, if the boot code, key materials and data that enable "Secure Boot" are all mutable, the implementation is vulnerable.

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

Verwundbares Codebeispiel

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.

Verwundbar 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;
   ...
Sicheres Codebeispiel

Secure Verilog

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

Sicher 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.
Präventions-Checkliste

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

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.

CWE-1326

Don't catalog this weakness. Prove it's reachable.

Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.

Häufig gestellte Fragen

Frequently asked questions

Was ist 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.

Wie gravierend ist CWE-1326?

MITRE hat für diese Schwachstelle keine Exploit-Wahrscheinlichkeit veröffentlicht. Behandle sie als mittlere Auswirkung, bis dein Threat Model anderes belegt.

Welche Sprachen oder Plattformen sind von CWE-1326 betroffen?

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

Wie kann ich CWE-1326 verhindern?

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.

Wie erkennt und behebt Plexicus CWE-1326?

Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-1326 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.

Wo erfahre ich mehr über CWE-1326?

MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/1326.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.

Verwandte Schwachstellen

Weaknesses related to CWE-1326

CWE-693 Parent

Protection Mechanism Failure

This weakness occurs when software either lacks a necessary security control, implements one that is too weak, or fails to activate an…

CWE-1039 Sibling

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

This vulnerability occurs when a system uses automated AI or machine learning to classify complex inputs like images, audio, or text, but…

CWE-1248 Sibling

Semiconductor Defects in Hardware Logic with Security-Sensitive Implications

A security-critical hardware component contains physical flaws in its semiconductor material, which can cause it to malfunction and…

CWE-1253 Sibling

Incorrect Selection of Fuse Values

This vulnerability occurs when a hardware security fuse is incorrectly programmed to represent a 'secure' state as logic 0 (unblown). An…

CWE-1269 Sibling

Product Released in Non-Release Configuration

This vulnerability occurs when a product ships to customers while still configured with its pre-production or manufacturing settings,…

CWE-1278 Sibling

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

This vulnerability occurs when hardware lacks safeguards against physical inspection, allowing attackers to extract sensitive data by…

CWE-1291 Sibling

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

This vulnerability occurs when the same cryptographic key is used to sign both development/debug software builds and final production…

CWE-1318 Sibling

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

This vulnerability occurs when the communication channels (fabrics or buses) within a chip lack built-in or enabled security features,…

CWE-1319 Sibling

Improper Protection against Electromagnetic Fault Injection (EM-FI)

This vulnerability occurs when a hardware device lacks sufficient shielding against electromagnetic interference, allowing attackers to…

Bereit, das Wesentliche zu validieren?

Bereit zu validieren, was zählt.

Plexicus ist Proof-Driven AppSec: validierte Funde, kontextuelles Verständnis und geprüfte Remediation — in Evidenz verankert, mit Ihnen gescoped.

Qualifizierung

Prüfen Sie, ob AI Swarm Pentest zu Ihrer Umgebung passt.

Teilen Sie den wichtigsten Kontext. Wir prüfen den Umfang und nennen den nächsten kommerziellen Schritt.

Vor dem Absenden — prüfen Sie, ob Sie passen

0 / 280

Keine Verpflichtung. Wenn Sie nicht passen, sagen wir es Ihnen.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Private Runde Für Investoren