mbedTLS-Schwachstellen nach Version: die CVE-Liste je Release-Linie

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

Gezählt sind CVEs, deren NVD-Konfiguration die Version als verwundbar führt. Abgefragt am 23.10.2026 über die NVD-API, mit allen CPE-Namen, unter denen NVD mbedTLS führt, ohne zurückgezogene Einträge. Die CVSS-Wertung ist die der NVD, sonst die Zweitwertung im NVD-Eintrag, bei den meisten neueren mbedTLS-CVEs die von CISA-ADP. In Klammern steht, welches Paket diese Version mitliefert.

Die Zahl ist ein Versionsbereich. Ob eine Lücke im Gerät ausnutzbar ist, hängt davon ab, ob die betroffene Funktion gebaut und erreichbar ist.

Welche mbedTLS-Version liefern STM32Cube, NXP-SDK, ESP-IDF und Zephyr mit?

Gelesen aus version.h oder build_info.h an den veröffentlichten Tags, Stand 23.10.2026. Espressif, Zephyr und NXP führen eigene Forks. Der Header nennt die Version, auf der die Kopie beruht.

Die STM32-Pakete für F4, F7 und H7 liefern 2.16.2 aus dem Jahr 2019. Die Linie bekommt seit 2.16.12 keine Korrekturen mehr. Zwei Lücken vom Juli 2026 betreffen laut Projekt alle Versionen bis 3.6.6, also auch 2.16 und 2.28: CVE-2026-49300 und CVE-2026-50580. Für diese Linien gibt es keine Korrektur.

Welche mbedTLS-Lücken zählen zuerst?

Eine Auswahl nach CVSS und Reichweite. Die Wertung ist die der NVD, sonst die von CISA-ADP. CVE-2026-49300 und CVE-2026-50580 sind bei CVE.org nur reserviert und fehlen in der NVD; das Projekt stuft beide als HIGH ein. Bei CVE-2026-34877 weichen die Wertungen auseinander: das Projekt sagt LOW, CISA-ADP 9,8.

Warum fehlen neue mbedTLS-CVEs in der NVD?

Die Release Notes zu 3.6.7 verweisen auf 19 Sicherheitshinweise. Sie nennen 15 CVE-Nummern und eine sechzehnte mit Tippfehler („CVE-ID-50580“, bei CVE.org als CVE-2026-50580 reserviert). Am 23.10.2026 sind 14 der 15 bei CVE.org nur reserviert und fehlen in der NVD. Die fünfzehnte, CVE-2026-25832, steht in der NVD ohne CPE-Konfiguration, Status „Awaiting Analysis“. Keine der 15 zählt deshalb bei einer Version mit.

Wer 3.6.6, 4.1.0 oder älter einsetzt, liest deshalb zusätzlich die Security Advisories des Projekts. Sie nennen je Lücke die betroffenen Versionen.

$ 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

Welche mbedTLS-Linien bekommen noch Korrekturen?

Laut BRANCHES.md bekommen die LTS-Zweige nur noch Fehler- und Sicherheitskorrekturen; neue Funktionen entstehen im Zweig development für die nächste 4.x-Version. Das Projekt schreibt: „Users are urged to always use the latest version of a maintained branch.“

Ab 4.0 liegt die Kryptografie in einem eigenen Projekt, TF-PSA-Crypto, mit eigener Versionsnummer. Mbed TLS 4.0.0 enthält TF-PSA-Crypto 1.0.0. NVD führt sie in den CVE-Konfigurationen unter trustedfirmware:tf-psa-crypto und unter arm:tf-psa-crypto; fragen Sie beide ab. Für TF-PSA-Crypto 1.0.0 führt NVD fünf CVEs, zwei davon ab 9,0, für 1.1.0 bis 1.2.0 keine.

Unter welchem CPE-Namen steht mbedTLS in der NVD?

Das CPE-Wörterbuch der NVD führt mbedTLS heute unter cpe:2.3:a:trustedfirmware:mbed_tls. Der ältere Name cpe:2.3:a:arm:mbed_tls ist dort bis auf drei Einträge als veraltet markiert. In den Konfigurationen der meisten älteren CVEs steht aber genau dieser Name. Ein dritter Name, cpe:2.3:a:mbed:mbedtls, ist ebenfalls veraltet und lieferte für keine der geprüften Versionen einen Treffer.

Wer nur den aktuellen Namen abfragt, findet für 2.16.12 keine einzige CVE und für 3.6.5 sechs statt elf. Fragen Sie beide Namen ab und führen Sie die Treffer zusammen.

$ 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

Wo steht die mbedTLS-Version in meiner Firmware?

