CVE-2026-127928: AES image key left on the stack after serial-recovery encrypted-image handling in MCUboot
In MCUboot's serial-recovery encrypted-image support (boot/bootserial/src/bootserialencryption.c), decryptimageinplace() and bootimagevalidateencrypted() each keep a stack-local struct bootstatus. bootencload() 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 decryptimageinplace() returned early and skipped the totalout: cleanup, which left the expanded AES key context (encdata) on the stack as well. The error paths of bootimagevalidateencrypted() similarly skipped bootenczeroize().
The affected code is built when encrypted images (MCUBOOTENCIMAGES, Zephyr CONFIGBOOTENCRYPTIMAGE) 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.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
The affected code is built only when encrypted images are enabled together with serial recovery, including MCUboot encrypted-image support and Zephyr CONFIG_BOOT_ENCRYPT_IMAGE. The vulnerable paths run during encrypted-image upload to the primary slot over recovery, and during image-list or state queries when an encrypted image is in the secondary slot.
What additional access would an attacker need to recover a key?
The attacker must be able to read device RAM after the affected function returns. Examples given include access through a debug port or retained RAM; the issue does not itself provide RAM-read access.
How can I determine whether a device may already have exposed a key?
Check whether the device uses both encrypted images and serial recovery, then determine whether it has processed an encrypted upload to the primary slot or queried image list or state while an encrypted image was in the secondary slot. In those cases, the relevant image AES content key may remain in dead stack memory after the operation.
What configuration change avoids the affected code paths if an update cannot be applied immediately?
Avoid combining encrypted-image support with serial recovery, because that combination is required for the affected code to be built. Limiting later access to device RAM, such as through debug interfaces or retained RAM, also limits the ability to recover the residual key.