CVE-2026-16664mcu-tools mcuboot improper array index validation
CVE-2026-16664 is a improper array index validation in mcu-tools mcuboot, rated medium (5.1 on CVSS 3.1).
Why this priority: Medium severity, with no exploitation signal.
Published · Updated · NVD status: Received
What it is
An index from input is used without a bounds check.
How it is reached
An attacker can exploit it by someone who can already run code or sign in on the machine, without an account, and nobody has to click anything.
What an attacker gains
The direct impact is limited: partial access to data or a partial outage. In practice, this kind of flaw lets an attacker crash the process, read memory, or in the worst case run code.
Is it being exploited?
There is no public report of exploitation yet.
What to do
- No fixed version is listed yet. Find every place mcu-tools mcuboot runs, watch the references for a fix, and plan a replacement if it is no longer supported.
- Limit who can run code or sign in on the hosts that run it.
Description from NVD
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.
What this means for your architecture.
A CVE names a product. Whether it matters depends on where that product sits in your systems: what reaches it, which trust boundary it guards and what it can reach once compromised. Veriom maps your components, their relationships and your trust boundaries from your code, cloud and delivery evidence, so you can see where a component like this sits. The radar itself does not look at your systems.
Components it touches
- Native code: operating systems, browsers and firmware. The flaw sits wherever native code reads untrusted data.
- Network appliances and media or file parsers. The flaw sits wherever native code reads untrusted data.
Trust boundaries in play
- Host boundary. The attacker needs a foothold on the machine first; the flaw turns a small foothold into a bigger one.
- Wherever native code reads untrusted data. An attacker who crosses it can crash the process, read memory, or in the worst case run code.
Questions to answer about your own systems
- Where does mcu-tools mcuboot run in your systems, and at which version?
- Which of those hosts also run code or users you do not fully trust?
- What can it reach once compromised: which data stores, secrets and services?
Sources
- CVE records and CVSS scores from the NVD CVE API. This product uses the NVD API but is not endorsed or certified by the NVD.
- Exploitation status from CISA’s Known Exploited Vulnerabilities catalog.
- Exploit likelihood from FIRST’s Exploit Prediction Scoring System (EPSS), refreshed daily.
- Explanations are written by Veriom from fixed templates over each record’s data, not by a person reviewing each CVE. Descriptions are quoted from the records as published.