CVE-2025-49600: Mbed TLS LMS Auth Bypass Vulnerability

CVE-2025-49600 Overview

CVE-2025-49600 is a signature verification flaw in Mbed TLS versions 3.3.0 through 3.6.3. The function mbedtls_lms_verify fails to check return values from internal Merkle tree helpers create_merkle_leaf_value and create_merkle_internal_value. When these helpers fail, the output buffer Tc_candidate_root_node remains uninitialized, leaving verification results unpredictable. An attacker who can induce a fault in a hardware hash accelerator can bypass Leighton-Micali Signature (LMS) verification and force acceptance of a forged signature. The issue is tracked under CWE-325: Missing Cryptographic Step.

Critical Impact
Successful fault injection against the hash accelerator allows LMS signature forgery, undermining code-signing and firmware authenticity guarantees on affected embedded devices.

Affected Products

Trusted Firmware Mbed TLS 3.3.0 through 3.6.3
Embedded systems using Mbed TLS with hardware-accelerated SHA-256
Devices relying on Mbed TLS LMS post-quantum signature verification

Discovery Timeline

2025-07-04 - CVE-2025-49600 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-49600

Vulnerability Analysis

The defect resides in the LMS verification path of Mbed TLS. mbedtls_lms_verify invokes create_merkle_leaf_value and create_merkle_internal_value to reconstruct a candidate Merkle root from the signature and public key. Both helpers return an integer status indicating success or failure, but the caller discards those return values. If either helper fails partway through execution, it leaves the destination buffer Tc_candidate_root_node uninitialized on the stack. The subsequent comparison against the expected root then operates on stale or attacker-influenceable stack data, producing an undefined verification outcome that can resolve as success.

Root Cause

The root cause is unchecked return values around a cryptographic primitive, which maps directly to CWE-325. In a pure software build, the SHA-256 implementation cannot fail, so the bug is latent. On platforms that offload hashing to a hardware accelerator, transient hardware faults propagate into failed helper calls that verification logic never observes.

Attack Vector

Exploitation requires physical access to the target device and the ability to induce controlled faults, typically through voltage glitching, clock glitching, or electromagnetic injection, against the hash accelerator. The attacker submits a crafted LMS signature and times the fault to occur during Merkle root reconstruction. When the accelerator faults, the uninitialized Tc_candidate_root_node buffer may coincidentally match the expected root, causing mbedtls_lms_verify to return success on an invalid signature. This enables installation of unsigned firmware, bypass of secure boot chains, or acceptance of forged update manifests. Full technical detail is available in the MbedTLS Security Advisory 2025-06-3.

Detection Methods for CVE-2025-49600

Indicators of Compromise

Unexpected acceptance of firmware or update payloads whose LMS signatures fail verification on a known-good reference device
Anomalous power, clock, or electromagnetic patterns near the device during update or boot operations, consistent with fault injection tooling
Devices booting firmware images not present in the authorized build manifest

Detection Strategies

Inventory embedded devices and firmware to identify components linking against Mbed TLS versions 3.3.0 through 3.6.3 with LMS enabled
Enable and monitor hardware accelerator fault or error status registers, if exposed by the platform, and treat any fault as a verification failure
Compare mbedtls_lms_verify return values across redundant verification paths where feasible, and log discrepancies

Monitoring Recommendations

Collect and forward secure boot and update verification logs from fleets of embedded devices to a centralized analytics pipeline
Alert on repeated boot cycles, verification retries, or firmware rollbacks that may indicate glitching attempts
Track physical tamper sensor events alongside cryptographic verification outcomes to correlate fault injection activity

How to Mitigate CVE-2025-49600

Immediate Actions Required

Upgrade Mbed TLS to version 3.6.4 or later on all affected devices and rebuild dependent firmware
Where hardware allows, enable tamper detection and voltage or clock glitch countermeasures on the SoC or secure element
Audit any product using LMS verification with a hardware SHA accelerator and prioritize patch deployment for units in physically exposed environments

Patch Information

Trusted Firmware fixed the issue in Mbed TLS 3.6.4 by checking the return values of create_merkle_leaf_value and create_merkle_internal_value inside mbedtls_lms_verify and failing verification when either helper reports an error. Details are documented in the MbedTLS Security Advisory 2025-06-3.

Workarounds

Switch LMS verification to the software SHA-256 implementation, which cannot fail and therefore is not exploitable through accelerator faults
Restrict physical access to devices performing LMS verification, including during manufacturing, provisioning, and field service
Perform LMS verification twice with independent hashing paths and require both results to agree before trusting a signature

bash

# Configuration example: disable hardware SHA acceleration for LMS
# in the Mbed TLS build configuration (mbedtls_config.h)
#undef  MBEDTLS_SHA256_ALT
#undef  MBEDTLS_SHA256_PROCESS_ALT
#define MBEDTLS_SHA256_C
#define MBEDTLS_LMS_C