Search
Search Results (87 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-25834 | 2 Mbed-tls, Trustedfirmware | 2 Mbedtls, Mbed Tls | 2026-06-05 | 6.5 Medium |
| Mbed TLS v3.3.0 up to 3.6.5 and 4.0.0 allows Algorithm Downgrade. | ||||
| CVE-2026-34873 | 2 Mbed-tls, Trustedfirmware | 2 Mbedtls, Mbed Tls | 2026-06-05 | 9.1 Critical |
| An issue was discovered in Mbed TLS 3.5.0 through 4.0.0. Client impersonation can occur while resuming a TLS 1.3 session. | ||||
| CVE-2026-34874 | 2 Mbed-tls, Trustedfirmware | 2 Mbedtls, Mbed Tls | 2026-06-05 | 7.5 High |
| An issue was discovered in Mbed TLS through 3.6.5 and 4.x through 4.0.0. There is a NULL pointer dereference in distinguished name parsing that allows an attacker to write to address 0. | ||||
| CVE-2026-34876 | 2 Mbed-tls, Trustedfirmware | 2 Mbedtls, Mbed Tls | 2026-06-05 | 7.5 High |
| An issue was discovered in Mbed TLS 3.x before 3.6.6. An out-of-bounds read vulnerability in mbedtls_ccm_finish() in library/ccm.c allows attackers to obtain adjacent CCM context data via invocation of the multipart CCM API with an oversized tag_len parameter. This is caused by missing validation of the tag_len parameter against the size of the internal 16-byte authentication buffer. The issue affects the public multipart CCM API in Mbed TLS 3.x, where mbedtls_ccm_finish() can be invoked directly by applications. In Mbed TLS 4.x versions prior to the fix, the same missing validation exists in the internal implementation; however, the function is not exposed as part of the public API. Exploitation requires application-level invocation of the multipart CCM API. | ||||
| CVE-2026-34877 | 3 Arm, Mbed, Trustedfirmware | 3 Mbed Tls, Mbedtls, Mbed Tls | 2026-06-05 | 9.8 Critical |
| An issue was discovered in Mbed TLS versions from 2.19.0 up to 3.6.5, Mbed TLS 4.0.0. Insufficient protection of serialized SSL context or session structures allows an attacker who can modify the serialized structures to induce memory corruption, leading to arbitrary code execution. This is caused by Incorrect Use of Privileged APIs. | ||||
| CVE-2025-53022 | 1 Trustedfirmware | 1 Trusted Firmware-m | 2026-04-15 | 8.6 High |
| TrustedFirmware-M (aka Trusted Firmware for M profile Arm CPUs) before 2.1.3 and 2.2.x before 2.2.1 lacks length validation during a firmware upgrade. While processing a new image, the Firmware Upgrade (FWU) module does not validate the length field of the Type-Length-Value (TLV) structure for dependent components against the maximum allowed size. If the length specified in the TLV exceeds the size of the buffer allocated on the stack, the FWU module will overwrite the buffer (and potentially other stack data) with the TLV's value content. An attacker could exploit this by crafting a malicious TLV entry in the unprotected section of the MCUBoot upgrade image. By setting the length field to exceed the expected structure size, the attacker can manipulate the stack memory of the system during the upgrade process. | ||||
| CVE-2024-45746 | 1 Trustedfirmware | 1 Trusted Firmware-m | 2026-04-15 | 9.8 Critical |
| An issue was discovered in Trusted Firmware-M through 2.1.0. User provided (and controlled) mailbox messages contain a pointer to a list of input arguments (in_vec) and output arguments (out_vec). These list pointers are never validated. Each argument list contains a buffer pointer and a buffer length field. After a PSA call, the length of the output arguments behind the unchecked pointer is updated in mailbox_direct_reply, regardless of the call result. This allows an attacker to write anywhere in the secure firmware, which can be used to take over the control flow, leading to remote code execution (RCE). | ||||