Four of CISA's nine new ICS advisories are about borrowed code, and the lwIP fixes have no release

Nine advisories, four of them about code the named vendor did not write

CISA published nine industrial control system advisories on 22 September 2026, numbered ICSA-26-265-01 to ICSA-26-265-09. Read them as a set and the first useful number is not a severity score. It is four. Four of the nine describe a defect in software that the vendor on the front of the advisory did not write: two in lwIP, the small TCP/IP stack that ships inside other people's devices, one in the Linux kernel, and one in Keycloak, the identity server that sits under Siemens Industrial Edge Management. Only five are about code the named vendor owns end to end.

The second number is six. Six of the nine are not new. They are CISA republications of Siemens ProductCERT advisories that Siemens published on 8 September 2026, except for the WTV advisory, which Siemens published on 16 September. The revision history on each CISA page says so plainly: revision 1 is the Siemens publication date, revision 2 is dated 22 September and summarised as the initial CISA republication. Only three advisories in this batch are original CISA work: the two lwIP advisories and the OpenPLC one.

What those two counts do not establish is anything about risk in your plant. They do not tell you that any of these products is present on your network, that any instance is reachable, or that anyone is attacking them. Eight of the nine carry no evidence of exploitation at all. The ninth is a different matter, and it is not the one with the highest score.

What the nine advisories actually say

Every figure below is taken from the CISA advisory page for that advisory, cross-checked against the Siemens ProductCERT CSAF record where one exists. The scores are CVSS v3.1 base scores. Where CISA also published a v4.0 score, it is noted in the factcheck rather than the table, because the two scales are not comparable and mixing them in one column would mislead.

The 22 September 2026 batch, from the CISA advisory pages ICSA-26-265-01 to -09 and the matching Siemens CSAF records

Advisory and product	CVSS v3.1	How it is reached	Fix on the record
-01 lwIP MQTT client application, 2.0.1 to 2.2.1	9.8	Network, no credentials, no user action	A commit on the lwIP master branch. No release.
-02 lwIP, 2.0.1 to 2.2.1	8.8	Adjacent network. CISA says not exploitable remotely.	A commit on the lwIP master branch. No release.
-03 Siemens Siveillance Control and Control Pro	9.0	Adjacent network, with a low privileged account	Four fixed versions, all published by Siemens
-04 Siemens SIPLUS and SIMATIC products	7.8	Local, with a low privileged account	60 of 67 products fixed, 7 with none available
-05 Siemens Desigo CC family V6 and V7	8.2	Local, and a user has to open the file	None. Mitigation only. V8 and V9 not affected.
-06 Siemens Industrial Edge Management	9.1	Network, no credentials, no user action	Three fixed versions. Cloud fixed by Siemens on 2 September.
-07 Siemens SIMOVE Fleetmanager and SIPLANT	8.6	Network, no credentials, no user action	Five fixed versions. Three SIPLANT lines go through support.
-08 Siemens WTV676 and WTV776 web interface	6.5	Network, no credentials, no user action	V3.94 and V4.17
-09 OpenPLC Runtime v3	6.1	Network, but a user has to follow the link	None for v3. The vendor says move to v4.

The sector labels in the next table are CISA's own critical infrastructure categories, not the UK's. They are a rough guide to where a product turns up, not a determination that your organisation is in scope of anything. A UK operator of essential services is defined by the thresholds in the NIS Regulations 2018, not by an American sector tag on an advisory page.

Sectors and exploitation status, from the CISA advisory pages and the CISA-ADP SSVC decisions recorded in NVD

Advisory	Sectors named by CISA	Exploitation status on the record
-01 and -02 lwIP	Chemical, communications, critical manufacturing, energy, financial services, healthcare, transport, water	CISA: no known public exploitation reported
-03 Siveillance Control	Critical manufacturing, communications, commercial facilities	SSVC decision of none, recorded 8 September 2026
-04 SIPLUS and SIMATIC	Critical manufacturing, energy, water, chemical, food and agriculture, commercial facilities	SSVC decision of active, recorded 29 April 2026
-05 Desigo CC family	Critical manufacturing, commercial facilities	SSVC decision of none, recorded 14 September 2026
-06 Industrial Edge Management	Critical manufacturing	SSVC decision of none, recorded 20 August 2026
-07 SIMOVE Fleetmanager and SIPLANT	Critical manufacturing	SSVC decision of none, recorded 9 September 2026
-08 WTV676 and WTV776	Energy	SSVC decision of none, recorded 16 September 2026
-09 OpenPLC Runtime v3	Critical manufacturing, energy, transport, water	CISA: no known public exploitation reported

