{"id":"CVE-2026-127915","summary":"TLV iterator does not bound each entry against the declared TLV area in MCUboot bootutil","details":"The MCUboot TLV iterator bootutil_tlv_iter_next() in boot/bootutil/src/tlv.c walks image trailer TLVs with a single loop guard (it-\u003etlv_off \u003c it-\u003etlv_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-\u003etlv_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.\n\nThe 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.\n\nThe 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-\u003etlv_end inside the iterator.","aliases":["GHSA-4fp3-3qw2-25jv"],"modified":"2026-11-14T02:47:05.243445487Z","published":"2026-11-13T00:23:07.449Z","database_specific":{"cwe_ids":["CWE-125"],"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/127xxx/CVE-2026-127915.json","cna_assigner":"zephyr"},"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/127xxx/CVE-2026-127915.json"},{"type":"ADVISORY","url":"https://github.com/mcu-tools/mcuboot/security/advisories/GHSA-4fp3-3qw2-25jv"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-127915"},{"type":"FIX","url":"https://github.com/mcu-tools/mcuboot/commit/90f4e7c3ebe4cf9a5eb7d981220388ffdefd6d19"},{"type":"PACKAGE","url":"https://github.com/mcu-tools/mcuboot"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/mcu-tools/mcuboot","events":[{"introduced":"b6efee9deb9d748cb2f0856a520becc67d808214"},{"fixed":"725d63c9d5bc1bb572d802e7a768daf504186daf"},{"fixed":"90f4e7c3ebe4cf9a5eb7d981220388ffdefd6d19"}],"database_specific":{"extracted_events":[{"range":[{"introduced":"0.9.0"},{"fixed":"2.5.0"}],"source":"AFFECTED_FIELD","strategy":"StandardRange"},{"range":[{"fixed":"90f4e7c3ebe4cf9a5eb7d981220388ffdefd6d19"}],"source":"REFERENCES_COMMIT"}]}}],"versions":["v2.4.0","v2.4.0-rc1","v2.3.0","v2.3.0-rc2","v2.3.0-rc1","v2.2.0","v2.2.0-rc2","v2.2.0-rc1","v2.1.0","v2.1.0-rc1","v2.0.0","v2.0.0-rc1","v1.10.0","v1.10.0-rc1","v1.9.0","v1.9.0-rc2","v1.9.0-rc1","v1.8.0","v1.8.0-rc1","TF-Mv1.4-integ-rc2","TF-Mv1.4-integ","TF-Mv1.4-integ-rc1","v1.7.0","v1.7.0-rc2","1.7.0-rc1","TF-Mv1.2-integ","TF-Mv1.3-integ","v1.6.1-cypress","cypress-latest-v1.X","v1.6.0","v1.6.0-cypress","v1.6.0-rc2","v1.6.0-rc1","v1.5.0-cypress","v1.5.0","v1.5.0-rc2","v1.5.0-rc1","v1.4.0","v1.4.0-rc2","v1.4.0-rc1","v1.3.1-rc1","v1.3.1","v1.3.0","v1.3.0-rc3","v1.3.0-rc2","v1.3.0-rc1","v1.2.0-rc5","v1.2.0","v1.2.0-rc4","v1.2.0-rc3","v1.2.0-rc2","v1.2.0-rc1","v1.1.0-rc2","v1.1.0","v1.1.0-rc1","v1.0.0","v1.0.0-rc3","v1.0.0-rc2","v1.0.0-rc1","v0.9.0"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-127915.json"}}],"schema_version":"1.9.2","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L"}]}