MCUBOOT · CVE-2026-16671 · Package
NO FIX YET
In MCUboot's legacy Mynewt split-image path, a 32-byte stack buffer receives a 48- or 64-byte digest when built with SHA-384 or SHA-512 signing. The overrun corrupts the bootloader's stack, which may cause instability or a failed boot rather than reliable code execution.
first public Nov 12, 2026 · 1 source
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Only builds of MCUboot that use the legacy Mynewt split-image feature with a SHA-384 or SHA-512 digest, with MCUBOOT_SIGN_PURE off, are exposed. Default SHA-256 builds and projects using direct XIP or RAM load are not affected. The sources state the fix as sizing the buffer to IMAGE_HASH_SIZE, but no fixed release version is given.
Not affected if default-config, direct-xip, ram-load, sha256-only, sign-pure
Who cares embedded, mcuboot, mynewt
MCUBOOT_SHA512 or MCUBOOT_SIGN_EC384, and whether MCUBOOT_DIRECT_XIP, MCUBOOT_RAM_LOAD and MCUBOOT_SIGN_PURE are absentsplit_go()) is compiled inUnknown from the sources.
split_image_check() in boot/bootutil/src/loader.c declares a fixed uint8_t loader_hash[32] buffer and passes it as the out_hash out-parameter to bootutil_img_validate(). That routine copies IMAGE_HASH_SIZE bytes into out_hash (memcpy(out_hash, hash, IMAGE_HASH_SIZE) in boot/bootutil/src/image_validate.c), where IMAGE_HASH_SIZE is a compile-time constant of 64 for MCUBOOT_SHA512 or 48 for MCUBOOT_SIGN_EC384/SHA-384 (boot/bootutil/include/bootutil/crypto/sha.h). The buffer tracks SHA-256 (32 bytes) while the copy length tracks the configured algorithm, so the write overruns the buffer by 16 or 32 bytes.
The overflow is only present in a non-default configuration: the legacy Mynewt split-image feature must be compiled (split_go()/split_image_check(), i.e. neither MCUBOOT_DIRECT_XIP nor MCUBOOT_RAM_LOAD), the digest must be larger than 32 bytes (MCUBOOT_SHA512 or MCUBOOT_SIGN_EC384), and MCUBOOT_SIGN_PURE must be off. split_go() is a public API with no caller inside MCUboot; it is invoked from a Mynewt application. In the default SHA-256 build there is no overflow.
The over-written bytes are the one-way digest of the loader image and the overflow length is fixed at build time, so the contents are not meaningfully attacker-controlled and the size is not attacker-chosen. The realistic impact is bounded, uncontrolled corruption of the bootloader's stack on the split-boot path, manifesting as instability or failed boot in the affected configuration rather than reliable code execution. The fix is to size loader_hash to IMAGE_HASH_SIZE and pass IMAGE_HASH_SIZE as the matching seed length.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.