Three of those CVEs are not in the National Vulnerability Database at all as of 22 September 2026. Queries for CVE-2026-87121, CVE-2026-91018 and CVE-2026-88020 return no records, so the only published scores for the lwIP and OpenPLC issues are the ones on the CISA pages. If your vulnerability management tooling waits for an NVD record before it raises a ticket, those three will not appear.

The lwIP problem: a fix that is not a release

lwIP is a lightweight TCP/IP stack designed, in the project's own words, for embedded systems with tens of kilobytes of free RAM. It is not a product you buy. It is a component that silicon vendors, module makers and device builders compile into firmware, usually years before the device reaches a plant. The two advisories name lwIP as the vendor and lwIP as the equipment, which is accurate and almost useless operationally: nobody has an asset register entry that says lwIP.

That is why the real exposure is wider than the two advisories look. The affected range is version 2.0.1 to 2.2.1, which is every release the project has tagged since 2.0.1, roughly a decade of firmware. Anything built on a vendor software development kit that bundles lwIP, and that uses the MQTT client application or the 6LoWPAN path, is potentially in scope. The advisories cannot tell you which of your devices those are, and neither can CISA. Only the device maker can, and the question has to be asked device by device.

Now the part that changes what "fix available" means. CISA's remediation for both lwIP advisories is a git commit identifier. For ICSA-26-265-01 that is f89407ea711879c04d91c92b35d67be78bbaf0f1. Fetch that commit from the project's own repository and it turns out to be a one line change to test/unit/mqtt/test_mqtt.c, described by its author as fixing a wrong memset in the previous test commit. The substantive change is its parent, 68b2c119, titled "mqtt: fix rx_buffer overrun", which touches src/apps/mqtt/mqtt.c and its unit test. Both were committed on 31 August 2026 by the same maintainer.

The commit cited for ICSA-26-265-02, f873b629, is titled "lowpan6: fix FRAG1 decompression failure and add unit test" and changes src/netif/lowpan6.c. That is the 6LoWPAN adaptation layer, which carries IPv6 over low power radio links. It explains the adjacent network vector in the score, and it means the advisory's description of the affected component as the lwIP API is broader than the code that actually changed.

This is the friendly-name fallacy in its purest form. "Fix available" on an advisory page reads like something an asset owner can install. For lwIP it means a patch exists in someone else's source tree, upstream of your supplier, upstream of your device, and the number of hands it has to pass through before it reaches a panel on your plant floor is not stated anywhere in the advisory. The same applies in reverse to the Keycloak flaw in ICSA-26-265-06: Red Hat published CVE-2026-18963 on 18 August 2026, Siemens mitigated its own cloud service with firewall rules on 26 August and fixed it on 2 September, and customers running Industrial Edge Management themselves had to wait for the versions listed in SSA-503852.

What these advisories establish, and what they do not

An advisory is a statement about code, not about your plant. The gap between the two is where most wasted OT remediation effort lives. Set out plainly, for this batch:

Claims tested against the text of the nine advisories and the six Siemens CSAF records

Question	Stated on the record	Not stated
Is a fix available for lwIP?	A commit identifier in the project repository	Any release, any date for one, any device firmware containing it
Which devices embed lwIP?	Nothing beyond the version range 2.0.1 to 2.2.1	Any product, vendor or model list. CISA names lwIP as the equipment.
Is Copy Fail being exploited?	CISA KEV entry since 1 May 2026, SSVC decision of active	Any observation of exploitation against Siemens products specifically
Are Desigo CC users protected?	V8 and V9 are listed as not affected	Any fix for V6 and V7 clients. Siemens records none available.
Can SIPLANT 1.7, 2.2 and 3.0 be patched?	Contact Siemens customer support	A version number, a date, or whether a fix exists for those lines
Do the CISA sector labels apply in the UK?	CISA lists US critical infrastructure sectors per advisory	Anything about UK NIS scope or operator of essential services status

Prioritisation: exposure first, then the score

The temptation with a nine advisory batch is to sort by CVSS and work downwards. That produces the wrong order here, twice over. The 9.8 at the top of the list is in a component you may not be able to patch at all this quarter. The 7.8 near the bottom is the only one with evidence of real world use. CVSS measures the properties of a flaw, not your exposure to it, and the base score deliberately excludes anything about your environment.

A better order is to rank by how an attacker reaches the flaw, then within each band by severity, then override for anything with confirmed exploitation. That is what the matrix below does with this batch.

