BusyBox-Schwachstellen nach Version: was die NVD zählt und was kein Release behebt

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

Gezählt sind CVEs, deren NVD-Konfiguration die Version als verwundbar führt, abgefragt am 04.11.2026 über die NVD-API ohne zurückgezogene Einträge, jeder Treffer gegen seine Konfiguration nachgeprüft. Die NVD führt BusyBox unter cpe:2.3:a:busybox:busybox. Die Spalte „Ausgeliefert in“ nennt, welches Build-System oder welche Distribution diese Version mitliefert.

Die Zahl fällt nicht stetig. 1.36.1 hat mehr als 1.35.0, weil die NVD vier awk-Lücken von 2023 (CVE-2023-42363 bis -42366) nur für genau 1.36.1 führt. Yocto patcht sie auch in 1.35.0.

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

7

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

3

Welche BusyBox-CVEs haben CVSS ab 9,0?

Welche BusyBox-Lücken behebt auch 1.38.0 nicht?

Für diese fünf Lücken gibt es am 04.11.2026 kein BusyBox-Release mit Korrektur. Die Korrekturen liegen im Entwicklungszweig, als Einreichung beim Projekt oder nur als Patch der Build-Systeme, und Yocto oder Buildroot tragen jede davon selbst in ihre 1.38.0 ein. Die NVD-Zählung bildet das nicht ab: vier der fünf zählt sie für 1.38.0 nicht.

Welche BusyBox-CVEs fehlen in der Versionsabfrage?

20 BusyBox-CVEs haben in der NVD am 04.11.2026 keine Konfiguration (Status „Awaiting Analysis“ oder „Deferred“) und tauchen in keiner Versionsabfrage auf. 15 davon sind zwischen dem 23.09. und dem 21.10.2026 erschienen, 14 mit Red Hat als CNA. Sie betreffen unter anderem httpd, den TLS-Code, udhcpc, tar, dpkg und mount. Debian führt alle 15 in seinem Paket 1.38.0 als offen, eine davon als unwichtig.

BusyBox hat seit 1.38.0 kein Release veröffentlicht. Korrekturen für tar und httpd vom Oktober 2026 liegen nur im Entwicklungszweig.

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

Gelesen aus den Rezepten an den Release-Tags und Zweigen, Stand 04.11.2026: Yocto meta/recipes-core/busybox/busybox_<Version>.bb, OpenWrt package/utils/busybox/Makefile, Buildroot package/busybox/busybox.mk. Gezählt sind Patches, die eine CVE im Namen oder im Kopf tragen.

Die Patches ändern die Versionszeile nicht. Ein Yocto-5.0-Build meldet „BusyBox v1.36.1“, und CVE-2022-48174 ist darin behoben. Ein OpenWrt-24.10-Build meldet dieselbe Version, und unter seinen zwölf Patches ist keiner für ash. Ein Abgleich nur nach Version kann beide nicht unterscheiden. Buildroot 2026.02.3 trägt weniger BusyBox-Patches als 2025.02.19: die Korrekturen für CVE-2026-29004, -26157 und -26158 fehlen dort.

Wo steht die BusyBox-Version im Binary?

BusyBox schreibt seine Version als zusammenhängenden Text ins Binary, in bb_banner aus libbb/messages.c: „BusyBox v“, die Version und ein Zusatz in Klammern. Im Original ist der Zusatz die Bauzeit im Format JJJJ-MM-TT hh:mm:ss UTC. Distributionen setzen eigenen Text, Debian etwa die Paketversion. Auf dem Gerät gibt busybox ohne Argumente dieselbe Zeile aus, gefolgt von „multi-call binary.“

Die Zeile nennt die Upstream-Version. Patches des Build-Systems stehen nicht darin; die stehen im Rezept des Builds.

$ curl -s https://raw.githubusercontent.com/mirror/busybox/1_38_0/libbb/messages.c  \
| grep -n -E "bb_banner\[\]|define BB_EXTRA_VERSION"

11:#define BB_EXTRA_VERSION " ("AUTOCONF_TIMESTAMP")"
14:const char bb_banner[] ALIGN1 = "BusyBox v" BB_VER BB_EXTRA_VERSION;

$ strings -a usr/bin/busybox | grep -m1 "^BusyBox v"

BusyBox v1.37.0 (Debian 1:1.37.0-6+b9)

Wie prüfe ich das von Hand?

1. 1

   Version lesen: strings -a bin/busybox | grep -m1 "^BusyBox v" im entpackten Dateisystem, auf dem Gerät busybox | head -1.

2. 2

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

3. 3

   Applets bestimmen: busybox --list auf dem Gerät oder die .config des Builds. Eine Lücke in httpd, udhcpc6, tar oder dpkg betrifft nur Builds, die dieses Applet enthalten.

4. 4

   Netzwerk-Applets zuerst: udhcpc, udhcpc6, httpd, wget und ntpd sind aus dem Netz erreichbar, awk und die Shell meist nur über lokale Eingaben.

5. 5

   NVD abfragen mit cpe:2.3:a:busybox:busybox:<Version>, dann die CVEs ohne NVD-Zuordnung gegen Ihre Version lesen, etwa im Security Tracker von Debian für busybox.

6. 6

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

Geht das auch automatisch?

LegacyMind liest aus dem Image BusyBox, 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.