CVE-2026-127915 json
TLV iterator does not bound each entry against the declared TLV area in MCUboot bootutil
published yesterday modified 7h ago also EUVD-2026-124791 , GHSA-4fp3-3qw2-25jv
Unreviewed: the maintainers' own advisory
Published by the maintainers on their GitHub repository mcu-tools/mcuboot. GitHub has not reviewed it into the GitHub Advisory Database, so the affected packages and versions are the maintainers' word. Read the full advisory on GitHub.
- cvss
- 2.0
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.1%
- EPSS 0.1% chance of exploitation in 30 days, percentile 3%
- public exploits
- 0
- none known
Summary
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.
Patch / fix
Is CVE-2026-127915 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerExploit prediction
0.15% chance of exploitation in the next 30 days, higher than 3% of all scored CVEs (FIRST EPSS, 2026-11-13).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 2.0 | CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L |
Affected products
- mcu-tools mcuboot
Classification
- Weakness
-
- CWE-125 Out-of-bounds Read
References
Sources
- CVE List CVE-2026-127915
- NVD CVE-2026-127915
- Maintainer advisory GHSA-4fp3-3qw2-25jv
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.
The maintainers of mcu-tools/mcuboot published their own advisory on GitHub. Reviewed sources take precedence over it.