ESP-IDF vulnerabilities by version: what the NVD counts and what it misses

How many CVEs does the NVD list for my ESP-IDF version?

Counted are CVEs whose NVD configuration lists the version as vulnerable, queried on 23 October 2026 through the NVD API, rejected entries excluded. The NVD lists ESP-IDF under exactly one name, cpe:2.3:a:espressif:esp-idf. The number is a lower bound; the next section explains why.

The CVSS score is the NVD's, otherwise the vendor's. They can differ widely: the NVD scores CVE-2025-66409 (AVRCP) 9.1, Espressif 2.7.

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

10

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

2

Why is the NVD count for ESP-IDF too low?

The security advisories in the ESP-IDF GitHub repository name, per line, the last affected and the first fixed version, for example “vuln=v5.1.6 patched=v5.1.7”. The NVD configured many of these CVEs as exactly those single versions. CVE-2025-68473, for example, applies in the NVD only to 5.1.6, 5.2.6, 5.3.4, 5.4.3 and 5.5.1; earlier versions of the same lines are not counted. Whether they are affected, the NVD does not say; the advisory names only the last affected version per line.

On top of that come CVEs without an NVD configuration (status “Deferred” or “Awaiting Analysis”). Some descriptions spell the product “ESF-IDF”; a keyword search for “ESP-IDF” does not find them.

For an ESP-IDF version this means: the NVD count is a lower bound. Read the project's advisories and check every CVE against your line, not only against the exact version.

Which ESP-IDF CVEs count first, and with which switch?

Nine CVEs from the NVD lists for 5.2.6 and 5.5.4, by CVSS according to the NVD. Most depend on a feature that Kconfig puts in the build or leaves out. The fixes are stated in the CVE description or in Espressif's advisory.

Which CVEs do the libraries inside ESP-IDF bring?

ESP-IDF ships mbedTLS, lwIP, FreeRTOS and NimBLE as components of its own, partly as Espressif forks. The NVD lists their CVEs under each library. Read from the source tree of each tag: mbedTLS from include/mbedtls/build_info.h, lwIP from src/include/lwip/init.h, FreeRTOS from tskKERNEL_VERSION_NUMBER in task.h, NimBLE from sbom.yml in Espressif's fork. In brackets the CVEs according to the NVD for that version of the library.

$ curl -s https://raw.githubusercontent.com/espressif/mbedtls/$(gh api  \
"repos/espressif/esp-idf/contents/components/mbedtls/mbedtls?ref=v5.4.4"  \
-q .sha)/include/mbedtls/build_info.h  \
| grep "define MBEDTLS_VERSION_STRING "

#define MBEDTLS_VERSION_STRING         "3.6.5"

What do the library numbers mean?

mbedTLS is the largest item. ESP-IDF 5.4.4, the newest release of the 5.4 line, ships mbedTLS 3.6.5. The NVD lists eleven CVEs for it, ten of them fixed in mbedTLS 3.6.6. Espressif's fork in 5.4.4 ends with commits from November 2025; the eleven CVEs are from April 2026. The other maintained lines ship mbedTLS 3.6.7 or 4.1.

The five FreeRTOS CVEs for 10.5.1 concern, according to their descriptions, ports with MPU or TrustZone. lwIP has no NVD entry for 2.1.3 and 2.2.0; the flaw in ESP-IDF's DHCP server (CVE-2026-45160) is listed under ESP-IDF. For NimBLE 1.5.0 and 1.6.0 the NVD lists 15 CVEs each under apache:nimble.

Which ESP-IDF lines does Espressif maintain?

According to SUPPORT_POLICY.md every major and minor release is supported for 30 months: 12 months of service, then 18 months of maintenance with “only bugfixes for high severity issues or security issues”. End-of-life lines receive no further fixes.

Where is the ESP-IDF version in the image?

Every ESP-IDF application carries a descriptor esp_app_desc_t (magic 0xABCD5432) at the start of its first data segment, at offset 0x20 of the app image. The field idf_ver with the ESP-IDF version sits 112 bytes further, at offset 0x90. The build sets it from version.txt or git describe.

A public release of a widely used open-source project, WLED 16.0.1 of 7 July 2026 for the ESP32, names ESP-IDF 4.4.8 there. The 4.4 line has been end of life since 31 July 2024.

$ python -m esptool image-info WLED_16.0.1_ESP32.bin | grep ESP-IDF

ESP-IDF: 4.4.8.240628

$ xxd -s 0x90 -l 16 WLED_16.0.1_ESP32.bin

00000090: 342e 342e 382e 3234 3036 3238 0000 0000  4.4.8.240628....

How do I check this by hand?

1. 1

   Read the version: esptool image-info on the app image, or the 32 bytes at offset 0x90. In the source tree ESP_IDF_VERSION_MAJOR, _MINOR and _PATCH are in esp_idf_version.h.

2. 2

   Map the line: 5.3, 5.4, 5.5, 6.0 and 6.1 are maintained.

3. 3

   Query the NVD with cpe:2.3:a:espressif:esp-idf:<version> and read the advisories in the GitHub repository against the line, not only against the exact version.

4. 4

   Check the bundled libraries one by one: mbedTLS, lwIP, FreeRTOS, NimBLE or Bluedroid, wpa_supplicant. Their versions are in the component headers.

5. 5

   Check the switches in sdkconfig: CONFIG_BT_A2DP_ENABLE, CONFIG_HTTPD_WS_SUPPORT, CONFIG_ESP_PROTOCOMM_SUPPORT_SECURITY_VERSION_2, CONFIG_LWIP_DHCPS, CONFIG_SECURE_ENABLE_TEE. Switch off what you do not need; the code is then missing from the image.

6. 6

   Read Espressif's hardware advisories (secure boot, flash encryption); they often carry no CVE number and appear in no NVD query.

7. 7

   Check the CISA KEV catalogue for actively exploited vulnerabilities.

Can this run automatically?

LegacyMind reads the ESP-IDF version and the built-in libraries with their versions from the ESP32 image and matches each against the vulnerability sources, with the place in the image where it was read. Where the image proves no version, the field stays empty.