CVE-2026-14296: nRF54H20: MCUBoot can be tricked to executing unauthenticated code
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)).
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using nRF54H20 with the Direct XIP update strategy are exposed when the main application starts another core, such as the radio core. The issue concerns systems with separate image slots for the main application and the secondary-core image.
Is the upstream MCUboot configuration affected?
Yes. The bare upstream MCUboot configuration is affected because it considers the system bootable when at least one slot is available for each image, without ensuring that all selected images come from corresponding authenticated slots.
What conditions does exploitation require?
The supplied CVSS vector indicates adjacent-network attack access, no privileges, and no user interaction, but high attack complexity. Exploitation depends on causing MCUboot to select different slots for the main application and the secondary-core image.
What is the impact if exploitation succeeds?
The main application can start a secondary-core image from an unauthenticated slot by providing that slot's address to the other core. The reported impact includes high confidentiality, integrity, and availability effects.