lwIP-Schwachstellen nach Version: was NVD führt und was fehlt

Welche CVEs hat meine lwIP-Version?

NVD führt lwIP unter einem CPE-Namen, cpe:2.3:a:lwip_project:lwip. Gezählt sind CVEs, deren NVD-Konfiguration die Version als verwundbar führt, abgefragt am 23.10.2026 ohne zurückgezogene Einträge. Dazu steht je Version, welche weiteren CVEs der CNA in seinem Eintrag bei CVE.org als betroffen nennt.

CVE-2020-22283 (ICMPv6, CVSS 7,5) ist in NVD ohne Versionsnummer konfiguriert. Sie fällt deshalb bei jeder Versionsabfrage heraus. Ihr Text nennt den damaligen Git-Stand.

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

0

Welche lwIP-CVEs kamen 2026, und wo liegt die Korrektur?

Alle fünf sind in der NVD veröffentlicht, aber ohne CPE-Konfiguration: CVE-2026-8836 mit Status „Deferred“, die anderen mit „Awaiting Analysis“. Die CVSS-Werte stammen vom CNA. Jede Lücke sitzt in einem Modul, das nicht jeder Build enthält. Für drei davon hat CISA im September und Oktober 2026 eigene Hinweise für Industriesteuerungen veröffentlicht (ICSA-26-265-01, ICSA-26-265-02, ICSA-26-279-02), mit dem Commit, der die Lücke schließt.

Wie wird lwIP gepflegt?

lwIP wird auf Savannah entwickelt. Das neueste Release ist 2.2.1 vom 06.02.2025. Auf dem master-Zweig liegen seither 52 Commits, der letzte vom 27.10.2026, darunter alle fünf Korrekturen oben, eine Prüfung der TCP-Optionen und weitere Sicherheitskorrekturen vom 18. bis 27.10. (SNMP, 6LoWPAN, MQTT, PPP, TFTP). Ein Release mit diesen Korrekturen gibt es am 30.10.2026 nicht.

Auf master trägt init.h die Revision 2 mit LWIP_RC_DEVELOPMENT. Ein Build von diesem Stand meldet sich als 2.2.2 mit dem Suffix „d“ für Entwicklung.

$ git tag --contains 0c957ec0 | wc -l

0

$ git tag --contains 614420f8 | wc -l

0

$ grep -E "#define LWIP_VERSION_(REVISION|RC) " src/include/lwip/init.h

#define LWIP_VERSION_REVISION   2
#define LWIP_VERSION_RC         LWIP_RC_DEVELOPMENT

Welche lwIP-Version steckt in STM32Cube, NXP-SDK und ESP-IDF?

Viele Geräte bekommen lwIP über das SDK des Chipherstellers. Diese Kopien tragen eigene Änderungen. Ob die Korrekturen von 2026 darin stehen, zeigt der Quelltext: geprüft an den Zeilen, die jede Korrektur ändert, in den Dateien snmp_msg.c, smtp.c, mdns.c, mqtt.c und lowpan6.c, Stand 23.10.2026.

Bei STM32CubeH7 v1.13.0 nennen Release Notes und SBOM lwIP 2.2.1. Das Submodul am Git-Tag v1.13.0 zeigt aber auf ST-Tag v2.1.2_20190315, also lwIP 2.1.2 mit CVE-2020-22283 und CVE-2020-22284. Erst der master-Zweig zeigt seit dem 27.03.2026 auf v2.2.1_20250804.

NXP hat sein lwIP am 16.06.2026 auf den Upstream-Stand 3d896ba0 gebracht. Darin stehen die Korrekturen für SNMPv3, SMTP und mDNS. Die beiden Korrekturen vom 31.08.2026 fehlen, für MQTT und, laut CISA, für CVE-2026-91018. Die Datei mqtt.c im SDK ist identisch mit dem Stand davor.

$ curl -s https://raw.githubusercontent.com/nxp-mcuxpresso/lwip/a819058895af886fce65250cd82a8cf52a1b980d/src/apps/mqtt/mqtt.c  \
| diff - <(git show 68b2c119:src/apps/mqtt/mqtt.c)

862c862,866
<         client->rx_buffer[client->msg_idx++] = b;
---
>         if (client->msg_idx < MQTT_VAR_HEADER_BUFFER_LEN) {
>           client->rx_buffer[client->msg_idx++] = b;
>         } else {
>           return MQTT_CONNECT_DISCONNECTED;
>         }

Haben die SDK-Kopien eigene Änderungen und Lücken?

ST listet seine Änderungen in st_readme.txt. Im Eintrag vom 22.04.2016 steht: „Use updated version of LwIP v1.4.1 by integrating latest sources from LwIP Git Repository“, mit einem Commit vom 11.02.2016. Im lwIP-Git trägt dieser Commit die Version 1.5.0 in Entwicklung.

Manche Lücken führt NVD unter dem Produkt des SDK-Herstellers. CVE-2026-45160 betrifft den DHCP-Server im lwIP-Teil von ESP-IDF, CVSS 6,5, und steht unter espressif:esp-idf für 5.2.7, 5.3.5, 5.4.4, 5.5.4 und 6.0.1. Das Advisory von Espressif nennt als Korrektur 5.2.8, 5.3.6, 5.4.5, 5.5.5 und 6.0.2; eine Version 5.4.5 gibt es am 23.10.2026 nicht. CVE-2026-74222 betrifft U-Boot vor 2026.10-rc5, dessen wget auf lwIP aufsetzt; NVD hat sie noch keinem Produkt zugeordnet.

