---
id: "CVE-2026-16671"
page: "https://infrastack.ai/live/CVE-2026-16671"
kind: "vulnerability"
aliases: ["CVE-2026-16671"]
title: "MCUboot: split-image hash buffer overflows stack in non-default builds"
severity: "low"
cvss: 2.9
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "mcuboot", "fixed": [], "affected": "", "ecosystem": "vendor"}]
ecosystems: ["vendor"]
tags: ["embedded", "mcuboot", "mynewt", "package"]
not_affected_if: ["default-config", "direct-xip", "ram-load", "sha256-only", "sign-pure"]
published_at: "2026-11-13T02:18:57+00:00"
first_seen_at: "2026-11-13T02:41:37+00:00"
updated_at: "2026-11-13T02:43:06+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16671", "first_seen_at": "2026-11-13T02:41:37+00:00"}]
exploit_sources: []
---

# MCUboot: split-image hash buffer overflows stack in non-default builds

Link for people: https://infrastack.ai/live/CVE-2026-16671 (this .md is for agents)

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.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:mcuboot affected range not listed fixed no fixed version listed

## How to check

- Check whether the build defines `MCUBOOT_SHA512` or `MCUBOOT_SIGN_EC384`, and whether `MCUBOOT_DIRECT_XIP`, `MCUBOOT_RAM_LOAD` and `MCUBOOT_SIGN_PURE` are absent
- Confirm the Mynewt split-image feature (`split_go()`) is compiled in
- The default SHA-256 build is not affected

## Timeline

- 2026-11-13T02:41:37+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-16671

## Documents

- [advisory] Vendor advisory: github.com https://github.com/mcu-tools/mcuboot/security/advisories/GHSA-vj6q-r752-fpqv
- [fix] Patch: github.com https://github.com/mcu-tools/mcuboot/commit/9fb70f00173766d73cdadd82266bd61e4ddd0252

## 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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_