In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_verify may accept invalid signatures if hash computation fails and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario. Specifically, unchecked return values in mbedtls_lms_verify allow an attacker (who can induce a hardware hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in acceptance of an invalid signature. In mbedtls_lms_verify, the return values of the internal Merkle tree functions create_merkle_leaf_value and create_merkle_internal_value are not checked. These functions return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer (Tc_candidate_root_node) may remain uninitialized, and the result of the signature verification is unpredictable. When the software implementation of SHA-256 is used, these functions will not fail. However, with hardware-accelerated hashing, an attacker could use fault injection against the accelerator to bypass verification.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_verify may accept invalid signatures if hash computation fails     and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario.
    Specifically, unchecked return values in mbedtls_lms_verify allow an attacker (who can induce a hardware     hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in     acceptance of an invalid signature. In mbedtls_lms_verify, the return values of the internal Merkle tree     functions create_merkle_leaf_value and create_merkle_internal_value are not checked. These functions     return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer     (Tc_candidate_root_node) may remain uninitialized, and the result of the signature verification is     unpredictable. When the software implementation of SHA-256 is used, these functions will not fail.
    However, with hardware-accelerated hashing, an attacker could use fault injection against the accelerator     to bypass verification. (CVE-2025-49600)

Note that Nessus relies on the presence of the package as reported by the vendor.

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - Mbed TLS before 3.6.4 allows a use-after-free in certain situations of applications that are developed in
    accordance with the documentation. The function mbedtls_x509_string_to_names() takes a head argument that
    is documented as an output argument. The documentation does not suggest that the function will free that
    pointer; however, the function does call mbedtls_asn1_free_named_data_list() on that argument, which
    performs a deep free(). As a result, application code that uses this function (relying only on documented
    behavior) is likely to still hold pointers to the memory blocks that were freed, resulting in a high risk
    of use-after-free or double-free. In particular, the two sample programs x509/cert_write and x509/cert_req
    are affected (use-after-free if the san string contains more than one DN). (CVE-2025-47917)

  - Mbed TLS before 3.6.4 has a NULL pointer dereference because mbedtls_asn1_store_named_data can trigger
    conflicting data with val.p of NULL but val.len greater than zero. (CVE-2025-48965)

  - In Mbed TLS 3.6.1 through 3.6.3 before 3.6.4, a timing discrepancy in block cipher padding removal allows
    an attacker to recover the plaintext when PKCS#7 padding mode is used. (CVE-2025-49087)

  - In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_verify may accept invalid signatures if hash computation fails
    and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario.
    Specifically, unchecked return values in mbedtls_lms_verify allow an attacker (who can induce a hardware
    hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in
    acceptance of an invalid signature. In mbedtls_lms_verify, the return values of the internal Merkle tree
    functions create_merkle_leaf_value and create_merkle_internal_value are not checked. These functions
    return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer
    (Tc_candidate_root_node) may remain uninitialized, and the result of the signature verification is
    unpredictable. When the software implementation of SHA-256 is used, these functions will not fail.
    However, with hardware-accelerated hashing, an attacker could use fault injection against the accelerator
    to bypass verification. (CVE-2025-49600)

ID	Name	Product	Family	Type	Severity
244273	Linux Distros Unpatched Vulnerability : CVE-2025-49600	Nessus	Misc.	Local	medium
428615	Alpine: multiple mbedtls packages: security update to 3.6.4-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	Local	critical
428615	Alpine: multiple mbedtls packages: security update to 3.6.4-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	Local	critical

Detections

Analytics

CVE-2025-49600

medium

Tenable Plugins

medium

critical

critical