OpenSSL-Schwachstellen nach Version: 1.0.2 bis 4.1

Wie viele CVEs hat meine OpenSSL-Version?

Die Spalte „CVEs laut NVD“ zählt CVEs, deren NVD-Konfiguration die Version als verwundbar führt, abgefragt am 04.11.2026 über die NVD-API unter cpe:2.3:a:openssl:openssl, ohne zurückgezogene Einträge, jeder Treffer gegen seine Konfiguration nachgeprüft. CVE-2019-0190 erscheint bei jeder Version; sie betrifft mod_ssl im Apache HTTP Server und führt OpenSSL nur als Umgebung. Sie ist herausgerechnet. Wo die NVD keine eigene CVSS-Wertung hat, gilt die von CISA-ADP; das betrifft fast alle CVEs von 2026.

Die rechte Spalte zählt die Versionsbereiche, die OpenSSL selbst auf seiner Schwachstellenseite angibt, mit der eigenen Wertung Low, Moderate, High oder Critical. Die Spalte „Ausgeliefert in“ nennt, welches Build-System diese Version an seinem Release-Tag mitliefert.

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

28

Warum wertet die NVD OpenSSL-Lücken höher als OpenSSL?

OpenSSL wertet in eigenen Stufen und nennt die Bedingungen einer Lücke in ihrer Beschreibung. Die NVD und CISA-ADP werten nach CVSS. Von den 63 OpenSSL-CVEs aus 2026 stuft OpenSSL 49 als Low ein, 11 als Moderate und 3 als High. Die vier CVEs mit CVSS ab 9,0 hält OpenSSL für Low oder Moderate.

Für Geräte zählt die Bedingung. CVE-2026-31789 trifft nur 32-Bit-Plattformen, also auch Geräte mit 32-Bit-ARM-Linux; es braucht aber ein Zertifikat von über 1 GB, das die Anwendung ausgibt oder protokolliert.

Welche OpenSSL-CVEs fehlen in der Versionsabfrage?

Für eine Linie nach Supportende trägt OpenSSL keine Versionsbereiche mehr ein, und auch die NVD führt diese Linien danach fast nie. Die letzte Angabe für 3.1 stammt vom 20.01.2025, für 3.2 vom 30.09.2025, für 3.3 vom 07.04.2026. Seit dem jeweiligen Supportende hat OpenSSL 37 Lücken für 3.0 und eine neuere Linie gemeldet, aber nicht für 3.1; bei 3.2 sind es 35, bei 3.3 21. Der Code dieser Lücken steckt in der Linie davor und in der Linie danach. 3.1, 3.2 und 3.3 sind deshalb wahrscheinlich betroffen; geprüft hat OpenSSL das nicht. Ein Beispiel: CVE-2025-9230 nennt OpenSSL für 1.0.2, 1.1.1, 3.0 und 3.2 bis 3.5, für 3.1 nicht. Für 3.1.8, 3.2.6 und 3.3.7 ist die Zahl der NVD kein Befund.

13 CVEs mit OpenSSL als CNA haben in der NVD keine Konfiguration und fehlen in jeder Versionsabfrage: elf mit Status „Deferred“, darunter CVE-2024-12797 (High, Raw Public Keys in 3.2 bis 3.4) und CVE-2025-9230 bis -9232, dazu CVE-2026-54876 und CVE-2026-14456 mit „Awaiting Analysis“. Die rechte Spalte der Tabelle oben enthält sie.

Für 3.0.22, 1.1.1w und 1.0.2u meldet OpenSSL weiter Lücken, mit Korrekturen in 3.0.23, 1.1.1zj und 1.0.2zs. Diese Versionen gibt es nur für Kunden mit Supportvertrag; im öffentlichen Repository fehlt der Tag 3.0.23.

Welche OpenSSL-Version wird noch unterstützt?

OpenSSL erscheint zweimal im Jahr, im April und im Oktober. Alle zwei Jahre, im April ungerader Jahre, wird eine Version zur LTS mit fünf Jahren Support; die nächste ist 4.2 im April 2027. Andere Linien ab 3.5 bekommen 13 Monate Support. Laut Release-Strategie bleiben API und ABI innerhalb derselben Hauptversion kompatibel: 3.0 und 3.5 nutzen beide libssl.so.3 und libcrypto.so.3. Mit 4.0 beginnt .so.4.

