---
id: "CVE-2026-127915"
page: "https://infrastack.ai/live/CVE-2026-127915"
kind: "vulnerability"
aliases: ["CVE-2026-127915"]
title: "MCUboot: TLV iterator can read past trailer area during image validation"
severity: "low"
cvss: 2.0
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["dfu", "embedded", "firmware", "mcuboot", "runtime"]
not_affected_if: ["default-config", "non-ram-load"]
published_at: "2026-11-13T02:18:55+00:00"
first_seen_at: "2026-11-13T02:41:36+00:00"
updated_at: "2026-11-13T02:43:14+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-127915", "first_seen_at": "2026-11-13T02:41:36+00:00"}]
exploit_sources: []
---

# MCUboot: TLV iterator can read past trailer area during image validation

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

The MCUboot bootloader's TLV iterator does not check that each entry stays inside the image trailer area, so a crafted image can cause an out-of-bounds read. The sources say the default flash build only fails validation with a bounded read, while the non-default RAM-load configuration has a genuine but bounded out-of-bounds read.

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

## How to check

- Check whether the device uses MCUboot's non-default `MCUBOOT_RAM_LOAD` configuration, which the sources identify as the affected case.
- Check the MCUboot version in the build, against the fixed version in the vendor advisory (unknown from the sources given).

## Fix

- The sources say the fix is to validate each TLV entry's header and payload against the iterator's end inside `bootutil_tlv_iter_next()`; no fixed version is stated in the sources.

## Timeline

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

## Documents

- [advisory] Vendor advisory: github.com https://github.com/mcu-tools/mcuboot/security/advisories/GHSA-4fp3-3qw2-25jv
- [fix] Patch: github.com https://github.com/mcu-tools/mcuboot/commit/90f4e7c3ebe4cf9a5eb7d981220388ffdefd6d19

## From the sources

The MCUboot TLV iterator bootutil_tlv_iter_next() in boot/bootutil/src/tlv.c walks image trailer TLVs with a single loop guard (it->tlv_off < it->tlv_end) and advances by sizeof(struct image_tlv) + tlv.it_len using the attacker-controlled it_len field, without validating that the entry's header or payload stays within it->tlv_end. As a result the 4-byte header read can extend up to 3 bytes past the declared TLV area, and the returned (off, len) can describe a payload that runs past it.

The path is pre-authentication: TLVs are parsed during bootutil_img_validate() before the signature is verified, and a crafted image can be presented through DFU / serial-recovery / OTA. However the impact is contained by surrounding guards: bootutil_img_validate() first rejects a TLV area larger than bootutil_max_image_size(), the default LOAD_IMAGE_DATA sink is flash_area_read() which bounds-checks against the flash partition and fails an out-of-partition read, and every payload consumer (EXPECTED_HASH_TLV, EXPECTED_KEY_TLV, EXPECTED_SIG_TLV, IMAGE_TLV_SEC_CNT) clamps len against a fixed buffer before copying.

The residual effect in a default flash build is therefore an out-of-region read confined to the attacker's own slot partition whose result is never observable, yielding at worst a clean validation failure rather than memory corruption or information disclosure. A genuine (though still bounded) out-of-bounds read remains under the non-default MCUBOOT_RAM_LOAD configuration, where LOAD_IMAGE_DATA is an unchecked memcpy. The fix is to validate each entry's header and payload against it->tlv_end inside the iterator.

---

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