Dropbear-Schwachstellen nach Version: warum die NVD ab 2022.83 nichts mehr zählt

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

Gezählt sind CVEs, deren NVD-Konfiguration die Version als verwundbar führt, abgefragt am 12.11.2026 über die NVD-API ohne zurückgezogene Einträge, jeder Treffer gegen seine Konfiguration nachgeprüft. Die NVD kennt drei Produktnamen für Dropbear; alle 20 Dropbear-CVEs mit Konfiguration stehen unter cpe:2.3:a:dropbear_ssh_project:dropbear_ssh, die anderen zwei liefern keine Treffer.

Ab 2020.81 hat keine Version eine CVE mit CVSS ab 9,0. Die beiden 9,8er der NVD (CVE-2016-7406 und -7407) sind seit 2016.74 behoben.

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

0

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

2

Ist Dropbear 2022.83 von Terrapin betroffen?

Ja. CVE-2023-48795 (Terrapin) ist ein Angriff auf das SSH-Protokoll, der Nachrichten am Anfang einer Verbindung entfernt. Der Text der CVE nennt „Dropbear through 2022.83“, die Konfiguration in der NVD endet aber vor 2022.83. Eine Abfrage nach Version findet die Lücke für 2022.83 deshalb nicht.

Den Schutz, Strict KEX, hat Dropbear im November 2023 eingebaut; erstes Release damit ist 2024.84. Yocto 5.0 und Debian 12 liefern 2022.83 und patchen Terrapin selbst, OpenWrt 23.05 portiert Strict KEX in seine 2022.82.

Welche Dropbear-Lücken fehlen in der Versionsabfrage?

Drei Dropbear-CVEs haben in der NVD am 12.11.2026 keine Konfiguration (Status „Deferred“) und tauchen in keiner Versionsabfrage auf.

Was haben die Releases 2026.90 bis 2026.94 behoben?

Die Änderungsliste von Dropbear nennt für 2026.90 bis 2026.93 acht Sicherheitskorrekturen. Keine davon ist in der NVD einer Dropbear-Version zugeordnet; zwei verweisen auf CVEs von OpenSSH. Eine Abfrage nach CVEs findet sie nicht, ein Abgleich mit der Änderungsliste schon.

Nach 2026.94 liegen zehn weitere Commits im Entwicklungszweig, darunter eine Korrektur an der Terminal-Ausgabe von scp und eine Build-Prüfung für Builds ohne Abgabe der Root-Rechte. Ein Release damit gibt es nicht.

Welche Dropbear-Version liefern Yocto, OpenWrt und Buildroot mit?

Gelesen aus den Rezepten an den Release-Tags und Zweigen, Stand 12.11.2026: Yocto meta/recipes-core/dropbear, OpenWrt package/network/services/dropbear/Makefile, Buildroot package/dropbear/dropbear.mk.

Yocto 6.0 liefert 2025.89 ohne CVE-Patch. OpenWrt 25.12 liefert dieselbe Version und portiert die Sicherheitskorrekturen aus 2026.90 zurück. Die Versionszeile ist in beiden Fällen dieselbe.

Wo steht die Dropbear-Version im Binary?

Dropbear setzt seine Kennung aus src/sysoptions.h zusammen: „SSH-2.0-dropbear_“ und die Version. Sie steht als Text im Binary und geht bei jeder SSH-Verbindung als erste Zeile an die Gegenstelle, ein Gerät nennt seine Version also auch über das Netz. Wer Dropbear baut, kann den Versionsteil überschreiben; dann fehlt er. OpenWrt tut genau das: 24.10 setzt die Kennung fest auf „SSH-2.0-dropbear“, 25.12 leert den Versionsteil. Im Binary steht die Nummer dann nur noch allein, etwa vor dem Text „Dropbear SSH client v%s“.

Die Zeile nennt die Upstream-Version, nie den Patchstand der Distribution.

$ strings -a usr/sbin/dropbear | grep -m1 "SSH-2.0-dropbear"

SSH-2.0-dropbear_2025.89

$ strings -a usr/sbin/dropbear | grep -B1 -m1 "^Dropbear SSH client v"

2024.86
Dropbear SSH client v%s https://matt.ucc.asn.au/dropbear/dropbear.html

Wie prüfe ich das von Hand?

1. 1

   Version lesen: strings -a usr/sbin/dropbear | grep -m1 "SSH-2.0-dropbear" im entpackten Dateisystem, bei OpenWrt grep -B1 -m1 "^Dropbear SSH client v" statt des Musters, am laufenden Gerät die erste Zeile einer Verbindung auf Port 22 (bei OpenWrt ohne Version).

2. 2

   Herkunft klären: Yocto, Buildroot, OpenWrt oder ein eigener Build. Bei Yocto und OpenWrt die Patches im Rezept lesen; sie stehen nicht in der Versionszeile.

3. 3

   Funktionen bestimmen: Ist der Client dbclient gebaut, ist scp dabei, ist X11-Weiterleitung aktiv? Mehrere Lücken treffen nur diese Teile.

4. 4

   NVD abfragen mit cpe:2.3:a:dropbear_ssh_project:dropbear_ssh:<Version>, dann Terrapin und die drei CVEs ohne NVD-Zuordnung gegen Ihre Version lesen.

5. 5

   Die Änderungsliste von Dropbear ab Ihrer Version auf „Security“ lesen; von den Korrekturen aus 2026 trägt nur die zu CVE-2026-3706 eine Dropbear-CVE.

6. 6

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

Geht das auch automatisch?

LegacyMind liest aus dem Image Dropbear, den Kernel und die 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.