mbedTLS vulnerabilities by version: the CVE list per release line

How many CVEs does the NVD list for my mbedTLS version?

Counted are CVEs whose NVD configuration lists the version as vulnerable. Queried on 23 October 2026 through the NVD API, with every CPE name under which the NVD lists mbedTLS, rejected entries excluded. The CVSS score is the NVD's, otherwise the secondary score in the NVD record, for most recent mbedTLS CVEs the one from CISA-ADP. In brackets: which package ships this version.

The count is a version range. Whether a vulnerability can be exploited in the device depends on whether the affected function is built and reachable.

Which mbedTLS version do STM32Cube, the NXP SDK, ESP-IDF and Zephyr ship?

Read from version.h or build_info.h at the published tags, as of 23 October 2026. Espressif, Zephyr and NXP maintain forks of their own. The header names the version the copy is based on.

The STM32 packages for F4, F7 and H7 ship 2.16.2 from 2019. The line has had no fixes since 2.16.12. Two vulnerabilities of July 2026 affect, according to the project, every version up to 3.6.6, so 2.16 and 2.28 as well: CVE-2026-49300 and CVE-2026-50580. There is no fix for these lines.

Which mbedTLS vulnerabilities count first?

A selection by CVSS and reach. The score is the NVD's, otherwise CISA-ADP's. CVE-2026-49300 and CVE-2026-50580 are only reserved at CVE.org and absent from the NVD; the project rates both HIGH. For CVE-2026-34877 the ratings diverge: the project says LOW, CISA-ADP 9.8.

Why are new mbedTLS CVEs missing from the NVD?

The release notes of 3.6.7 link 19 security advisories. They name 15 CVE numbers and a sixteenth with a typo (“CVE-ID-50580”, reserved at CVE.org as CVE-2026-50580). On 23 October 2026, 14 of the 15 are only reserved at CVE.org and absent from the NVD. The fifteenth, CVE-2026-25832, is in the NVD without a CPE configuration, status “Awaiting Analysis”. None of the 15 is therefore counted for any version.

If you run 3.6.6, 4.1.0 or older, read the project's security advisories as well. They name the affected versions for each vulnerability.

$ for id in CVE-2026-25832 CVE-2026-35336 CVE-2026-49300 CVE-2026-50579  \
CVE-2026-50581 CVE-2026-50583 CVE-2026-50584 CVE-2026-50585  \
CVE-2026-50586 CVE-2026-50587 CVE-2026-50588 CVE-2026-50640  \
CVE-2026-50713 CVE-2026-54435 CVE-2026-54441;  \
do curl -s "https://cveawg.mitre.org/api/cve-id/$id" | jq -r .state;  \
done | sort | uniq -c

1PUBLISHED14RESERVED

Which mbedTLS lines still get fixes?

According to BRANCHES.md, the LTS branches receive only bug fixes and security fixes; new features go into the development branch for the next 4.x version. The project writes: “Users are urged to always use the latest version of a maintained branch.”

From 4.0 the cryptography lives in a project of its own, TF-PSA-Crypto, with its own version number. Mbed TLS 4.0.0 includes TF-PSA-Crypto 1.0.0. The NVD's CVE configurations list it under trustedfirmware:tf-psa-crypto and under arm:tf-psa-crypto; query both. For TF-PSA-Crypto 1.0.0 the NVD lists five CVEs, two of them 9.0 or higher, for 1.1.0 to 1.2.0 none.

Under which CPE name is mbedTLS in the NVD?

The NVD CPE dictionary lists mbedTLS today as cpe:2.3:a:trustedfirmware:mbed_tls. The older name cpe:2.3:a:arm:mbed_tls is marked deprecated there, except for three entries. Yet that is exactly the name in the configurations of most older CVEs. A third name, cpe:2.3:a:mbed:mbedtls, is deprecated as well and returned no hit for any of the versions checked.

If you query only the current name, you find not a single CVE for 2.16.12 and six instead of eleven for 3.6.5. Query both names and merge the hits.

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:trustedfirmware:mbed_tls:2.16.12&noRejected"  \
| jq .totalResults

0

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:arm:mbed_tls:2.16.12&noRejected"  \
| jq .totalResults

23

Where is the mbedTLS version in my firmware?

In the source the version is in include/mbedtls/version.h (2.x) or include/mbedtls/build_info.h (3.x and 4.x): MBEDTLS_VERSION_STRING, MBEDTLS_VERSION_STRING_FULL and MBEDTLS_VERSION_NUMBER. Older versions spell the full form “mbed TLS”, for example “mbed TLS 2.28.0”, newer ones “Mbed TLS”, for example “Mbed TLS 3.6.7”. So search case-insensitively.

