---
id: "CVE-2026-127928"
page: "https://infrastack.ai/live/CVE-2026-127928"
kind: "vulnerability"
aliases: ["CVE-2026-127928"]
title: "MCUboot: encryption keys left in stack memory after serial recovery"
severity: "low"
cvss: 2.0
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["embedded", "firmware", "mcuboot", "runtime", "zephyr"]
not_affected_if: ["debug-locked", "encrypted-images-disabled", "serial-recovery-disabled"]
published_at: "2026-11-13T02:18:56+00:00"
first_seen_at: "2026-11-13T02:41:36+00:00"
updated_at: "2026-11-13T02:43:11+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-127928", "first_seen_at": "2026-11-13T02:41:36+00:00"}]
exploit_sources: []
---

# MCUboot: encryption keys left in stack memory after serial recovery

Link for people: https://infrastack.ai/live/CVE-2026-127928 (this .md is for agents)

MCUboot's serial-recovery code for encrypted images leaves the plaintext AES image key and expanded key context in stack memory after returning. An attacker who can read device RAM through a debug port or retained RAM can recover the key and decrypt the firmware image it protects.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the build enables `MCUBOOT_ENC_IMAGES` (or Zephyr `CONFIG_BOOT_ENCRYPT_IMAGE`) together with serial recovery.
- Check whether the bootloader source contains `boot/boot_serial/src/boot_serial_encryption.c`.

## Timeline

- 2026-11-13T02:41:36+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-127928

## Documents

- [advisory] Vendor advisory: github.com https://github.com/mcu-tools/mcuboot/security/advisories/GHSA-hqmg-jwp9-8cf8
- [fix] Patch: github.com https://github.com/mcu-tools/mcuboot/commit/411949f830724617fbc08b9b32f0a45ba0c80baf

## From the sources

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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_