CVE-2026-16671: Out-of-bounds stack write in MCUboot split-image validation with SHA-384/SHA-512 builds

Published Nov 13, 2026
·
Updated

splitimagecheck() in boot/bootutil/src/loader.c declares a fixed uint8t loaderhash[32] buffer and passes it as the outhash out-parameter to bootutilimgvalidate(). That routine copies IMAGEHASHSIZE bytes into outhash (memcpy(outhash, hash, IMAGEHASHSIZE) in boot/bootutil/src/imagevalidate.c), where IMAGEHASHSIZE is a compile-time constant of 64 for MCUBOOTSHA512 or 48 for MCUBOOTSIGNEC384/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 (splitgo()/splitimagecheck(), i.e. neither MCUBOOTDIRECTXIP nor MCUBOOTRAMLOAD), the digest must be larger than 32 bytes (MCUBOOTSHA512 or MCUBOOTSIGNEC384), and MCUBOOTSIGNPURE must be off. splitgo() 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 loaderhash to IMAGEHASHSIZE and pass IMAGEHASHSIZE as the matching seed length.

Event History

Nov 13, 2026
CVE Published
via MITRE·12:23 AM
Data Sourced
via MITRE·12:23 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·02:18 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are affected?

Only builds that use the legacy Mynewt split-image feature, use SHA-512 or EC384/SHA-384, and have MCUBOOT_SIGN_PURE disabled are affected. Default SHA-256 builds are not affected.

2

Does an attacker need to invoke MCUboot directly?

No internal MCUboot caller invokes split_go(); it is a public API invoked by a Mynewt application. Exposure therefore depends on whether the application calls this split-image path.

3

How can I determine whether my build has the vulnerable configuration?

Check whether the build is neither MCUBOOT_DIRECT_XIP nor MCUBOOT_RAM_LOAD, whether MCUBOOT_SHA512 or MCUBOOT_SIGN_EC384 is enabled, and whether MCUBOOT_SIGN_PURE is disabled. All of these conditions must be present for the overflow to occur.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203