Description

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)).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-07T08:17:11.773Z",
  "pubdate": "2026-09-07T08:17:11.773Z",
  "executiveSummary": "This vulnerability involves an improper validation mechanism within the MCUboot bootloader, specifically when employing the Direct XIP (Execute-in-Place) update strategy for multi-core systems.\nThe flaw allows the system to boot a main application image from one slot while subsequently executing an unverified or mismatched radio core image from a different slot, violating the integrity of the combined system image state.\nThe root cause lies in MCUboot's assumption that the mere presence of at least one valid slot for each image confirms a bootable system, failing to enforce strict synchronization or verify the pairing of image slots.\nAn attacker capable of influencing the flash memory or update process can cause the main application to execute an unauthenticated or unintended radio core image.\nThis potentially facilitates cross-slot code execution, privilege escalation, or the bypass of secure boot policies for the secondary core.\nThe vulnerability affects multi-core systems relying on MCUboot for firmware management in a Direct XIP configuration.",
  "technicalDetails": "The vulnerability originates in the logic governing multi-image boot sequences within MCUboot, particularly under the Direct XIP update strategy. In a multi-core environment, the system is expected to maintain coherent versions of images across multiple cores to ensure compatibility and security. However, the current implementation of MCUboot performs independent slot selection for different images.\nRoot Cause: The bootloader verifies each image individually and considers the system bootable if at least one valid slot exists for every required image. It lacks a binding mechanism that mandates the active slot for the main application (e.g., slot A) must correspond to a validated, trusted radio core image in the same versioning or security context (e.g., also slot A).\nAttack Flow: 1) An attacker manipulates the system's flash partition, perhaps by partially updating images or modifying image trailers. 2) MCUboot proceeds with the boot process, selecting a valid main application image from slot 'a'. 3) Simultaneously, due to the lack of slot-pairing verification, MCUboot may select a different slot, such as 'b', for the secondary radio core image. 4) The main application initializes and, following its internal logic, attempts to start the radio core. 5) By referencing the address of the unauthenticated or mismatched slot (or incorrectly assuming the radio image should be pulled from the same index as the app), the main application executes code located in a potentially compromised or legacy partition.\nExploitation: If an attacker can introduce an arbitrary radio image into a secondary slot, they can trick the primary application into starting this unverified code. Because the primary application trusts its own boot context, it provides the address of the unverified radio binary to the hardware's secondary core. This results in the execution of arbitrary code on the radio core with the same privileges as the legitimate radio firmware.\nImpact: The exploitation leads to a compromise of the radio core, which may be leveraged to intercept sensitive communications, perform malicious radio-frequency operations, or serve as a vector to compromise the main application core through inter-processor communication (IPC) channels. The vulnerability effectively bypasses the integrity checks that MCUboot is intended to enforce."
}