Eine Versionsnummer ist deshalb der Anfang der Prüfung. Ob eine Korrektur enthalten ist, steht in den Release Notes des SDK oder im Quelltext der Kopie.

Wo steht die lwIP-Version in meiner Firmware?

Im Quellcode steht die Version in src/include/lwip/init.h. Aus den drei Makros setzt lwIP LWIP_VERSION_STRING zusammen. Der Kern des Stacks schreibt diesen Text nicht ins Image. Das tun die HTTP-Module: der Webserver sendet ihn im Header „Server: lwIP/2.2.1 (http://savannah.nongnu.org/projects/lwip)“, der HTTP-Client als Kennung. Ist einer davon gebaut, steht die Version als Text im Image. Bei der Standardeinstellung LWIP_HTTPD_DYNAMIC_HEADERS 0 steht der Header in den Dateidaten, die makefsdata erzeugt hat; die Version darin ist die des makefsdata-Laufs.

Ohne HTTP-Modul bleiben Symbole und Pfade. Funktionen wie lwip_init, tcp_input und etharp_output zeigen, dass lwIP gelinkt ist. Die Standarddefinition von LWIP_PLATFORM_ASSERT gibt den Namen der Quelldatei aus. Bleibt sie aktiv, steht der Pfad der lwIP-Quellen im Image. Das Release-Archiv lwip-2.2.1.zip entpackt nach lwip-2.2.1/; bleibt dieser Ordnername im Projekt, steht die Version im Pfad.

$ grep -E "#define LWIP_VERSION_(MAJOR|MINOR|REVISION|RC) "  \
src/include/lwip/init.h

#define LWIP_VERSION_MAJOR      2
#define LWIP_VERSION_MINOR      2
#define LWIP_VERSION_REVISION   1
#define LWIP_VERSION_RC         LWIP_RC_RELEASE

$ grep -n "define HTTPD_SERVER_AGENT" src/include/lwip/apps/httpd_opts.h

172:#define HTTPD_SERVER_AGENT "lwIP/" LWIP_VERSION_STRING " (http://savannah.nongnu.org/projects/lwip)"

Wie prüfe ich das von Hand?

1. 1

   Version lesen: src/include/lwip/init.h im Projekt. Im Build findet strings -a firmware.elf | grep "lwIP/" die Kennung, wenn ein HTTP-Modul gebaut ist.

2. 2

   Prüfen, ob lwIP gelinkt ist: arm-none-eabi-nm firmware.elf | grep -E " (lwip_init|tcp_input|etharp_output)$".

3. 3

   Herkunft klären: Upstream-Release, Git-Stand (LWIP_RC_DEVELOPMENT) oder Kopie aus einem SDK. Bei einer SDK-Kopie die Release Notes des SDK lesen, bei STM32Cube aus GitHub den Submodul-Stand.

4. 4

   NVD abfragen: virtualMatchString=cpe:2.3:a:lwip_project:lwip:<Version>. Dazu eine Stichwortsuche nach „lwIP“, weil neue CVEs noch ohne CPE-Konfiguration sein können, und die CNA-Einträge bei CVE.org lesen.

5. 5

   Module prüfen: LWIP_SNMP, LWIP_SNMP_V3, LWIP_MDNS_RESPONDER und LWIP_IPV6 stehen in der Standardkonfiguration auf 0 und werden in lwipopts.h eingeschaltet. MQTT und SMTP sind eigene Dateien unter src/apps, die nur gebaut werden, wenn das Projekt sie einbindet. Im NXP-SDK schalten CONFIG_MCUX_COMPONENT_middleware.lwip.apps.mqtt und CONFIG_MCUX_COMPONENT_middleware.lwip.apps.mdns die Module zu.

6. 6

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

Was kann ich tun?

1. 1

   Ein Gerät mit SNMPv3, MQTT, SMTP oder mDNS aus lwIP: die fünf Commits aus der Tabelle oben übernehmen oder auf den aktuellen master-Stand (27.10.2026) gehen; vom 18. bis 27.10. kamen weitere Sicherheitskorrekturen dazu (SNMP, 6LoWPAN, MQTT, PPP, TFTP). Ein Release mit allen Korrekturen gibt es nicht.

2. 2

   Im NXP-SDK 26.09.00: die Commits 68b2c119 (MQTT, eine Zeile in mqtt.c) und f873b629 nachziehen.

3. 3

   lwIP 2.1.2 aus STM32Cube: CVE-2020-22283 und CVE-2020-22284 sind ab 2.1.3 behoben; ST stellt die korrigierte Fassung im Repository stm32-mw-lwip bereit.

4. 4

   Module, die das Gerät nicht braucht, in lwipopts.h abschalten oder die Dateien aus dem Build nehmen. Eine Lücke in einem Modul, das nicht gebaut ist, steht nicht im Image.

Geht das auch automatisch?

Builds für Mikrocontroller aus Keil MDK, IAR oder GNU Arm. Gefunden werden die eingebauten Bibliotheken mit Version, etwa CMSIS-Packs, RTX5, FreeRTOS, lwIP, mbedTLS und STM32Cube. Dazu Härtung (Stack-Canary, MPU, Privilegientrennung) und eingebettete Schlüssel.

Jede Komponente mit belegter Version wird gegen die Schwachstellenquellen abgeglichen und nennt, wo im Build sie steht. Belegt das Binary keine Version, bleibt das Feld leer.