CVE-2026-14296 in nRF54H20
Summary
by MITRE • 09/07/2026
When using the Direct XIP update strategy, the main application image starts other cores (i.e. radio core), based on the currently active slot without additional verification. The MCUboot in the bare (upstream) configuration assumes that if there is at least a single slot for each image available, the system is bootable and continues the boot process. This may lead to a situation when MCUboot picks different slot for different images (i.e. (a) for the main application and (b) for the radio image), boots the main application (from slot (a)) that afterwards starts the radio image by providing an address of the unauthenticated slot ((a) instead of (b)).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability described involves a critical flaw in the MCUboot implementation when operating under the Direct XIP update strategy, specifically concerning the authentication and verification processes for multi-core systems. In this architecture, the main application image is responsible for initializing other cores, such as a radio core, by providing them with memory addresses to execute code from specific flash slots. The root cause of the vulnerability lies in the assumption made by MCUboot in its bare or upstream configuration that the presence of at least one valid slot per image type guarantees system bootability without performing cross-image consistency checks during the transition phase. This design oversight allows for a scenario where different images are loaded from different, potentially mismatched slots based on individual validity rather than coordinated integrity across all components required for system operation.
During the boot process, MCUboot evaluates each available slot to determine which image is active and valid. If multiple slots exist, it may select one slot for the main application and a separate, distinct slot for the radio firmware if both are individually deemed acceptable by their respective validation criteria. Consequently, the bootloader successfully initiates the system using these disparate sources. The primary issue arises when the main application, now running from its selected slot, proceeds to start the secondary core. Instead of verifying that the radio image corresponds to a trusted and authenticated version consistent with the current boot context, it blindly uses the address associated with the currently active or previously identified slot for the radio component. This lack of additional verification means the system may load an unauthenticated or potentially compromised binary onto the secondary processor.
The operational impact of this flaw is severe, as it effectively bypasses the security guarantees provided by secure boot mechanisms. By allowing the main application to launch code from a slot that has not been authenticated in the context of the current boot session, attackers could exploit this behavior if they have gained partial control over flash memory or can influence which slots are marked active. This creates an attack vector where malicious firmware on one core can be executed without proper integrity checks, potentially leading to full system compromise, data exfiltration, or denial of service through unstable execution environments. The vulnerability undermines the principle of least privilege and trust boundaries between different processing units within a System-on-Chip environment.
To mitigate this risk, it is essential to enhance the verification logic during the Direct XIP update strategy implementation. Developers should ensure that when the main application initializes other cores, it performs strict authentication checks on the target image before passing its execution address. This can be achieved by integrating additional signature validation steps or ensuring that MCUboot enforces slot consistency across all images required for a successful boot state. Furthermore, adopting a configuration where MCUboot validates the entire set of active slots as a cohesive unit rather than individually could prevent mismatched loading scenarios. Aligning with industry standards such as CWE-295 Improper Certificate Validation and ATT&CK techniques related to unauthorized access or execution can help in identifying similar weaknesses in embedded systems security architectures, ensuring that all components are verified against trusted sources before execution begins.