New lwIP and OpenPLC Alerts Demand Different Repair Plans

An industrial security advisory can tell you where the software is broken. It cannot tell you whether the controller running your process has actually been repaired. That gap is the operational story in three notices CISA published on September 22: two flaws in lwIP components and a browser vulnerability in OpenPLC v3. The remediation paths diverge immediately. One organization may need a supplier to deliver corrected firmware. Another needs to leave an unsupported runtime behind.

The lwIP notices concern different components and different access conditions. CVE-2026-87121 affects the MQTT client application in versions 2.0.1 through 2.2.1, inclusive. CISA describes an out-of-bounds write that could permit code execution. Its assessment uses a network attack vector and does not require privileges or user interaction. That is a serious software exposure, but it is not evidence that every product containing lwIP includes the affected MQTT functionality or exposes it in the same way.

The other lwIP notice, CVE-2026-91018, concerns a double-free defect in the API, also covering versions 2.0.1 through 2.2.1. CISA identifies potential crashes, denial of service, memory corruption and possible code execution. Here, however, the assessment specifies adjacent-network access, and the notice explicitly says the vulnerability is not remotely exploitable. Collapsing the two notices into one claim about internet-accessible industrial equipment would erase a distinction operators need when deciding what to investigate first.

Those memory-management terms are worth translating. An out-of-bounds write places data outside the memory region intended to hold it. A double free tries to release the same memory allocation twice. MITRE describes how such mistakes can corrupt memory or disrupt execution. These are explanations of the weakness classes, not a reconstruction of the exact exploitation sequence in these newly published cases. A possible code-execution consequence should not become a claim that someone has demonstrated control of an operating factory.

The MQTT component adds a useful wrinkle to exposure analysis. The project's documentation describes a client connecting to a server, subscribing and receiving published data through callbacks. A client is not necessarily a public-facing service waiting for arbitrary internet connections. That does not make it safe by definition. It means the right question concerns the communication path and the parties supplying data, not simply whether a security team can find an open web page on the device.

For a product owner, the first useful evidence would be specific: the firmware build, the included lwIP component, whether that component is enabled and the connections it uses. A bill of materials can help establish component presence, but presence alone does not answer all those questions. Conversely, an incomplete inventory is not proof of absence. The proposed investigation should follow the affected function into the deployed product, rather than treating a match on the library name as a finished assessment.

CISA points to separate upstream fixes for the two lwIP issues. That is an important starting point, not confirmation that an installed device contains either correction. This publication has not independently tested those commits or verified a supplier's firmware package. A supplier should be asked to connect its delivered build to the relevant fix, including any backport. The useful answer is a traceable statement about a particular product and release, not a link to a repository someone else maintains.

This also explains why version numbers need interpretation. The affected ranges identify where to begin checking; they are not a substitute for evidence about a modified vendor build. An operator should ask whether a correction has been incorporated and how the supplier established that conclusion. If the supplier says the vulnerable function is absent, that answer should identify the configuration or build evidence supporting it. Both outcomes can resolve an investigation, but neither should rest on a reassuring adjective.

OpenPLC v3 presents a different problem. CISA's CVE-2026-88020 notice describes cross-site scripting in the runtime's web interface, involving input that is not properly encoded before use in a page. The agency describes potential access to session cookies and state-changing requests in an operator's context, with possible consequences for the PLC and the physical process it controls. Its assessment requires user interaction. The notice is not a claim that an unauthenticated network packet automatically takes over a plant.

The relevant trust boundary is the operator's browser. In the general weakness described by MITRE, content supplied by an untrusted party can be interpreted as active content within a trusted site's context. For an operational interface, the concern is what that context is allowed to do. That is why the article's distinction between a browser flaw and a control-system consequence matters: the browser is part of the authority chain, not a decorative screen sitting outside the system.

The vendor's recommended destination, as reported by CISA, is OpenPLC v4. Version 3 is already end of life and will not receive patches, bug fixes or security updates. The project's own v3 README separately confirms its retired status. September 22 is the date of the advisory, not the date the project suddenly decided to retire that version. Waiting for a v3 security release would therefore be planning around a maintenance path the project says no longer exists.

