mcu-tools MCUboot up to 2.4.x TinyCrypt crypto backend aes_ctr_tinycrypt.h bootutil_aes_ctr_drop information disclosure

Summaryinfo

A vulnerability was found in mcu-tools MCUboot up to 2.4.x. It has been classified as problematic. Impacted is the function bootutil_aes_ctr_drop of the file boot/bootutil/include/bootutil/crypto/aes_ctr_tinycrypt.h of the component TinyCrypt crypto backend. The manipulation leads to information disclosure. This vulnerability is referenced as CVE-2026-128091. The attack can only be performed from a local environment. No exploit is available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability was found in mcu-tools MCUboot up to 2.4.x and classified as problematic. This issue affects the function bootutil_aes_ctr_drop of the file boot/bootutil/include/bootutil/crypto/aes_ctr_tinycrypt.h of the component TinyCrypt crypto backend. The manipulation with an unknown input leads to a information disclosure vulnerability. Using CWE to declare the problem leads to CWE-200. The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. Impacted is confidentiality. The summary by CVE is:

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().

It is possible to read the advisory at github.com. The identification of this vulnerability is CVE-2026-128091 since 11/12/2026. The exploitation is known to be easy. Attacking locally is a requirement. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1592 according to MITRE ATT&CK.

Upgrading to version 2.5.0 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Vendor

• mcu-tools

Name

• MCUboot

Version

• 2.0
• 2.1
• 2.2
• 2.3
• 2.4

Website

• Product: https://github.com/mcu-tools/mcuboot/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion