mcu-tools mcuboot up to 2.4.x Boot Record boot_record.c boot_save_boot_status uninitialized resource

Summaryinfo

A vulnerability has been found in mcu-tools mcuboot up to 2.4.x and classified as problematic. This vulnerability affects the function boot_save_boot_status of the file boot/bootutil/src/boot_record.c of the component Boot Record. Performing a manipulation results in uninitialized resource. This vulnerability was named CVE-2026-16662. The attack needs to be approached locally. There is no available exploit. The affected component should be upgraded.

Detailsinfo

A vulnerability, which was classified as problematic, was found in mcu-tools mcuboot up to 2.4.x. This affects the function boot_save_boot_status of the file boot/bootutil/src/boot_record.c of the component Boot Record. The manipulation with an unknown input leads to a uninitialized resource vulnerability. CWE is classifying the issue as CWE-908. The product uses or accesses a resource that has not been initialized. This is going to have an impact on confidentiality. The summary by CVE is:

boot_save_boot_status() in boot/bootutil/src/boot_record.c reads the image's EXPECTED_HASH_TLV into a stack buffer image_hash[IMAGE_HASH_SIZE] that is never zero-initialised. The TLV handler validates only the upper bound (len > sizeof(image_hash)) and then reads exactly len bytes, so a TLV shorter than IMAGE_HASH_SIZE leaves the tail of image_hash holding stale stack content. The subsequent copy into the boot record, memcpy(buf + offset, image_hash, sizeof(image_hash)), uses the fixed buffer size rather than len, so up to IMAGE_HASH_SIZE - 1 bytes of uninitialised bootloader stack are written into the measured-boot record. The defect is reachable only under MCUBOOT_MEASURED_BOOT, and only when the image reaching boot_save_boot_status() was not hash-validated on that boot. bootutil_img_validate() rejects a hash TLV whose length is not exactly sizeof(hash) (boot/bootutil/src/image_validate.c:345), and primary-slot validation is on by default (Zephyr's CONFIG_BOOT_VALIDATE_SLOT0 defaults to y), so in a default build the malformed image never reaches this code. The direct-XIP and RAM-load strategies in boot/bootutil/src/loader.c validate the selected slot unconditionally and are not affected. The short TLV survives only where the integrator has turned primary-slot validation off: the swap and overwrite loader built without MCUBOOT_VALIDATE_PRIMARY_SLOT, which checks only the image magic before calling boot_add_shared_data(), and the Zephyr single-slot loader (boot/zephyr/single_loader.c) built without it, including the MCUBOOT_VALIDATE_PRIMARY_SLOT_ONCE variant, which skips validation once the trailer records an earlier successful one. It is also reachable through a time-of-check/time-of-use change to tamperable external flash between validation and the boot-record read. Placing the crafted image requires physical or flash-write access to the device; in a single-slot build with serial recovery enabled, the serial-recovery upload writes the primary slot directly and can place it as well. In these configurations the boot record's measurement is already not trustworthy: with validation off, the hash copied into the record is the image's own unverified EXPECTED_HASH_TLV, which the attacker chooses. The defect therefore does not weaken attestation integrity any further. What it adds is a path for bootloader memory to leave the device: up to 63 bytes (IMAGE_HASH_SIZE - 1) of uninitialised bootloader stack are embedded in the measurement field that a downstream attestation service sends to a remote verifier. In the configurations analysed the residue is bootloader internal state (TLV offsets and lengths, flash addresses, loop state), not key material, but what occupies that stack region depends on configuration and on which code ran before boot_save_boot_status(). It is reported as a low-severity, defense-in-depth disclosure with no integrity or availability impact. This is distinct from the already-fixed record_len integer underflow in the same routine (GHSA-8hrv-4cp5-4rg3). The fix rejects any EXPECTED_HASH_TLV whose length is not exactly IMAGE_HASH_SIZE.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-16662 since 07/22/2026. The exploitability is told to be easy. An attack has to be approached locally. Additional levels of successful authentication are necessary for exploitation. Technical details are known, but no exploit is available.

Upgrading to version 2.5.0 eliminates this vulnerability. Applying the patch 5098d8eef1139abd3d821d8138a6321d656dcd3e is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Vendor

• mcu-tools

Name

• mcuboot

Version

• 2.0
• 2.1
• 2.2
• 2.3
• 2.4

Website

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

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion