Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.
CWE-1243 Base Incomplete
Sensitive Non-Volatile Information Not Protected During Debug
This vulnerability occurs when security-critical data stored in hardware fuses is left unprotected and accessible during debug modes.
Definition
What is CWE-1243?
This vulnerability occurs when security-critical data stored in hardware fuses is left unprotected and accessible during debug modes.
Modern chips store highly sensitive data—like encryption keys, root secrets, and unique manufacturer codes—in permanent hardware fuses. When the device powers on, this information is loaded into temporary registers or on-chip memory for runtime use. While normal software access to these locations is usually restricted, debug interfaces often bypass these protections entirely.
During debug or testing operations, these temporary storage locations remain exposed, allowing anyone with debug access to read the sensitive fuse data. This creates a significant hardware-level security gap, as an attacker can extract foundational secrets that underpin the device's entire security model, potentially compromising encryption, authentication, and secure boot processes.
Real-world impact
Real-world CVEs caused by CWE-1243
No public CVE references are linked to this CWE in MITRE's catalog yet.
How attackers exploit it
Step-by-step attacker path
- 1
Sensitive manufacturing data (such as die information) are stored in fuses. When the chip powers on, these values are read from the fuses and stored in microarchitectural registers. These registers are only given read access to trusted software running on the core. Untrusted software running on the core is not allowed to access these registers.
- 2
The example code below is taken from one of the AES cryptographic accelerators of the HACK@DAC'21 buggy OpenPiton SoC [REF-1366]. The operating system (OS) uses three AES keys to encrypt and decrypt sensitive data using this accelerator. These keys are sensitive data stored in fuses. The security of the OS will be compromised if any of these AES keys are leaked. During system bootup, these AES keys are sensed from fuses and stored in temporary hardware registers of the AES peripheral. Access to these temporary registers is disconnected during the debug state to prevent them from leaking through debug access. In this example (see the vulnerable code source), the registers key0, key1, and key2 are used to store the three AES keys (which are accessed through key_big0, key_big1, and key_big2 signals). The OS selects one of these three keys through the key_big signal, which is used by the AES engine.
- 3
The above code illustrates an instance of a vulnerable implementation for blocking AES key mechanism when the system is in debug mode (i.e., when debug_mode_i is asserted). During debug mode, key accesses through key_big0 and key_big1 are effectively disconnected, as their values are set to zero. However, the key accessed via the key_big2 signal remains accessible, creating a potential pathway for sensitive fuse data leakage, specifically AES key2, during debug mode. Furthermore, even though it is not strictly necessary to disconnect the key_big signal when entering debug mode (since disconnecting key_big0, key_big1, and key_big2 will inherently disconnect key_big), it is advisable, in line with the defense-in-depth strategy, to also sever the connection to key_big. This additional security measure adds an extra layer of protection and safeguards the AES keys against potential future modifications to the key_big logic.
- 4
To mitigate this, disconnect access through key_big2 and key_big during debug mode [REF-1367].
Vulnerable code example
Vulnerable Other
Sensitive manufacturing data (such as die information) are stored in fuses. When the chip powers on, these values are read from the fuses and stored in microarchitectural registers. These registers are only given read access to trusted software running on the core. Untrusted software running on the core is not allowed to access these registers.
All microarchitectural registers in this chip can be accessed through the debug interface. As a result, even an untrusted debugger can access this data and retrieve sensitive manufacturing data. Secure code example
Secure Other
Registers used to store sensitive values read from fuses should be blocked during debug. These registers should be disconnected from the debug interface. 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-1243
- Architecture and Design / Implementation Disable access to security-sensitive information stored in fuses directly and also reflected from temporary storage locations when in debug mode.
Detection signals
How to detect CWE-1243
Run dynamic application security testing against the live endpoint.
Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.
Code review: flag any new code that handles input from this surface without using the validated framework helpers.
Plexicus auto-detects CWE-1243 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-1243?
How serious is CWE-1243?
What languages or platforms are affected by CWE-1243?
How can I prevent CWE-1243?
How does Plexicus detect and fix CWE-1243?
Where can I learn more about CWE-1243?
Frequently asked questions
What is CWE-1243?
This vulnerability occurs when security-critical data stored in hardware fuses is left unprotected and accessible during debug modes.
How serious is CWE-1243?
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-1243?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Not Technology-Specific.
How can I prevent CWE-1243?
Disable access to security-sensitive information stored in fuses directly and also reflected from temporary storage locations when in debug mode.
How does Plexicus detect and fix CWE-1243?
Plexicus's SAST engine matches the data-flow signature for CWE-1243 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-1243?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1243.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-1243
Resources
Further reading
- MITRE — official CWE-1243 https://cwe.mitre.org/data/definitions/1243.html
- aes0_wrapper.sv https://github.com/HACK-EVENT/hackatdac21/blob/71103971e8204de6a61afc17d3653292517d32bf/piton/design/chip/tile/ariane/src/aes0/aes0_wrapper.sv#L56C1-L57C1
- fix cwe_1243 in aes0_wrapper.sv https://github.com/HACK-EVENT/hackatdac21/blob/cde1d9d6888bffab21d4b405ccef61b19c58dd3c/piton/design/chip/tile/ariane/src/aes0/aes0_wrapper.sv#L56
Ready when you are
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.