CVE-2026-128091mcu-tools mcuboot vulnerability
CVE-2026-128091 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
When MCUboot is built with the TinyCrypt crypto backend (MCUBOOT_USE_TINYCRYPT), bootutil_aes_ctr_drop() in boot/bootutil/include/bootutil/crypto/aes_ctr_tinycrypt.h was an empty stub. The AES-CTR context for this backend is the fully expanded AES-128 key schedule (struct tc_aes_key_sched_struct). Generic code relies on this hook to release and clear key state, so with TinyCrypt nothing was cleared. The mbedTLS and PSA backends do free or destroy their key state here.
As a result, boot_state_clear(), which boot_go() calls before handing off to the application, left the image's AES content-encryption key schedule in the static boot_data state. This is the case after an encrypted upgrade in single-image builds, where boot_enc_zeroize() is not called. boot_decrypt_key() likewise left the ECIES-derived key-encryption key schedule on the stack. The affected build uses MCUBOOT_ENC_IMAGES with TinyCrypt, which is the default ECDSA and Ed25519 backend in the Zephyr port.
The first AES-128 round key equals the cipher key, so anyone who can read the leftover bootloader RAM after boot can recover the image content key and decrypt that encrypted image. That includes a physical attacker with debug or RAM access, or code later running on the device. This weakens image-encryption key confidentiality (and so the confidentiality of the encrypted image's plaintext). The device's long-term private decryption key is not exposed, and image authenticity is not affected. The fix wipes the context with bootutil_wipe_memory().
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.