CVE-2025-49600 is a medium-severity vulnerability affecting MbedTLS versions from 3.3.0 up to but not including 3.6.4. The issue lies in the mbedtls_lms_verify function, which is responsible for verifying LMS (Leighton-Micali Signature) signatures. Specifically, the vulnerability arises because the function fails to check the return values of internal Merkle tree computation functions, create_merkle_leaf_value and create_merkle_internal_value. These functions return status codes indicating success or failure. If a failure occurs, particularly during hash computations, the output buffer used in signature verification may remain uninitialized. This leads to unpredictable verification results, potentially allowing invalid signatures to be accepted. The vulnerability is exploitable only in scenarios where hardware-accelerated hashing is used because the software SHA-256 implementation does not fail in this manner. An attacker capable of inducing faults in the hardware hash accelerator (e.g., via fault injection techniques) can cause the hash computation to fail silently, bypass the signature verification process, and forge LMS signatures by reusing stale stack data. This flaw compromises the integrity of signature verification, enabling attackers to impersonate legitimate signers or inject malicious data that appears valid. The vulnerability does not impact confidentiality or availability directly but poses a significant risk to data integrity and trustworthiness of cryptographic signatures. The CVSS 3.1 base score is 4.9 (medium), reflecting the complexity of exploitation (requires physical or close access to induce hardware faults), no privileges required, and no user interaction needed. No known exploits are reported in the wild as of the publication date. No patches were linked at the time of reporting, indicating that affected users should monitor for updates and apply them promptly once available.

For European organizations, this vulnerability poses a risk primarily to systems relying on MbedTLS for cryptographic signature verification, especially those using hardware-accelerated hashing modules. Industries such as telecommunications, IoT device manufacturers, embedded systems in automotive or industrial control, and critical infrastructure sectors that employ LMS signatures for firmware or software authenticity verification could be impacted. The ability to forge signatures undermines the integrity of software updates, secure communications, and authentication mechanisms, potentially leading to unauthorized code execution or data manipulation. Although exploitation requires sophisticated fault injection attacks, the threat is more pronounced in environments where hardware security modules or accelerators are deployed without robust physical security controls. European organizations with supply chains or products incorporating vulnerable MbedTLS versions may face risks of counterfeit firmware or malicious updates, which can disrupt operations or compromise safety-critical systems. The medium severity suggests a moderate risk level, but the potential impact on trust and compliance with EU cybersecurity regulations (e.g., NIS2 Directive) could be significant if exploited.

1. Immediate mitigation involves auditing all systems and devices using MbedTLS versions 3.3.0 up to but not including 3.6.4, particularly those employing hardware-accelerated hashing. 2. Apply vendor patches or updates as soon as they become available to ensure the return values of internal Merkle tree functions are properly checked and handled. 3. Where possible, disable hardware-accelerated hashing temporarily or configure systems to use the software SHA-256 implementation, which is not vulnerable to this fault injection scenario. 4. Implement physical security measures to prevent fault injection attacks, such as shielding hardware components, monitoring for abnormal hardware behavior, and restricting physical access to critical devices. 5. Conduct thorough testing and validation of cryptographic verification processes after updates or configuration changes to confirm signature verification integrity. 6. Incorporate runtime integrity checks and anomaly detection mechanisms to identify suspicious signature verification outcomes or repeated verification failures. 7. Engage with hardware vendors to understand the fault injection resistance of their accelerators and apply recommended firmware or hardware mitigations. 8. Maintain an inventory of affected devices and ensure supply chain partners are informed to coordinate remediation efforts.