Missing Cryptographic Step Affecting mbedtls package, versions [3.4.1,3.6.4)
Threat Intelligence
Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CONAN-MBEDTLS-10768242
- published17 Jul 2025
- disclosed4 Jul 2025
- creditLinh Le, Ngan Nguyen
Introduced: 4 Jul 2025
NewCVE-2025-49600 (opens in a new tab)How to fix?
Upgrade mbedtls to version 3.6.4 or higher.
Overview
Affected versions of this package are vulnerable to Missing Cryptographic Step in the mbedtls_lms_verify process when internal errors from the create_merkle_leaf_value and create_merkle_internal_value functions are not checked. An attacker can cause the acceptance of invalid signatures by inducing faults in a hardware hash accelerator, leading to the reuse of uninitialized stack data and bypassing signature verification.
Note:
This is only exploitable if hardware-accelerated hashing is used and the attacker can perform fault injection against the accelerator.
Workaround
For the users that are unable to upgrade to the fixed version it is recommended to not use a hardware hash accelerator that can fail without halting the system. If a hardware accelerator is required, choose accelerators that are tamper-proof or include fault-injection detection.
Alternatively use the built-in software implementation of SHA-256 if possible.
PoC
Under the following plausible scenario, an adversary could bypass signature verification:
mbedtls_lms_verify()is first called to verify a valid message and signature. A valid value for Tc_candidate_root_node is stored on the stack. The adversary then injects a fault into the hash accelerator, causing all subsequent hashing operations to fail.mbedtls_lms_verify()is called again with the same key and signature but a different message, without invoking other functions that would overwrite the stack. Because the Tc_candidate_root_node is not updated due to the failure of the hashing operations, the previous valid value remains on the stack, causing the verification to incorrectly succeed.