ESP-IDF-Schwachstellen nach Version: was NVD zählt und was fehlt

Wie viele CVEs führt die NVD für meine ESP-IDF-Version?

Gezählt sind CVEs, deren NVD-Konfiguration die Version als verwundbar führt, abgefragt am 23.10.2026 über die NVD-API, ohne zurückgezogene Einträge. NVD führt ESP-IDF unter genau einem Namen, cpe:2.3:a:espressif:esp-idf. Die Zahl ist eine Untergrenze, warum, steht im nächsten Abschnitt.

Die CVSS-Wertung ist die der NVD, sonst die des Herstellers. Beide weichen teils stark voneinander ab: CVE-2025-66409 (AVRCP) wertet NVD mit 9,1, Espressif mit 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

Warum ist die NVD-Zahl für ESP-IDF zu niedrig?

Die Security Advisories im GitHub-Repository von ESP-IDF nennen je Linie die letzte betroffene und die erste korrigierte Version, etwa „vuln=v5.1.6 patched=v5.1.7“. NVD hat viele dieser CVEs als genau diese einzelnen Versionen konfiguriert. CVE-2025-68473 etwa gilt in der NVD nur für 5.1.6, 5.2.6, 5.3.4, 5.4.3 und 5.5.1; frühere Versionen derselben Linien zählen nicht mit. Ob sie betroffen sind, sagt die NVD damit nicht; das Advisory nennt je Linie nur die letzte betroffene Version.

Dazu kommen CVEs ohne NVD-Konfiguration (Status „Deferred“ oder „Awaiting Analysis“). Einige Beschreibungen schreiben das Produkt „ESF-IDF“; eine Stichwortsuche nach „ESP-IDF“ findet sie nicht.

Für eine ESP-IDF-Version heißt das: die NVD-Zahl ist eine Untergrenze. Lesen Sie die Advisories des Projekts und prüfen Sie jede CVE gegen Ihre Linie, nicht nur gegen die genaue Version.

Welche ESP-IDF-CVEs zählen zuerst, und mit welchem Schalter?

Neun CVEs aus den NVD-Listen für 5.2.6 und 5.5.4, nach CVSS laut NVD. Die meisten hängen an einer Funktion, die per Kconfig im Build ist oder nicht. Die Korrekturen stehen in der Beschreibung der CVE oder im Advisory von Espressif.

Welche CVEs bringen die Bibliotheken in ESP-IDF mit?

ESP-IDF bringt mbedTLS, lwIP, FreeRTOS und NimBLE als eigene Komponenten mit, teils als Fork von Espressif. NVD führt deren CVEs unter der jeweiligen Bibliothek. Gelesen aus dem Quellbaum je Tag: mbedTLS aus include/mbedtls/build_info.h, lwIP aus src/include/lwip/init.h, FreeRTOS aus tskKERNEL_VERSION_NUMBER in task.h, NimBLE aus sbom.yml im Fork von Espressif. In Klammern die CVEs laut NVD für diese Version der Bibliothek.

$ 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"

Was bedeuten die Bibliothekszahlen?

mbedTLS ist der größte Posten. ESP-IDF 5.4.4, das neueste Release der Linie 5.4, bringt mbedTLS 3.6.5 mit. Dafür führt NVD elf CVEs, zehn davon korrigiert in mbedTLS 3.6.6. Der Fork von Espressif in 5.4.4 endet mit Commits vom November 2025; die elf CVEs sind vom April 2026. Die anderen gepflegten Linien bringen mbedTLS 3.6.7 oder 4.1 mit.

Die fünf FreeRTOS-CVEs für 10.5.1 betreffen laut ihrer Beschreibung Ports mit MPU oder TrustZone. lwIP hat für 2.1.3 und 2.2.0 keinen Eintrag in der NVD; die Lücke im DHCP-Server von ESP-IDF (CVE-2026-45160) steht unter ESP-IDF. Für NimBLE 1.5.0 und 1.6.0 führt NVD je 15 CVEs unter apache:nimble.

Welche ESP-IDF-Linien pflegt Espressif?

Laut SUPPORT_POLICY.md wird jede Haupt- und Nebenversion 30 Monate unterstützt: 12 Monate Service, danach 18 Monate Maintenance mit „only bugfixes for high severity issues or security issues“. Abgekündigte Linien bekommen keine Korrekturen mehr.

Wo steht die ESP-IDF-Version im Image?

Jede ESP-IDF-Anwendung trägt eine Beschreibung esp_app_desc_t (Magic 0xABCD5432) am Anfang des ersten Datensegments, im App-Image an Offset 0x20. Das Feld idf_ver mit der ESP-IDF-Version liegt 112 Byte dahinter, also an Offset 0x90. Gesetzt wird es beim Bauen aus version.txt oder git describe.

Ein öffentliches Release eines verbreiteten Open-Source-Projekts, WLED 16.0.1 vom 07.07.2026 für den ESP32, nennt dort ESP-IDF 4.4.8. Die Linie 4.4 ist seit 31.07.2024 abgekündigt.

$ 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....

Wie prüfe ich das von Hand?

1. 1

   Version lesen: esptool image-info auf das App-Image oder die 32 Byte an Offset 0x90. Im Quellbaum stehen ESP_IDF_VERSION_MAJOR, _MINOR und _PATCH in esp_idf_version.h.

2. 2

   Linie zuordnen: gepflegt sind 5.3, 5.4, 5.5, 6.0 und 6.1.

3. 3

   NVD abfragen mit cpe:2.3:a:espressif:esp-idf:<Version> und die Advisories im GitHub-Repository gegen die Linie lesen, nicht nur gegen die genaue Version.

4. 4

   Die mitgebauten Bibliotheken einzeln prüfen: mbedTLS, lwIP, FreeRTOS, NimBLE oder Bluedroid, wpa_supplicant. Ihre Versionen stehen in den Headern der Komponenten.

5. 5

   Die Schalter in sdkconfig prüfen: CONFIG_BT_A2DP_ENABLE, CONFIG_HTTPD_WS_SUPPORT, CONFIG_ESP_PROTOCOMM_SUPPORT_SECURITY_VERSION_2, CONFIG_LWIP_DHCPS, CONFIG_SECURE_ENABLE_TEE. Was Sie nicht brauchen, schalten Sie ab; der Code fehlt dann im Image.

6. 6

   Hardware-Advisories von Espressif (Secure Boot, Flash-Verschlüsselung) lesen; sie tragen oft keine CVE-Nummer und erscheinen in keiner NVD-Abfrage.

7. 7

   Den KEV-Katalog der CISA auf aktiv ausgenutzte Lücken prüfen.

Geht das auch automatisch?

LegacyMind liest aus dem ESP32-Image die ESP-IDF-Version und die eingebauten Bibliotheken mit ihren Versionen und gleicht jede gegen die Schwachstellenquellen ab, mit der Fundstelle im Image. Belegt das Image keine Version, bleibt das Feld leer.