---
id: CVE-2026-128091
title: >-
  AES key schedule not cleared by the TinyCrypt AES-CTR backend in MCUboot
  bootutil
summary: >-
  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 ex…
severity: low
cvss: 2
cvssVector: 'CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N'
cvssSource: cna
cwe:
  - CWE-226
vendor: mcu-tools
product: mcuboot
affected:
  - mcuboot >= 1.3.0 < 2.5.0
published: '2026-11-13'
updated: '2026-11-13'
sourceUpdated: '2026-11-13T00:22:58.572Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-128091'
references:
  - url: >-
      https://github.com/mcu-tools/mcuboot/commit/d204aaa3ab40c0b37a52d3b4c433b437f9ad8374
    label: Fix commit
  - url: >-
      https://github.com/mcu-tools/mcuboot/security/advisories/GHSA-wx3x-935q-6rcf
    label: GHSA-wx3x-935q-6rcf
tags:
  - cve.org
ingestedAt: '2026-11-13T01:19:02.074Z'
---

## Overview

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

## Affected

- `mcuboot >= 1.3.0 < 2.5.0`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.