wolfSSL-Schwachstellen nach Version: die CVE-Liste je Release

Wie viele CVEs führt die NVD für meine wolfSSL-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 wolfSSL unter cpe:2.3:a:wolfssl:wolfssl; wolfCrypt hat keinen eigenen CVE-Bestand, seine Lücken stehen unter wolfSSL. Die alten Namen für CyaSSL lieferten für keine der geprüften Versionen einen Treffer.

Die Spalte „ab 9,0“ zählt nach der Wertung der NVD. wolfSSL wertet als CNA oft deutlich niedriger: CVE-2026-4395 hat bei der NVD 9,8, bei wolfSSL 1,3 („Low“).

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

78

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

0

Welche elf CVEs ab 9,0 hat wolfSSL 5.8.4?

Die meisten setzen eine Funktion voraus, die im Build eingeschaltet sein muss. Die Bedingung steht jeweils in der Beschreibung der CVE. Die erste Zahl ist die Wertung der NVD, die zweite die von wolfSSL.

Kann ich die Lücken im Build abschalten?

Acht der elf hängen an Funktionen, die bei configure standardmäßig aus sind: ECH (HAVE_ECH, drei CVEs), CRL (HAVE_CRL), DTLS 1.3 (WOLFSSL_DTLS13), PKCS7 (HAVE_PKCS7), KCAPI für ECC (WOLFSSL_KCAPI_ECC) und Dual-Algorithm-Zertifikate (WOLFSSL_DUAL_ALG_CERTS, setzt zusätzlich --enable-experimental voraus).

Bei Keil- und IAR-Projekten gibt es kein configure. Dort steht in user_settings.h, welche Makros gesetzt sind. Wer ECH, CRL, DTLS 1.3 oder PKCS7 nicht braucht, nimmt das Makro heraus; der Code fehlt dann im Build. Für CVE-2026-5187 nennt die Beschreibung keine Bedingung; hier hilft nur ein neues Release.

$ curl -s https://raw.githubusercontent.com/wolfSSL/wolfssl/v5.8.4-stable/configure.ac  \
| grep -E "AS_HELP_STRING\(\[--enable-(ech|crl|dtls13|pkcs7|kcapi-ecc)\]"

    [AS_HELP_STRING([--enable-ech],[Enable ECH (default: disabled)])],
    [AS_HELP_STRING([--enable-kcapi-ecc],[Enable libkcapi use for ECC (default: disabled)])],
    [AS_HELP_STRING([--enable-dtls13],[Enable wolfSSL DTLS v1.3 (default: disabled)])],
    [AS_HELP_STRING([--enable-crl],[Enable CRL (Use =io for inline CRL HTTP GET) (default: disabled)])],
    [AS_HELP_STRING([--enable-pkcs7],[Enable PKCS7 (default: disabled)])],

Welche wolfSSL-Version bringen die Hersteller-SDKs mit?

ESP-IDF nutzt für TLS standardmäßig mbedTLS. wolfSSL kommt erst mit der Option CONFIG_ESP_TLS_USING_WOLFSSL und einer eigenen Komponente in den Build.

$ curl -s https://raw.githubusercontent.com/wolfSSL/wolfssl/$(gh api  \
repos/espressif/esp-wolfssl/contents/wolfssl -q .sha)/wolfssl/version.h  \
| grep VERSION_STRING

#define LIBWOLFSSL_VERSION_STRING "5.9.1"

Wo widersprechen sich NVD und wolfSSL?

wolfSSL führt eine eigene Liste seiner Schwachstellen mit Schweregrad und korrigierter Version. Von den 167 Zeilen, die sie am 23.10.2026 zeigt, tragen 19 keine CVE-Nummer; diese Lücken fehlen in jeder NVD-Abfrage.

Andere stehen in der NVD ohne Konfiguration und zählen bei keiner Version mit: CVE-2026-89136 (Umgehung der Authentifizierung mit Raw Public Keys, laut wolfSSL 5.6.0 bis 5.9.2, korrigiert in 5.9.4) mit Status „Awaiting Analysis“, CVE-2025-7395 (Prüfung des Hostnamens, nur mit Apple-Zertifikatsprüfung) mit Status „Deferred“.

Auch die Wertung weicht ab. Einen Teil erklärt SECURITY-POLICY.md: Fehler, die physischen Zugang, physische Seitenkanäle oder Fehlerinjektion voraussetzen, behandelt wolfSSL in der Regel als Fehlerkorrektur, nicht als CVE.

Welche wolfSSL-Releases bekommen noch Korrekturen?

SECURITY-POLICY.md (Stand 22.04.2026): „Security fixes are released for the current stable release and the immediately prior stable release. Older releases receive security fixes only under active commercial support agreements.“ Am 23.10.2026 sind das 5.9.4 und 5.9.2.

wolfSSL veröffentlicht drei bis vier Releases im Jahr, 2026 bisher 5.9.0 (18.03.), 5.9.1 (08.04.), 5.9.2 (23.06.) und 5.9.4 (25.09.). Wer eine Linie hält, bekommt Korrekturen also nur durch einen Wechsel auf ein neues Release.

Wo steht die wolfSSL-Version in meiner Firmware?

Im Quellcode steht die Version in wolfssl/version.h: LIBWOLFSSL_VERSION_STRING und LIBWOLFSSL_VERSION_HEX (für 5.9.4 0x05009004). Die Datei ist im Release enthalten, Keil- und IAR-Projekte übernehmen sie unverändert.

Im Build steht die Version nur, wenn die Firmware wolfSSL_lib_version() aufruft oder das Makro selbst ausgibt, und dann als blankes „5.9.4“ ohne den Namen wolfSSL. In unserem Test-Build (5.9.4, GCC für x86-64 mit --gc-sections, gestrippt) fand strings ohne diesen Aufruf weder die Version noch den Namen. Die Version kommt dann aus version.h im Projekt; dass wolfSSL gelinkt ist, zeigen die Funktionsnamen mit dem Präfix wolfSSL_ in der Symboltabelle des ELF.

$ grep -E "define LIBWOLFSSL_VERSION_(STRING|HEX)"  \
wolfssl-5.9.4/wolfssl/version.h

#define LIBWOLFSSL_VERSION_STRING "5.9.4"
#define LIBWOLFSSL_VERSION_HEX 0x05009004

Wie prüfe ich das von Hand?

1. 1

   Version lesen: im Projekt aus wolfssl/version.h, im Build mit strings -a firmware.elf | grep -E "^[0-9]+\.[0-9]+\.[0-9]+$", falls die Firmware die Version ausgibt.

2. 2

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

3. 3

   NVD abfragen mit cpe:2.3:a:wolfssl:wolfssl:<Version>.

4. 4

   Die Schwachstellenliste von wolfSSL lesen: sie führt Lücken ohne CVE-Nummer und Korrekturen, deren Version in der NVD anders steht.

5. 5

   Konfiguration prüfen: viele Lücken setzen eine Option voraus, etwa RPK (HAVE_RPK) bei CVE-2026-89136. Die Optionen stehen in user_settings.h oder in den Optionen von configure.

6. 6

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

Geht das auch automatisch?

LegacyMind liest aus dem Build die gelinkten Bibliotheken mit ihren Versionen und gleicht jede gegen die Schwachstellenquellen ab, mit der Fundstelle im Build. Belegt das Binary keine Version, bleibt das Feld leer.