CVE-2026-127928mcu-tools mcuboot vulnerability
CVE-2026-127928 is a vulnerability in mcu-tools mcuboot, rated low (2.0 on CVSS 3.1).
Why this priority: Low severity, with no exploitation signal.
Published · Updated · NVD status: Received
What it is
The record does not classify the weakness yet; the description below says what the reporter found.
How it is reached
An attacker can exploit it with physical access to the device, without an account, and nobody has to click anything. Success also depends on conditions the attacker does not fully control.
What an attacker gains
The direct impact is limited: partial access to data or a partial outage.
Is it being exploited?
There is no public report of exploitation yet.
What to do
- Upgrade mcu-tools mcuboot to 2.5.0 or later.
Description from NVD
In MCUboot's serial-recovery encrypted-image support (boot/boot_serial/src/boot_serial_encryption.c), decrypt_image_inplace() and boot_image_validate_encrypted() each keep a stack-local struct boot_status. boot_enc_load() writes the plaintext per-image AES key into its enckey[] field. Neither function cleared this structure before returning. In addition, a decrypt failure inside the per-sector loop of decrypt_image_inplace() returned early and skipped the total_out: cleanup, which left the expanded AES key context (enc_data) on the stack as well. The error paths of boot_image_validate_encrypted() similarly skipped boot_enc_zeroize().
The affected code is built when encrypted images (MCUBOOT_ENC_IMAGES, Zephyr CONFIG_BOOT_ENCRYPT_IMAGE) are combined with serial recovery. It runs when an encrypted image is uploaded to the primary slot over the recovery protocol, and when the image list or state is queried while an encrypted image is in the secondary slot. After these functions return, the image's AES content key remains in dead stack memory. An attacker who can later read device RAM, for example through a debug port or retained RAM, can recover it.
This weakens the confidentiality of image-encryption keys within the bootloader trust boundary. A recovered key exposes the plaintext of the encrypted firmware image it protects. The device's long-term private decryption key is not exposed. No remote or recovery-protocol channel that returns this memory is known, so exploitation requires a separate memory-read capability.
What this means for your architecture.
A CVE names a product. Whether it matters depends on where that product sits in your systems: what reaches it, which trust boundary it guards and what it can reach once compromised. Veriom maps your components, their relationships and your trust boundaries from your code, cloud and delivery evidence, so you can see where a component like this sits. The radar itself does not look at your systems.
Components it touches
- mcu-tools mcuboot. Start from where it runs and what it is connected to.
Trust boundaries in play
- Host boundary. The attacker needs a foothold on the machine first; the flaw turns a small foothold into a bigger one.
Questions to answer about your own systems
- Where does mcu-tools mcuboot run in your systems, and at which version?
- Which of those devices sit where outsiders can touch them?
- What can it reach once compromised: which data stores, secrets and services?
Sources
- CVE records and CVSS scores from the NVD CVE API. This product uses the NVD API but is not endorsed or certified by the NVD.
- Exploitation status from CISA’s Known Exploited Vulnerabilities catalog.
- Exploit likelihood from FIRST’s Exploit Prediction Scoring System (EPSS), refreshed daily.
- Explanations are written by Veriom from fixed templates over each record’s data, not by a person reviewing each CVE. Descriptions are quoted from the records as published.