Migration is also more substantial than swapping a version label. The v4 repository describes a headless runtime managed through the OpenPLC Editor v4 desktop application over a REST API, or through Autonomy Edge Cloud. Its documentation explicitly distinguishes this from the old browser interface. It describes an HTTPS API server and a separate runtime core. These are the project's architectural statements, not an independent certification of security or a guarantee that an existing installation can move without engineering work.

For a team considering the move, the acceptance test should cover the actual program, its input and output relationships, operator access and the workflow used to deploy changes. Those are recommended checks, not reported incompatibilities in v4. The browser interface disappearing changes where a person interacts with the system; it does not remove the need to control who can send commands. The migration should produce a supported operating arrangement, not merely a screenshot showing that a newer process has started.

A reasonable counterargument is that maintenance itself can introduce risk. Replacing runtime software or firmware during an active process is not automatically the safer action at every instant. CISA's notices recommend impact analysis before defensive changes, alongside measures to limit network exposure and separate control systems from business networks. The practical response is to define a controlled change window and temporary restrictions appropriate to the installation. Neither indefinite delay nor an untested emergency update deserves to masquerade as operational discipline.

Temporary restrictions and a permanent correction should remain separate records. Reducing access may narrow a reachable path while a supplier prepares an update or a team validates migration. It does not rewrite the vulnerable software. A useful status report would state what remains installed, what access has been restricted, who owns the remaining work and what evidence will close it. Otherwise a temporary workaround can quietly become the permanent architecture because the dashboard stopped looking urgent.

That dashboard should not rank everything by severity alone. FIRST, which maintains CVSS, explicitly distinguishes vulnerability severity from a comprehensive assessment of risk. The cases here make the reason concrete: one assessment has a network vector, another requires adjacent access, and the browser case requires user interaction. Their actual importance to a particular installation also depends on what is present, what is reachable and what the affected system is authorized to do. A single sortable score cannot supply those missing facts.

Consider two hypothetical inventories. In one, a library name appears in a supplier record but the affected application is not included. In another, an unsupported runtime is actively used through an operator interface. The same investigation process should not assign them identical remediation work simply because both appeared in an industrial advisory feed. These are illustrative cases, not findings about any customer. They show why an accountable owner needs to turn a public notice into an installation-specific decision.

The evidence does not support claims of an ongoing attack campaign. All three CISA notices say no known public exploitation specifically targeting the vulnerabilities had been reported to the agency. That wording has limits: it describes what had been reported, not a guarantee about every private incident or every future attempt. This report is based on the advisories and upstream documentation. We found no independent incident reporting establishing exploitation of these particular disclosures, and we have not reproduced the vulnerabilities.

Nor do the reviewed records establish a population of affected factories, an aggregate financial loss or a confirmed physical failure. It would be easy to borrow the language of industrial catastrophe and attach it to a list of software weaknesses. It would also be bad reporting. The supported conclusion is narrower and still consequential: specific software components have disclosed flaws, their access conditions differ, and the supported remediation route is not the same across the products.

For builders selling connected equipment, that distinction should influence the product promise. A customer should be able to ask who tracks embedded components, who decides whether a disclosure applies and who delivers the resulting maintenance release. For an open-source runtime, the equivalent question is whether the deployment has an owner for lifecycle changes. These are proposed procurement requirements, not claims that the projects owe every downstream integrator a customized update. Responsibility must be explicit somewhere in the chain.

The strongest next move is a short, evidence-backed remediation record for each relevant installation. Name the component and deployed build, document the applicable access path, identify the correction or migration route, and assign a person who can authorize and verify the change. Keep the supporting supplier or project evidence with that record. Today's notices are useful because they identify concrete failures. The work is complete only when the organization can explain what those failures mean for its own equipment and what it actually changed.

LaunchPad positionTrace the relevant flaw into the deployed build, then verify a delivered correction or a supported runtime migration.