lwIP vulnerabilities by version: what the NVD lists and what is missing

Which CVEs does my lwIP version have?

The NVD lists lwIP under one CPE name, cpe:2.3:a:lwip_project:lwip. Counted are CVEs whose NVD configuration lists the version as vulnerable, queried on 23 October 2026 without rejected entries. For each version, the table also shows which further CVEs the CNA names as affected in its record at CVE.org.

CVE-2020-22283 (ICMPv6, CVSS 7.5) is configured in the NVD without a version number. It therefore drops out of every version query. Its text names the Git state of the time.

$ 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

Which lwIP CVEs came in 2026, and where is the fix?

All five are published in the NVD, but without a CPE configuration: CVE-2026-8836 with status “Deferred”, the others with “Awaiting Analysis”. The CVSS scores come from the CNA. Each vulnerability sits in a module that not every build contains. For three of them, CISA published industrial control system advisories in September and October 2026 (ICSA-26-265-01, ICSA-26-265-02, ICSA-26-279-02), with the commit that closes the vulnerability.

How is lwIP maintained?

lwIP is developed on Savannah. The newest release is 2.2.1 of 6 February 2025. The master branch has received 52 commits since then, the last on 27 October 2026, among them all five fixes above, a check of the TCP options and further security fixes from 18 to 27 October (SNMP, 6LoWPAN, MQTT, PPP, TFTP). There is no release with these fixes on 30 October 2026.

On master, init.h carries revision 2 with LWIP_RC_DEVELOPMENT. A build from this state reports itself as 2.2.2 with the suffix “d” for development.

$ 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

Which lwIP version is in STM32Cube, the NXP SDK and ESP-IDF?

Many devices get lwIP through the chip vendor's SDK. These copies carry changes of their own. Whether the 2026 fixes are in them shows in the source: checked at the lines each fix changes, in the files snmp_msg.c, smtp.c, mdns.c, mqtt.c and lowpan6.c, as of 23 October 2026.

For STM32CubeH7 v1.13.0 the release notes and the SBOM name lwIP 2.2.1. The submodule at Git tag v1.13.0, however, points to ST tag v2.1.2_20190315, so lwIP 2.1.2 with CVE-2020-22283 and CVE-2020-22284. Only the master branch points to v2.2.1_20250804, since 27 March 2026.

NXP brought its lwIP to the upstream state 3d896ba0 on 16 June 2026. That state contains the fixes for SNMPv3, SMTP and mDNS. The two fixes of 31 August 2026 are missing, for MQTT and, according to CISA, for CVE-2026-91018. The file mqtt.c in the SDK is identical to the state before the fix.

$ 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;
>         }

Do the SDK copies have changes and vulnerabilities of their own?

ST lists its changes in st_readme.txt. The entry of 22 April 2016 reads: “Use updated version of LwIP v1.4.1 by integrating latest sources from LwIP Git Repository”, with a commit of 11 February 2016. In the lwIP Git that commit carries version 1.5.0 in development.

The NVD lists some vulnerabilities under the SDK vendor's product. CVE-2026-45160 affects the DHCP server in the lwIP part of ESP-IDF, CVSS 6.5, and is listed under espressif:esp-idf for 5.2.7, 5.3.5, 5.4.4, 5.5.4 and 6.0.1. Espressif's advisory names 5.2.8, 5.3.6, 5.4.5, 5.5.5 and 6.0.2 as fixed; there is no version 5.4.5 on 23 October 2026. CVE-2026-74222 affects U-Boot before 2026.10-rc5, whose wget builds on lwIP; the NVD has not yet assigned it to a product.

A version number is therefore where the check starts. Whether a fix is included is in the SDK's release notes or in the source of the copy.

Where is the lwIP version in my firmware?

In the source the version sits in src/include/lwip/init.h. lwIP assembles LWIP_VERSION_STRING from the three macros. The core of the stack does not write this text into the image. The HTTP modules do: the web server sends it in the header “Server: lwIP/2.2.1 (http://savannah.nongnu.org/projects/lwip)”, the HTTP client as its identifier. If one of them is built, the version is in the image as text. With the default setting LWIP_HTTPD_DYNAMIC_HEADERS 0, the header sits in the file data that makefsdata generated; the version in it is that of the makefsdata run.

Without an HTTP module, symbols and paths remain. Functions such as lwip_init, tcp_input and etharp_output show that lwIP is linked. The default definition of LWIP_PLATFORM_ASSERT prints the name of the source file. If it stays active, the path of the lwIP sources is in the image. The release archive lwip-2.2.1.zip unpacks to lwip-2.2.1/; if that folder name stays in the project, the version is in the path.

$ 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)"

How do I check this by hand?

1. 1

   Read the version: src/include/lwip/init.h in the project. In the build, strings -a firmware.elf | grep "lwIP/" finds the identifier if an HTTP module is built.

2. 2

   Check that lwIP is linked: arm-none-eabi-nm firmware.elf | grep -E " (lwip_init|tcp_input|etharp_output)$".

3. 3

   Establish the origin: upstream release, Git state (LWIP_RC_DEVELOPMENT) or a copy from an SDK. For an SDK copy, read the SDK's release notes, for STM32Cube from GitHub the submodule state.

4. 4

   Query the NVD: virtualMatchString=cpe:2.3:a:lwip_project:lwip:<version>. Add a keyword search for “lwIP”, because new CVEs may still lack a CPE configuration, and read the CNA records at CVE.org.

5. 5

   Check the modules: LWIP_SNMP, LWIP_SNMP_V3, LWIP_MDNS_RESPONDER and LWIP_IPV6 are 0 in the default configuration and are switched on in lwipopts.h. MQTT and SMTP are separate files under src/apps that are built only if the project includes them. In the NXP SDK, CONFIG_MCUX_COMPONENT_middleware.lwip.apps.mqtt and CONFIG_MCUX_COMPONENT_middleware.lwip.apps.mdns add the modules.

6. 6

   Check the CISA KEV catalogue for actively exploited vulnerabilities.

What can I do?

1. 1

   A device with SNMPv3, MQTT, SMTP or mDNS from lwIP: take over the five commits from the table above or move to the current master state (27 October 2026); further security fixes landed from 18 to 27 October (SNMP, 6LoWPAN, MQTT, PPP, TFTP). There is no release with all the fixes.

2. 2

   In NXP SDK 26.09.00: pull in commits 68b2c119 (MQTT, one line in mqtt.c) and f873b629.

3. 3

   lwIP 2.1.2 from STM32Cube: CVE-2020-22283 and CVE-2020-22284 are fixed from 2.1.3; ST provides the fixed version in the repository stm32-mw-lwip.

4. 4

   Switch off modules the device does not need in lwipopts.h, or take the files out of the build. A vulnerability in a module that is not built is not in the image.

Can this run automatically?

Microcontroller builds from Keil MDK, IAR or GNU Arm. It finds the libraries built in, with their versions, for example CMSIS packs, RTX5, FreeRTOS, lwIP, mbedTLS and STM32Cube. Plus hardening (stack canary, MPU, privilege separation) and embedded keys.

Every component with an evidenced version is matched against the vulnerability sources and says where in the build it sits. If the binary evidences no version, the field stays blank.