Welche OpenSSL-Version steckt in Yocto, OpenWrt und Buildroot?

Gelesen aus Rezept und Makefile an den Release-Tags, Stand 04.11.2026. Yocto trägt einzelne Korrekturen auch als Patch ins Rezept ein, ohne die Versionsnummer zu ändern; Kirkstone 4.0.35 etwa Patches für CVE-2024-41996 und CVE-2023-50781 zu 3.0.19. Was ein Build als behoben führt, steht deshalb in Rezept und Patches, die Versionsnummer allein reicht nicht.

Das Standard-Image von OpenWrt 24.10.8 und 25.12.6 enthält kein OpenSSL, TLS kommt dort aus mbedTLS. OpenSSL kommt erst mit Paketen in den Build, die es brauchen. Die Paketquelle einer OpenWrt-Linie wird nach dem Release weiter aktualisiert: am Tag v24.10.8 steht 3.0.21, in der Paketquelle 3.0.22.

$ curl -s "https://api.github.com/repos/openembedded/openembedded-core/contents/meta/recipes-connectivity/openssl?ref=yocto-5.0.21"  \
| jq -r '.[].name' | grep openssl_

openssl_3.5.8.bb

Wo steht die OpenSSL-Version in meiner Firmware?

OpenSSL schreibt seine Version mit Datum als Text in libcrypto, ab 3.0 in der Form „OpenSSL 3.0.22 25 Aug 2026“, bis 1.1.1 mit zwei Leerzeichen vor dem Datum. Im geprüften Paket steht dieser Text nur in libcrypto, nicht in libssl. Der Dateiname der Bibliothek nennt nur die Hauptlinie: libssl.so.3 für alle Versionen von 3.0 bis 3.6, libssl.so.4 ab 4.0, libssl.so.1.1 für 1.1.x, im Original libssl.so.1.0.0 für 1.0.x.

Geprüft am Paket libopenssl3_3.0.22-r1_arm_cortex-a7_neon-vfpv4.ipk aus der Paketquelle von OpenWrt 24.10.8, 32-Bit-ARM, SHA-256 1ac68ea8fd17b168…, entpackt.

$ strings -a usr/lib/libcrypto.so.3 | grep -E "^OpenSSL [0-9]"

OpenSSL 3.0.22 25 Aug 2026

$ strings -a usr/lib/libssl.so.3 | grep -E "^lib(ssl|crypto)\.so"

libcrypto.so.3
libssl.so.3

$ curl -s https://raw.githubusercontent.com/openssl/openssl/OpenSSL_1_1_1w/include/openssl/opensslv.h  \
| grep "define OPENSSL_VERSION_TEXT"

# define OPENSSL_VERSION_TEXT    "OpenSSL 1.1.1w  11 Sep 2023"

Wie prüfe ich das von Hand?

1. 1

   Version lesen: strings -a libcrypto.so.* | grep -E "^OpenSSL [0-9]" im entpackten Dateisystem, auf dem Gerät openssl version. Ist OpenSSL statisch in ein Programm gelinkt, gibt es keine eigene Bibliothek; dann strings auf das Programm selbst.

2. 2

   Alle Kopien suchen: Neben der System-Bibliothek bringen manche Anwendungen eine eigene OpenSSL mit eigener Version mit.

3. 3

   Herkunft klären: Yocto, OpenWrt, Buildroot oder eine Distribution. Bei Yocto die Patches im Rezept lesen, sie beheben CVEs ohne neue Versionsnummer.

4. 4

   NVD abfragen mit cpe:2.3:a:openssl:openssl:<Version> und die Schwachstellenseite von OpenSSL lesen; sie führt auch die CVEs ohne NVD-Konfiguration. Für 3.1, 3.2 und 3.3 die Lücken der Nachbarlinien mitlesen.

5. 5

   Bedingungen prüfen: viele Lücken betreffen nur CMS, PKCS#7, CMP, QUIC, DTLS oder 32-Bit-Plattformen. Ob die Firmware diese Teile nutzt, entscheidet über die Ausnutzbarkeit.

6. 6

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

Geht das auch automatisch?

LegacyMind liest aus dem Image die Bibliotheken und Pakete mit ihren Versionen und gleicht jede gegen die öffentlichen Schwachstellenquellen ab, mit der Fundstelle im Image und dem Vermerk, ob eine Lücke aktiv ausgenutzt wird. Belegt das Image keine Version, bleibt das Feld leer.