mcu-tools mcuboot up to 2.0.0 Serial-Recovery Upload boot_serial.c bs_upload img_num integer coercion

Summaryinfo

A vulnerability described as problematic has been identified in mcu-tools mcuboot up to 2.0.0. This impacts the function bs_upload of the file boot/boot_serial/src/boot_serial.c of the component Serial-Recovery Upload Handler. Executing a manipulation of the argument img_num can lead to integer coercion. This vulnerability appears as CVE-2026-16664. The attack requires local access. There is no available exploit. It is advisable to implement a patch to correct this issue.

Detailsinfo

A vulnerability was found in mcu-tools mcuboot up to 2.0.0. It has been declared as problematic. This vulnerability affects the function bs_upload of the file boot/boot_serial/src/boot_serial.c of the component Serial-Recovery Upload Handler. The manipulation of the argument img_num with an unknown input leads to a integer coercion vulnerability. The CWE definition for the vulnerability is CWE-192. Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types. As an impact it is known to affect integrity, and availability. CVE summarizes:

MCUboot's Zephyr serial-recovery upload handler bs_upload() in boot/boot_serial/src/boot_serial.c decodes the host-supplied image field of an MCUmgr image-upload request into img_num (a full 32-bit value) and latches it on the off == 0 packet without any range check. It then passes img_num straight to flash_area_id_from_multi_image_slot(img_num, 0), which on the Zephyr port resolves to __flash_area_ids_for_slot() in boot/zephyr/include/sysflash/sysflash.h and indexes the static const int all_slots[] table as all_slots[img_num 2]. That table holds only MCUBOOT_IMAGE_NUMBER 2 entries, so any img_num >= MCUBOOT_IMAGE_NUMBER is an out-of-bounds read. The path is reachable by anyone with access to the serial / SMP recovery console, which is unauthenticated by design, and the bad value is supplied before any image signature is verified. The defect is specific to the default non-direct upload path (MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD disabled) on the Zephyr port with the array-backed slot layout (not CONFIG_SINGLE_APPLICATION_SLOT). It is not gated on a multi-image configuration: MCUBOOT_IMAGE_NUMBER defaults to 1, so even a default single-image build is affected for any image >= 1. The MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD path is safe (its flash_area_id_from_direct_image() switch returns -EINVAL for unknown indices). flash_area_id_from_multi_image_slot() takes a signed int image_index while img_num is uint32_t, so the attacker controls the sign of the index as well as its magnitude: an image of 0xFFFFFFFF converts to -1 and reads all_slots[-2], off the front of the table, while large positive values read off the end (CWE-192). Either way the index multiply img * 2 is performed in int, so a wild offset yields a bus/hard fault, giving a reliable denial of service of the bootloader during recovery. For moderately out-of-range indices the read returns adjacent .rodata as a garbage flash-area id that is handed to flash_area_open(); this normally fails with MGMT_ERR_EINVAL, but if the garbage id happens to match a valid non-image partition, the subsequent erase/write can target a partition outside the image set (CWE-787). The attacker-supplied value is never echoed back, so there is no information disclosure. The fix is to reject img_num >= BOOT_IMAGE_NUMBER on the off == 0 packet, before the slot lookup. The comparison must be made on the unsigned img_num: an equivalent guard applied after the conversion to int would not reject the negative case above. __flash_area_ids_for_slot() should bounds-check its own arguments as defence in depth. This vulnerability was reported independently twice: by NVIDIA Project Vanessa on 2026-06-22, and by Kai Phan (@kaimandalic) on 2026-07-19 as GHSA-8v33-88p6-jffj, which is closed as a duplicate of this advisory. Both original reports are reproduced in full below.

The advisory is shared for download at github.com. This vulnerability was named CVE-2026-16664 since 07/22/2026. The exploitation appears to be easy. The attack needs to be approached locally. There are known technical details, but no exploit is available.

Applying the patch 183a05f256bdbbac86edcb048958da59018f814e is able to eliminate this problem.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• mcu-tools

Name

• mcuboot

Version

• 2.0

Website

• Product: https://github.com/mcu-tools/mcuboot/

CPE 2.3info

• 🔒

CPE 2.2info

• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion