Summary
On September 22, 2026, CISA published two advisories for lwIP, the open-source TCP/IP stack found inside a large share of embedded devices.
- ICSA-26-265-01, CVE-2026-87121: an out-of-bounds write in the lwIP MQTT client. CVSS v3.1 9.8, v4.0 9.3. An attacker can reach it over the network with no login and no user action. CISA says it "may allow an attacker to gain full code execution on the device".
- ICSA-26-265-02, CVE-2026-91018: a double free in the lwIP API. CVSS v3.1 8.8, v4.0 8.7. The attacker must be on an adjacent network. CISA says it is not exploitable remotely. The result is a crash, a denial of service, or memory corruption that could lead to code execution.
Both advisories cover lwIP 2.0.1 through 2.2.1. CISA lists eight sectors, including Water and Wastewater, Energy, Chemical and Critical Manufacturing.
Most ICS advisories name a product. These two advisories name no product, so you first have to find out which of your devices are affected.
What the advisories say
- Vendor: lwIP, the open-source project. CISA gives Sweden as the headquarters, where the stack started.
- CVE-2026-87121: CWE-787, out-of-bounds write in the MQTT client application. Credited to Shahriyar Jalayeri of ByteRay Ltd.
- CVE-2026-91018: CWE-415, double free. Credited to Eric Evenchick of Tetrel Security.
- Fix: two commits in the lwIP repository,
f89407ea711879c04d91c92b35d67be78bbaf0f1for the MQTT client andf873b6295933e4149a2132adf3e9a2d2a676a5ecfor the double free. - Known exploitation: none reported to CISA at publication.
| CVE | Where | CVSS v3.1 | Reach | Upstream fix |
|---|---|---|---|---|
| CVE-2026-87121 | MQTT client application | 9.8 | Network, no login | Commit f89407e |
| CVE-2026-91018 | lwIP API, memory handling | 8.8 | Adjacent network only | Commit f873b62 |
Why the advisories list no products
lwIP is a library, and plants do not buy it directly. A device maker chooses a microcontroller, uses the networking stack that comes with the chip vendor's SDK, which is very often lwIP, and builds firmware on top of it. The result ships as a sensor gateway, a protocol converter, a small RTU, a power meter, an I/O module or a cellular modem.
The advisories therefore ask which of your devices were built on lwIP 2.0.1 to 2.2.1. Your asset inventory cannot answer this. It lists the product and the firmware version, and it does not list the libraries compiled into the firmware. The device maker knows. An SBOM can also tell you, if you have one.
The fix is a commit in a source repository, and you cannot install it. Each maker has to pull it into their code, rebuild, test and release new firmware. You then have to schedule the update. For a device at a remote site that is rebooted once a year, this takes months. For a product that its maker no longer supports, no fix will come.
How to assess the MQTT client flaw
The 9.8 score means the flaw is reachable over the network with no login. Before you rank it against the rest of your list, find out where the malicious data would come from.
An MQTT client does not wait for incoming connections. It opens a connection to a broker and receives messages from it. In our reading of the vector, the practical attacker is whoever can respond as that broker: a compromised broker, a spoofed broker, or anyone on the path between the device and its broker who can tamper with the session.
Ask three questions about every device that uses MQTT:
- Which broker does it connect to? It may connect to the local SCADA broker, a vendor's cloud, or both.
- Can it reach anything else? If a device can open connections to any address, anyone who controls DNS or routing on its segment can point it at a hostile broker.
- Is the session authenticated and encrypted? Someone else on a shared network can take over a plaintext MQTT connection.
A device that can only reach its one broker, over TLS, on a path you control, is a much smaller target than its CVSS score suggests. A device that sends plaintext MQTT to a cloud endpoint over a flat network carries the full 9.8 risk.
How to limit exposure to the double free flaw
CVE-2026-91018 requires the attacker to be on the same network segment. On a well-built network, few systems share that segment. On a typical small plant, the segment with the embedded devices also holds the HMI, the engineering workstation, the historian, the vendor's cellular router, and the last laptop someone plugged in.
The control is the same as for the MQTT flaw, applied at the segment level. Decide which systems need to talk to each device, allow those systems, and block all other traffic before it reaches the device.
How to protect many devices you cannot patch
Most advisories cover one vendor's product. You can track one fix and plan one maintenance window. These two advisories cover every device built on a common library. The makers will release fixes at different speeds, and some will never release one.
You cannot manage this one device at a time while you wait. Apply one rule that works whatever firmware the device runs: the device talks to the systems that need it, on the protocols it needs, and nothing else can reach it. Enforce this rule on the network in front of the device. It needs no help from the device maker, and it also protects the devices whose makers never ship a fix.
Five steps to take this week
- Ask your vendors. For each embedded device family, ask the maker in writing whether the firmware includes lwIP, which version, whether the MQTT client is compiled in, and when a fixed release will ship. Keep the answers.
- List every device that uses MQTT. Note the broker each device connects to and whether the session uses TLS.
- Limit each MQTT device to its broker. Allow the device to reach its broker, and block all other outbound connections.
- Reduce the segments. For every embedded device, write down which systems need to talk to it. Allow only the systems on that list.
- Schedule firmware updates as they arrive. Track each vendor's answer against these two advisory numbers. For devices with no answer or no future release, steps three and four are the only protection.