Zephyr-Schwachstellen nach Version: LTS, Patch-Releases und NVD

Wie viele CVEs führt die NVD für meine Zephyr-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 Zephyr unter cpe:2.3:o:zephyrproject:zephyr; die ältere Form mit a: ist im CPE-Wörterbuch abgelöst und lieferte keinen Treffer. Zwei Treffer, die nur Release-Kandidaten betreffen, sind herausgerechnet.

Die CVSS-Wertung ist die der NVD, sonst die der Zephyr-CNA. Die NVD wertet höher: CVE-2026-10666 (parse_ipv4) hat bei der NVD 9,8, bei Zephyr 8,1.

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

57

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

26

Warum zählt die NVD für Patch-Releases zu viele CVEs?

Zephyr behebt eine Lücke im Hauptzweig und portiert die Korrektur in die gepflegten Zweige zurück, 2026 nach v4.4, v4.3 und v3.7. NVD konfiguriert die CVE aber meist mit einem Bereich bis vor der nächsten Hauptversion, etwa „ab 2.5.0, vor 4.5.0“. Damit zählt jedes Patch-Release der Linie mit, auch wenn die Korrektur schon darin steckt.

Nachgeprüft an CVE-2026-10634 (Use-after-free in net_tcp_foreach()): NVD führt den Bereich bis vor 4.5.0. Der Backport (Pull Request 107289, gemergt am 22.04.2026) ist laut GitHub in 4.4.2 enthalten, in 4.4.0 nicht. Für 4.4.2 zählt NVD diese CVE trotzdem.

Für 4.4.2 trifft das auf alle 26 CVEs zu: Bei jeder nennt die Liste des Projekts einen Backport nach v4.4, und jeder dieser Backports ist laut GitHub in 4.4.2 enthalten.

Für 3.7.2 sieht es anders aus. Von den 57 CVEs ist die Korrektur bei neun schon in 3.7.2 enthalten. Bei 37 liegt sie im Zweig v3.7, wurde aber erst nach 3.7.2 gemergt; 36 davon stecken im Release-Kandidaten 3.7.3-rc1 vom 06.08.2026. Bei elf nennt die Liste keinen Backport nach 3.7.

$ gh api repos/zephyrproject-rtos/zephyr/compare/v4.4.2...168295f5a16d  \
-q .status

behind

Welche vier CVEs ab 9,0 hat Zephyr 3.7.2?

Alle vier betreffen den Netzwerk-Stack. Zwei sind in 3.7.2 schon korrigiert, zwei erst im Zweig v3.7 danach.

Welche Zephyr-Version steckt im nRF Connect SDK?

Das nRF Connect SDK von Nordic holt Zephyr aus dem eigenen Repository sdk-zephyr, festgelegt in west.yml. In allen geprüften Versionen bis 3.3 ist das ein Stand mit der Endung .99. Laut Release-Prozess von Zephyr markiert x.y.99 den Hauptzweig, nachdem die Arbeit an der nächsten Nebenversion begonnen hat. Ein solcher Stand ist kein Zephyr-Release; die NVD-Zahl der benachbarten Version ist dafür nur ein Ausgangspunkt. Seit nRF Connect SDK 3.4.0 steht dort ein Release.

$ curl -s https://raw.githubusercontent.com/nrfconnect/sdk-nrf/v3.3.4/west.yml  \
| grep -A2 "name: zephyr$";  \
curl -s https://raw.githubusercontent.com/nrfconnect/sdk-zephyr/ncs-v3.3.4/VERSION  \
| head -3

    - name: zephyr
      repo-path: sdk-zephyr
      revision: ncs-v3.3.4
VERSION_MAJOR = 4
VERSION_MINOR = 3
PATCHLEVEL = 99

Welche Zephyr-CVEs fehlen in der NVD-Versionsabfrage?

Die Zephyr-CNA hat am 23.10.2026 308 CVEs in der NVD. 124 davon haben noch keine Konfiguration (Status etwa „Awaiting Analysis“) und zählen bei keiner Version mit. Die eigene Liste des Projekts, „Vulnerabilities“ in der Zephyr-Dokumentation, nennt je CVE die Korrektur und die Backports je Zweig.

Für eine Zephyr-Version heißt das: lesen Sie die Liste des Projekts gegen Ihre Linie. Die NVD-Zahl allein ist für Patch-Releases zu hoch und für neue Lücken zu niedrig.

Welche Zephyr-Linien bekommen Korrekturen?

Laut Release-Prozess erscheinen LTS-Releases alle 2,5 bis 3 Jahre und werden etwa fünf Jahre gepflegt, die ersten zwei Jahre mit allgemeinen Fehlerkorrekturen, danach nur noch mit Sicherheits- und Stabilitätskorrekturen. „Support for a given LTS release (LTS N) continues until the initial release of the LTS two versions ahead (LTS N+2).“ Seit 2026 erscheinen Releases im April und im Oktober.

Wo steht die Zephyr-Version in meiner Firmware?

Im Quellbaum steht die Version in der Datei VERSION (VERSION_MAJOR, VERSION_MINOR, PATCHLEVEL). Daraus erzeugt der Build include/generated/zephyr/version.h mit KERNEL_VERSION_STRING und BUILD_VERSION; BUILD_VERSION ist die Ausgabe von git describe, also „v4.4.2“ oder eine Form mit Commit-Hash.

Im Build steht die Version im Boot-Banner, das kernel/banner.c als einen zusammenhängenden Text ausgibt: „*** Booting Zephyr OS build v4.4.2 ***“. Das Banner ist standardmäßig an (CONFIG_BOOT_BANNER=y); ein Hersteller kann es abschalten oder den Text CONFIG_BOOT_BANNER_STRING ändern. sys_kernel_version_get() liefert dagegen eine Zahl, die strings nicht findet.

$ curl -s https://raw.githubusercontent.com/zephyrproject-rtos/zephyr/v4.4.2/kernel/banner.c  \
| grep "Booting\|CONFIG_BOOT_BANNER_STRING"

	printk("*** " CONFIG_BOOT_BANNER_STRING " " BANNER_VERSION BANNER_POSTFIX " ***\n");

Wie prüfe ich das von Hand?

1. 1

   Version lesen: strings -a zephyr.elf | grep "Booting Zephyr", im Projekt aus VERSION oder version.h.

2. 2

   Linie zuordnen: gepflegt sind 4.5, 4.4 und die LTS-Linie 3.7.

3. 3

   NVD abfragen mit cpe:2.3:o:zephyrproject:zephyr:<Version>.

4. 4

   Die Liste „Vulnerabilities“ des Projekts gegen Ihre Linie lesen: sie nennt Backports, die NVD nicht abbildet, und CVEs, die in der NVD noch ohne Konfiguration sind.

5. 5

   Konfiguration prüfen: viele Lücken betreffen den Netzwerk-Stack, Bluetooth oder den HTTP-Server und setzen voraus, dass das Subsystem im Build ist (prj.conf, .config). Für die kritischen CVEs in 3.7.2 sind das etwa CONFIG_DNS_RESOLVER und CONFIG_HTTP_SERVER_WEBSOCKET.

6. 6

   Beim nRF Connect SDK die Zephyr-Version aus west.yml und der Datei VERSION in sdk-zephyr lesen.

7. 7

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

Geht das auch automatisch?

LegacyMind liest aus dem Build das RTOS und 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.