CWE-1262: Improper Access Control for Register Interface
The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.
Last updated
Overview
Software commonly accesses peripherals in a System-on-Chip (SoC) or other device through a memory-mapped register interface. Malicious software could tamper with any security-critical hardware data that is accessible directly or indirectly through the register interface, which could lead to a loss of confidentiality and integrity.
Real-world CVEs
10 recorded CVEs are caused by CWE-1262 (Improper Access Control for Register Interface). The highest-severity and most recent are shown first. 3 new CWE-1262 CVEs have been recorded so far in 2026 (5 in 2025).
- CVE-2023-20599High · CVSS 7.9 · EPSS 5th2025-06-10
- CVE-2025-47385
Improper Access Control for Register Interface in SCE-Mink
High · CVSS 7.8 · EPSS 0th2026-03-02 - CVE-2015-8325High · CVSS 7.8 · EPSS 46th2016-05-01
- CVE-2024-6354High · CVSS 7.2 · EPSS 52th2024-06-26
- CVE-2024-45556Medium · CVSS 6.5 · EPSS 1th2025-04-07
- CVE-2024-57492Medium · CVSS 6.0 · EPSS 8th2025-03-10
- CVE-2025-20788Medium · CVSS 4.4 · EPSS 0th2025-12-02
- CVE-2025-54509Medium · CVSS 4.0 · EPSS 3th2026-06-09
- CVE-2025-36194
This Power System update is being released to address
Low · CVSS 3.3 · EPSS 2th2026-02-02 - CVE-2025-1882
i-Drive i11/i12 Device Setting improper access control for register interface
Low · CVSS 2.3 · EPSS 9th2025-03-03
Common consequences
What can happen when CWE-1262 is exploited.
Read Memory, Read Application Data, Modify Memory, Modify Application Data, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Unexpected State, Alter Execution Logic
Affects: Confidentiality, Integrity
Confidentiality of hardware assets may be violated if the protected information can be read out by software through the register interface. Registers storing security state, settings, other security-critical data may be corruptible by software without correctly implemented protections.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
How to prevent it
Practical mitigations for CWE-1262, grouped by where in the lifecycle they apply.
Design proper policies for hardware register access from software.
Ensure that access control policies for register access are implemented in accordance with the specified design.
How to detect it
Manual Analysis
This is applicable in the Architecture phase before implementation started. Make sure access policy is specified for the entire memory map. Manual analysis may not ensure the implementation is correct.
Effectiveness: Moderate
Manual Analysis
Registers controlling hardware should have access control implemented. This access control may be checked manually for correct implementation. Items to check consist of how are trusted parties set, how are trusted parties verified, how are accesses verified, etc. Effectiveness of a manual analysis will vary depending upon how complicated the interface is constructed.
Effectiveness: Moderate
Simulation / Emulation
Functional simulation is applicable during the Implementation Phase. Testcases must be created and executed for memory mapped registers to verify adherence to the access control policy. This method can be effective, since functional verification needs to be performed on the design, and verification for this weakness will be included. There can be difficulty covering the entire memory space during the test.
Effectiveness: Moderate
Formal Verification
Formal verification is applicable during the Implementation phase. Assertions need to be created in order to capture illegal register access scenarios and prove that they cannot occur. Formal methods are exhaustive and can be very effective, but creating the cases for large designs may be complex and difficult.
Effectiveness: High
Automated Analysis
Information flow tracking can be applicable during the Implementation phase. Security sensitive data (assets) - for example, as stored in registers - is automatically tracked over time through the design to verify the data doesn't reach illegal destinations that violate the access policies for the memory map. This method can be very effective when used together with simulation and emulation, since detecting violations doesn't rely on specific scenarios or data values. This method does rely on simulation and emulation, so testcases must exist in order to use this method.
Effectiveness: High
Architecture or Design Review
Manual documentation review of the system memory map, register specification, and permissions associated with accessing security-relevant functionality exposed via memory-mapped registers.
Effectiveness: Moderate
Fuzzing
Perform penetration testing (either manual or semi-automated with fuzzing) to verify that access control mechanisms such as the memory protection units or on-chip bus firewall settings adequately protect critical hardware registers from software access.
Effectiveness: Moderate
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The register interface provides software access to hardware functionality. This functionality is an attack surface. This attack surface may be used to run untrusted code on the system through the register interface. As an example, cryptographic accelerators require a mechanism for software to select modes of operation and to provide plaintext or ciphertext data to be encrypted or decrypted as well as other functions. This functionality is commonly provided through registers.
The example code is taken from the Control/Status Register (CSR) module inside the processor core of the HACK@DAC'19 buggy CVA6 SoC [REF-1340]. In RISC-V ISA [REF-1341], the CSR file contains different sets of registers with different privilege levels, e.g., user mode (U), supervisor mode (S), hypervisor mode (H), machine mode (M), and debug mode (D), with different read-write policies, read-only (RO) and read-write (RW). For example, machine mode, which is the highest privilege mode in a RISC-V system, registers should not be accessible in user, supervisor, or hypervisor modes.
Vulnerable example
if (csr_we || csr_read) beginSafe example
if (csr_we || csr_read) beginIllustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2014-2915 — virtualization product does not restrict access to debug and other processor registers in the hardware, allowing a crash of the host or guest OS
- CVE-2021-3011 — virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
- CVE-2020-12446 — Driver exposes access to Model Specific Register (MSR) registers, allowing admin privileges.
- CVE-2015-2150 — Virtualization product does not restrict access to PCI command registers, allowing host crash from the guest.
Attack patterns
CAPEC attack patterns that exploit this weakness.
Frequently asked questions
Common questions about CWE-1262.
- What is CWE-1262?
- The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.
- What CVEs are caused by CWE-1262?
- 10 recorded CVEs are attributed to CWE-1262, including CVE-2023-20599, CVE-2025-47385, CVE-2015-8325.
- How do you prevent CWE-1262?
- Design proper policies for hardware register access from software.
- How is CWE-1262 detected?
- Manual Analysis: This is applicable in the Architecture phase before implementation started. Make sure access policy is specified for the entire memory map. Manual analysis may not ensure the implementation is correct.
- What are the consequences of CWE-1262?
- Exploiting CWE-1262 can lead to: Read Memory, Read Application Data, Modify Memory, Modify Application Data, Gain Privileges or Assume Identity, Bypass Protection Mechanism.
- Is CWE-1262 actively exploited?
- 10 recorded CVEs are caused by CWE-1262; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-1262) (opens in a new tab)
- CWE-1262 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-1262
Get alerted the moment a new CWE-1262 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.