The text is in the build only when library/version.c is built in (option MBEDTLS_VERSION_C, on in the default configuration) and the firmware calls mbedtls_version_get_string() or mbedtls_version_get_string_full(). Otherwise the linker removes it: armlink discards unused sections by default, GNU ld with --gc-sections. If it is missing, function names with the prefix mbedtls_ show that the library is linked, and the version comes from the header in the project.

Folder names help only sometimes. The release archive unpacks to mbedtls-3.6.7/. STM32CubeF4 v1.28.3 puts the library under Middlewares/Third_Party/mbedTLS, with no version in the name; the header there says 2.16.2. STM32CubeU5 and H5 call the folder mbed-crypto, although it holds the full Mbed TLS 3.6.6.

$ tar xjf mbedtls-3.6.7.tar.bz2  \
&& grep -E "define MBEDTLS_VERSION_STRING(_FULL)? "  \
mbedtls-3.6.7/include/mbedtls/build_info.h

#define MBEDTLS_VERSION_STRING         "3.6.7"
#define MBEDTLS_VERSION_STRING_FULL    "Mbed TLS 3.6.7"

$ curl -s https://raw.githubusercontent.com/STMicroelectronics/STM32CubeF4/v1.28.3/Middlewares/Third_Party/mbedTLS/include/mbedtls/version.h  \
| grep -E "define MBEDTLS_VERSION_STRING(_FULL)? "

#define MBEDTLS_VERSION_STRING         "2.16.2"
#define MBEDTLS_VERSION_STRING_FULL    "mbed TLS 2.16.2"

How do I check this by hand?

1. 1

   Read the version: in the project from version.h or build_info.h, in the build with strings -a firmware.elf | grep -i "mbed tls".

2. 2

   Check that mbedTLS is linked: arm-none-eabi-nm firmware.elf | grep mbedtls_ lists the functions in the image.

3. 3

   Place the line: 3.6 and 4.1 are maintained, 2.28 and 2.16 no longer. From 4.0, read the TF-PSA-Crypto version separately (TF_PSA_CRYPTO_VERSION_STRING in tf-psa-crypto/include/tf-psa-crypto/build_info.h of the Mbed TLS 4 tree).

4. 4

   Query the NVD: virtualMatchString with cpe:2.3:a:trustedfirmware:mbed_tls:<version> and with cpe:2.3:a:arm:mbed_tls:<version>, then merge the hits.

5. 5

   Read the project's notices: security advisories and release notes name vulnerabilities that are still missing from the NVD.

6. 6

   Check the CISA KEV catalogue for actively exploited vulnerabilities.

What can I do?

1. 1

   Move to the newest version of a maintained line: 3.6.7, 4.1.1 or 4.2.0. From 2.16 or 2.28 the shortest path leads to 3.6; the API changed on the way, and the project describes the move in docs/3.0-migration-guide.md.

2. 2

   For a copy from STM32Cube, the NXP SDK, ESP-IDF or Zephyr, check the next package version. ESP-IDF v5.5.6 and NXP SDK 26.09.00 ship 3.6.7, STM32CubeU5 v1.9.0 and Zephyr v4.3.1 still 3.6.6.

3. 3

   Until the update, the configuration decides. In the default configuration of 3.6.7 these are on: MBEDTLS_SSL_PROTO_DTLS, MBEDTLS_SSL_DTLS_CONNECTION_ID, MBEDTLS_SSL_CONTEXT_SERIALIZATION, MBEDTLS_SSL_RENEGOTIATION, MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED, MBEDTLS_DHM_C, MBEDTLS_PKCS7_C. Off are MBEDTLS_SSL_EARLY_DATA and MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED. Switch off what a device does not need, in mbedtls_config.h (3.x) or config.h (2.x).

4. 4

   CVE-2026-50580 requires a very long PSK identity. CVE-2026-49300, according to the project, affects only applications that accept certificates directly from untrusted users. CVE-2026-34877 affects only applications that store TLS sessions in serialised form and load them again.

Can this run automatically?

Microcontroller builds from Keil MDK, IAR or GNU Arm. It finds the libraries built in, with their versions, for example CMSIS packs, RTX5, FreeRTOS, lwIP, mbedTLS and STM32Cube. Plus hardening (stack canary, MPU, privilege separation) and embedded keys.

Every component with an evidenced version is matched against the vulnerability sources and says where in the build it sits. If the binary evidences no version, the field stays blank.