Three practical consequences fall out of that order. First, the Industrial Edge Management flaw is the one to check tonight if you run it: unauthenticated, network reachable, an account takeover, with a straightforward containment measure in the vendor advisory that does not require a maintenance window, namely removing direct internet access to the management instance. Second, Copy Fail jumps its row, because confirmed exploitation of a local privilege escalation still matters the moment anyone has a shell on a panel, and Siemens has no fix at all for seven of the 67 affected products, including the SIMATIC S7-1500 TM MFP and the IoT2050 Advanced. Third, the lwIP pair moves to a supplier question rather than a patching task, because there is nothing to install.

Note the honest limits of the matrix. It places advisories by the vector string, which is an assessment of the flaw in a default configuration. A Siveillance Control server exposed through a jump host, or a Desigo CC client used by an engineer who opens files from outside the organisation, moves in practice. Use the matrix to decide what to look at first, then let your own architecture move things.

The UK position: an alert four weeks old and a duty already in force

UK operators did not need this batch to know the direction of travel. On 27 August 2026 the NCSC published an advisory on disruptive activity against internet exposed systems and edge devices, saying it had "seen increased targeting of operational technology (OT) systems across multiple sectors globally, including in the UK", carried out by a range of actors and resulting in some limited real world disruption. Its second point is the one that matters for a batch like this: "Organisations should not assume that their OT is inaccessible from the internet without verifying it", because exposure arises through misconfiguration, legacy connections and unmanaged assets.

The NCSC's eight recommended actions in that advisory line up almost exactly with the containment measures in these nine advisories: build a definitive view of OT assets and keep controllers off the public internet, replace default credentials and use multi-factor authentication where supported, harden the OT boundary and keep the devices that provide external connectivity in vendor support, adopt secure versions of industrial protocols, log and monitor all connectivity, prevent remote programming during normal operations, segment OT from management and business networks, and keep tested, ransomware resistant backups. Every one of those reduces the impact of at least one advisory in this batch without waiting for a vendor.

For an operator of essential services, the legal frame is already in place and does not depend on the Cyber Security and Resilience Bill, which as of 22 September 2026 is at report stage in the House of Lords with its next sitting listed for 26 October 2026 and is not yet an Act. Regulation 10 of the Network and Information Systems Regulations 2018 requires appropriate and proportionate technical and organisational measures to manage risk, having regard to the state of the art, and requires operators to have regard to their competent authority's guidance. Regulation 11 requires notification of any incident with a significant impact on continuity of the essential service, in writing, without undue delay and in any event no later than 72 hours after the operator becomes aware of it.

The NCSC's Cyber Assessment Framework version 4.0 is how most competent authorities test regulation 10. Contributing outcome B4.d is blunt about the standard: "You manage known vulnerabilities in network and information systems to prevent adverse impact on your essential function(s)." That wording is why an unpatchable flaw is not an excuse. The framework expects temporary mitigations for unsupported systems while migration is pursued, which is precisely the position an operator is in with Desigo CC V6 clients, OpenPLC Runtime v3 and the seven SIMATIC products with no Copy Fail fix. Doing nothing because the vendor has shipped nothing is the one response that will not survive an audit.

One more UK specific point. These are US advisories, and they are the product of a co-ordination process in which Siemens ProductCERT reports its own findings and CISA republishes them verbatim. CISA says so itself in the conversion disclaimer on the republished pages, stating that it is not responsible for the editorial or technical accuracy of republished advisories. The vendor's incentive to describe a flaw in the least alarming accurate terms is normal commercial behaviour, not misconduct, but it does mean the primary source for a Siemens issue is the Siemens advisory, and the CSAF machine readable version carries detail the human readable summary flattens, including which individual products have no fix.

The order worth working in

The question that exposes the gap

Five of these nine advisories hand a UK operator a version number and nothing more complicated than a change window: Siveillance Control, Industrial Edge Management, SIMOVE Fleetmanager, the WTV devices, and most of the SIMATIC and SIPLUS list. The other four ask for something harder. Two lwIP advisories are a supplier question with no release behind them. OpenPLC Runtime v3 is a migration, because the vendor has declared version 3 end of life. Desigo CC V6 and V7 clients get a mitigation and no fix at all, and so do seven of the 67 products in the Copy Fail advisory. None of those four is a patching failure. They are the ordinary consequence of building control systems from other people's software and then asking, years later, what is inside.

So the question is not which of these nine you will patch. It is this: if the next lwIP advisory arrives tomorrow, how many of your suppliers could tell you within a week whether their firmware contains it, and how many contracts you have signed give you the right to ask?