A defect in shared networking code can knock small control devices offline, and only your supplier can fix it.

CISA, the United States cyber security agency, published an advisory on 22 September about lwIP, a small piece of free networking software that lets low-powered equipment talk over a network. It is not something an operator buys. It is code that device makers drop into sensors, controllers, meters, gateways and radios, which is why the agency lists eight critical infrastructure sectors as exposed, energy, water and wastewater and critical manufacturing among them, and records the deployment area as worldwide.

The defect is a memory handling error. The agency's summary of what it buys an attacker runs from a crashed device, through corrupted memory, to code of the attacker's choosing running on the equipment, and both of the severity ratings it publishes sit in the high band.

The awkward part is who can act on it. The correction exists as a single change in the project's own source code, with no new numbered release behind it. For anyone running plant, that means there is nothing to install. The fix reaches site only when the company that built the device rebuilds its firmware and ships it, and then only when a maintenance window allows it on.

So this is a supplier conversation rather than an engineering one, and the person who needs it is whoever holds the asset register and the firmware records.

Who else is on the wire

The access path matters more here than the rating does. The agency records that the flaw cannot be reached over the internet: whatever sends the malicious traffic has to already be on the same local network as the device.

On a plant network, that is a lower bar than it sounds. A contractor's laptop on the maintenance segment, an operator station that has already been taken, a shared radio path out to an outstation: all of them sit on the same side of the fence as the equipment they serve. The practical reading is that the question was never whether the device faces the internet. It is who else is on the wire with it.

What an attacker gets is the device, and equipment of this class is usually a link rather than an endpoint. A crash on that link is the moment telemetry from an outstation stops arriving and commands stop landing. On a mine carrying its own reticulation, that is a supervisor working a phone instead of the mimic, the control room's live diagram of the plant, and a call-out on gear nobody had put in the schedule. The repeat is what hurts: a device that can be crashed once can be crashed again on the attacker's timing, which turns an outage into a tempo.

A crash is also the floor, not the ceiling. Where memory corruption ends in attacker code on the device, a rebooted unit coming back green is no longer evidence that the problem has gone.

The questions this leaves with a buyer

None of this tells an operator whether they are affected, and that is the honest shape of the document. It names the library and the affected range. It names not one device that ships it.

The question worth putting to whoever holds the maintenance record is which network-connected devices on site run somebody else's networking code inside them, and whether each supplier will put that answer in writing. Few asset registers carry the software bill of materials that would answer it without asking.

For every supplier that says yes, the next question is when a build carrying the upstream change will exist, and whether that is a scheduled release or something that happens if a customer pushes. The date is the whole of the risk here, because the defect is public and the correction is public together.

There is a question for the engineers who drew the network too, and it is not about the internet boundary. It is which of these devices share a segment with anything a person can log in to, and what would reach them from there.

And one for procurement, better asked now than during an incident: what the contract says about third-party components, and what time the supplier is committing to for passing an upstream fix through to a signed build.

The technical record

• Advisory: CISA ICSA-26-265-02, released 22 September 2026, revision 1, initial publication. Identifier CVE-2026-91018, a double free, CWE-415.
• Affected: lwIP API >=2.0.1 through <=2.2.1, status known_affected. No downstream products or devices are listed.
• Metrics: CVSS v3.1 base 8.8, high, CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. CVSS v4.0 base 8.7, high, CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The adjacent access vector in both is the constraint described above.
• Impact as stated: crash, denial of service, memory corruption, or code execution on the affected system.
• Exploitability: not exploitable remotely, and no public exploitation targeting it had been reported to the agency at publication.
• Remediation: update from the project repository at https://cgit.git.savannah.gnu.org/cgit/lwip.git, fix commit f873b6295933e4149a2132adf3e9a2d2a676a5ec. No fixed version number is given.
• Context: eight sectors listed, deployment worldwide, project headquarters Sweden. Reported to CISA by Tetrel Security.

The advisory is dated and the fix commit is dated. The distance between that commit and a signed firmware build sitting on plant is the one figure no document publishes, and it is the figure that decides whether any of this matters on a given site. The only way to learn it is to ask the people who ship the firmware, and their answer is worth writing down next to the asset it covers.