Im Quellcode steht die Version in include/mbedtls/version.h (2.x) oder include/mbedtls/build_info.h (3.x und 4.x): MBEDTLS_VERSION_STRING, MBEDTLS_VERSION_STRING_FULL und MBEDTLS_VERSION_NUMBER. Die volle Form lautet in älteren Versionen „mbed TLS“, etwa „mbed TLS 2.28.0“, in neueren „Mbed TLS“, etwa „Mbed TLS 3.6.7“. Suchen Sie deshalb ohne Rücksicht auf Groß- und Kleinschreibung.

Im Build steht der Text nur, wenn library/version.c mitgebaut ist (Option MBEDTLS_VERSION_C, in der Standardkonfiguration an) und die Firmware mbedtls_version_get_string() oder mbedtls_version_get_string_full() aufruft. Sonst entfernt ihn der Linker: armlink verwirft ungenutzte Sektionen standardmäßig, GNU ld mit --gc-sections. Fehlt er, zeigen die Funktionsnamen mit dem Präfix mbedtls_, dass die Bibliothek gelinkt ist, und die Version kommt aus dem Header im Projekt.

Ordnernamen helfen nur manchmal. Das Release-Archiv entpackt nach mbedtls-3.6.7/. STM32CubeF4 v1.28.3 legt die Bibliothek unter Middlewares/Third_Party/mbedTLS ab, ohne Version im Namen; der Header dort sagt 2.16.2. STM32CubeU5 und H5 nennen den Ordner mbed-crypto, obwohl darin das volle Mbed TLS 3.6.6 liegt.

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

Wie prüfe ich das von Hand?

1. 1

   Version lesen: im Projekt aus version.h oder build_info.h, im Build mit strings -a firmware.elf | grep -i "mbed tls".

2. 2

   Prüfen, ob mbedTLS gelinkt ist: arm-none-eabi-nm firmware.elf | grep mbedtls_ listet die Funktionen im Image.

3. 3

   Linie zuordnen: 3.6 und 4.1 werden gepflegt, 2.28 und 2.16 nicht mehr. Ab 4.0 die Version von TF-PSA-Crypto getrennt lesen (TF_PSA_CRYPTO_VERSION_STRING in tf-psa-crypto/include/tf-psa-crypto/build_info.h im Baum von Mbed TLS 4).

4. 4

   NVD abfragen: virtualMatchString mit cpe:2.3:a:trustedfirmware:mbed_tls:<Version> und mit cpe:2.3:a:arm:mbed_tls:<Version>, die Treffer zusammenführen.

5. 5

   Hinweise des Projekts lesen: Security Advisories und Release Notes nennen Lücken, die in der NVD noch fehlen.

6. 6

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

Was kann ich tun?

1. 1

   Auf die neueste Version einer gepflegten Linie heben: 3.6.7, 4.1.1 oder 4.2.0. Von 2.16 oder 2.28 führt der kürzeste Weg nach 3.6; die API hat sich dabei geändert, das Projekt beschreibt den Umstieg in docs/3.0-migration-guide.md.

2. 2

   Bei einer Kopie aus STM32Cube, NXP-SDK, ESP-IDF oder Zephyr die nächste Paketversion prüfen. ESP-IDF v5.5.6 und NXP SDK 26.09.00 liefern 3.6.7, STM32CubeU5 v1.9.0 und Zephyr v4.3.1 noch 3.6.6.

3. 3

   Bis zum Update entscheidet die Konfiguration. In der Standardkonfiguration von 3.6.7 sind an: 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. Aus sind MBEDTLS_SSL_EARLY_DATA und MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED. Was ein Gerät nicht braucht, schalten Sie in mbedtls_config.h (3.x) oder config.h (2.x) ab.

4. 4

   CVE-2026-50580 setzt eine sehr lange PSK-Identität voraus. CVE-2026-49300 betrifft laut Projekt nur Anwendungen, die Zertifikate direkt von nicht vertrauenswürdigen Nutzern annehmen. CVE-2026-34877 betrifft nur Anwendungen, die TLS-Sitzungen serialisiert ablegen und wieder laden.

Geht das auch automatisch?

Builds für Mikrocontroller aus Keil MDK, IAR oder GNU Arm. Gefunden werden die eingebauten Bibliotheken mit Version, etwa CMSIS-Packs, RTX5, FreeRTOS, lwIP, mbedTLS und STM32Cube. Dazu Härtung (Stack-Canary, MPU, Privilegientrennung) und eingebettete Schlüssel.

Jede Komponente mit belegter Version wird gegen die Schwachstellenquellen abgeglichen und nennt, wo im Build sie steht. Belegt das Binary keine Version, bleibt das Feld leer.