Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1000 CNY

100.0%
Buy Us a Coffee

CWE-1234 — Vulnerability Class 4

4 vulnerabilities classified as CWE-1234. AI Chinese analysis included.

CWE-1234 represents a critical configuration protection weakness where hardware internal or debug modes allow attackers to override system locks. Typically, device configurations are secured by trusted firmware modules that set lock bits to prevent unauthorized modifications to protected registers. However, if these locks can be bypassed during debug or internal hardware modes, malicious actors can exploit this vulnerability to alter critical system settings. This exploitation often involves accessing low-level hardware interfaces or utilizing debug ports to clear the lock bits before writing malicious configurations. To mitigate this risk, developers must rigorously disable or physically secure debug interfaces in production environments. Additionally, implementing hardware-enforced security measures that prevent lock bit modification regardless of the current operational mode ensures that configuration integrity remains intact against potential internal or external tampering attempts.

MITRE CWE Description
System configuration protection may be bypassed during debug mode. Device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification. This is commonly implemented using a trusted lock bit, which when set, disables writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). If debug features supported by hardware or internal modes/system states are supported in the hardware design, modification of the lock protection may be allowed allowing access and modification of configuration information.
Common Consequences (1)
Access ControlBypass Protection Mechanism
Bypass of lock bit allows access and modification of system configuration even when the lock bit is set.
Mitigations (1)
Architecture and Design, Implementation, TestingSecurity Lock bit protections should be reviewed for any bypass/override modes supported. Any supported override modes either should be removed or protected using authenticated debug modes. Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing.
Effectiveness: High
Examples (2)
For example, consider the example Locked_override_register example. This register module supports a lock mode that blocks any writes after lock is set to 1. However, it also allows override of the lock protection when scan_mode or debug_unlocked modes are active.
module Locked_register_example ( input [15:0] Data_in, input Clk, input resetn, input write, input Lock, input scan_mode, input debug_unlocked, output reg [15:0] Data_out ); reg lock_status; always @(posedge Clk or negedge resetn) if (~resetn) // Register is reset resetn begin lock_status <= 1'b0; end else if (Lock) begin lock_status <= 1'b1; end else if (~Lock) begin lock_status <= lock_status end always @(posedge Clk or negedge resetn) if (~resetn) // Register is reset resetn begin Data_out <= 16'h0000; end else if (write & (~lock_status | scan_mode | debug_unlocked) ) // Register protected
Bad · Verilog
Either remove the debug and scan mode overrides or protect enabling of these modes so that only trusted and authorized users may enable these modes.
Good · Other
The following example code [REF-1375] is taken from the register lock security peripheral of the HACK@DAC'21 buggy OpenPiton SoC. It demonstrates how to lock read or write access to security-critical hardware registers (e.g., crypto keys, system integrity code, etc.). The configuration to lock all the sensitive registers in the SoC is managed through the reglk_mem registers. These reglk_mem regist…
... always @(posedge clk_i) begin if(~(rst_ni && ~jtag_unlock && ~rst_9)) begin for (j=0; j < 6; j=j+1) begin reglk_mem[j] <= 'h0; end end ...
Bad · Verilog
... always @(posedge clk_i) begin if(~(rst_ni && ~rst_9)) begin for (j=0; j < 6; j=j+1) begin reglk_mem[j] <= 'h0; end end ...
Good · Verilog
CVE IDTitleCVSSSeverityPublished
CVE-2025-33242 NVIDIA B300 MCU 安全漏洞 — HGX and DGX B300 5.9 Medium2026-03-24
CVE-2025-59104 Unlocked Bootloader in dormakaba access manager — Access Manager 92xx-k7 6.8AIMediumAI2026-01-26
CVE-2023-44298 Dell PowerEdge Server BIOS 安全漏洞 — PowerEdge BIOS 3.6 Low2023-12-05
CVE-2023-44297 Dell PowerEdge Server BIOS 安全漏洞 — PowerEdge BIOS 7.1 High2023-12-05

Vulnerabilities classified as CWE-1234 represent 4 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.