Six defects in a shared industrial data component, and the oldest installations get no patch of their own.

On 15 October, CISA, the United States cyber defence agency, published an advisory about a piece of software almost no plant manager has ever bought, and that a good number of them are probably running. It lists six separate defects in it. The software is distributed as an open source project, and the correction comes as a new release of that project's source code. That is the shape of a building block rather than a product: software like this reaches a plant inside something else, compiled in by whoever sold the control system, the gateway or the data collector.

What the six allow runs from awkward to serious. At one end, an attacker who can reach the server over the network can stop it answering every client connected to it. In the middle, they can read off who is logged in and how. At the far end, they can recover a user's password and come back as that user. The sectors named are the usual ones: energy, water and wastewater, chemicals and manufacturing, deployed worldwide.

Here is the part worth forwarding to whoever owns the vendor relationships. A fix exists and is free, and hardly any affected site can install it, because it is not their software to rebuild. For installations on the oldest affected branch there is no corrected release on that branch at all, so the route out is a move onto the current line. That is a project, not a patch.

What a stalled server costs on plant

The software is Eclipse Milo, and the defects are all in its behaviour as an OPC UA server, OPC UA being the common language industrial kit uses to pass readings and commands between systems from different makers. A server built on it is what sits on the end of the line when a control room screen asks a pump house for a level, or when a collector gathers a shift of measurements for the engineers who look at trends afterwards.

Two of the six go at that service directly and neither needs a password. The first lets a remote client send part of a message, hang up, and do it again, in a loop, until the memory the server keeps for traffic is gone and the server can die. For a mine running its own substations, or a utility pulling telemetry from pump stations spread across a district, that is the moment readings stop arriving and commands stop landing. It looks like a supervisor on the phone to a site because the screen that normally shows it has gone blank, and a call-out nobody had in the plan.

The second is quieter and, for a maintenance team, harder to read. By sending one sufficiently tangled subscription request, an unauthenticated client can use up the server's whole allowance for monitored items, the individual tags a client signs up to for live updates. Everything already subscribed keeps flowing and the rest of the server stays healthy, so the plant looks normal. What fails is anything new, for every client, until the server is restarted. An engineer commissioning a point, or a packaged dashboard trying to rebuild its subscriptions after a network blip, gets nothing back from a server that is plainly up.

Three of the remaining four turn on identity. One lets a client pair a forbidden request with a permitted one and have both carried out, because the batch is checked and then the original batch is dispatched. Another applies where permissions are organised by role: a configuration copy loses the role mapping, every session arrives with no role attached, the permission check is skipped, and where anonymous connections are accepted an anonymous client can call protected methods or delete protected data. A third opens the server's own diagnostics to a client that should see none of it: usernames, login history, how each session authenticated, what security it negotiated.

The fourth carries the highest score in the advisory and the narrowest conditions. An attacker who can already watch the traffic, and who has captured a login protected by one of the older encryption options the standard still permits, can tell one kind of decryption failure from another by the errors coming back, work the password out by repetition, and then sign in as that user. It takes a position on the network. Where someone has that position, the outcome is a real account in the wrong hands, which from the server's side is indistinguishable from ordinary use.

The questions to put to a supplier

None of this is answerable from the plant floor, because the thing to find is a component inside other people's software rather than a product on an asset register. Two version ranges are affected, and which defects apply depends on which range a given installation falls into. So the first question is which control room applications, protocol gateways and edge devices on site contain this component, and at what version.

That question has one addressee, and it is narrow enough to answer in writing: does this product embed it, at which version, and when will a rebuilt release be available? A supplier who cannot answer the first part has said something useful about the state of their own inventory.

For anything found on the oldest affected branch, the question changes. There is no fixed release on that branch, so the path the Eclipse Foundation points to is the current line, and for an embedded component that is the supplier's migration rather than a site's patching window. The thing worth asking is when that work is scheduled, and what else in the product it changes.

Two configuration questions are worth putting to whoever commissioned the system, because several of these defects only bite in particular setups. Whether the server accepts anonymous connections, since that is the precondition for the role permission failure. And whether an endpoint with no signing or encryption is reachable, since that is what makes the diagnostics exposure trivial to reach. The advisory closes with the agency's usual segmentation and remote access guidance.

The technical record

CISA advisory ICSA-26-288-01, released 15 October 2026, revision 1, initial publication. Vendor: Eclipse Foundation. Equipment: Eclipse Milo. Headline CVSS v3 score on the advisory: 8.2. Sectors listed: chemical, critical manufacturing, energy, water and wastewater. Deployment: worldwide. Vendor headquarters: Belgium.

Affected, both ranges inclusive and both marked known_affected. Eclipse Milo 0.6.0 through 1.1.4: CVE-2026-63252, CVE-2026-63248, CVE-2026-60007. Eclipse Milo 1.0.0 through 1.1.4: CVE-2026-62927, CVE-2026-58080, CVE-2026-61387.

Remediation, identical on all six entries. Upgrade to Eclipse Milo 1.1.5, as recommended by the Eclipse Foundation. No 0.6.x release carries the fixes, so sites on 0.6.x are directed to migrate to 1.1.5 or later.

The six, with CVSS v3.1 and v4.0 base scores:

• CVE-2026-60007. 7.4, and 9.1 critical under v4.0, the highest in the advisory. CWE-204. Error responses differ according to whether RSA PKCS#1 v1.5 padding was invalid or authentication failed some other way. An on-path attacker holding a captured username token encrypted under Basic128Rsa15 can therefore replay ActivateSession requests, unauthenticated, as an oracle: the pattern of errors yields the password, and the password yields the account.
• CVE-2026-58080. 8.2, and 8.8 under v4.0. CWE-862. The defect is in OpcUaServerConfig.copy(), which loses a configured RoleMapper. Servers that rely on role permissions and build their running configuration that way hand out sessions carrying no role identifiers at all, so the access controller used by default finds nothing to check role permissions against. Where anonymous sessions are allowed, role permission metadata becomes readable and protected methods and nodes become reachable by an anonymous client.
• CVE-2026-63252. 7.5, and 8.7 under v4.0. CWE-401. Partial message chunks held by the UASC server transport handlers are not freed when a channel drops. An unauthenticated remote client can send incomplete chunks and disconnect in a loop until pooled direct memory is spent, which can terminate the server.
• CVE-2026-62927. 7.5, and 8.7 under v4.0. CWE-863. In the Call service, authorisation is calculated over a batch and then the original batch, mixed as submitted, goes to the address-space handlers. A low-privileged or anonymous client can pair a denied method with an allowed one and have both run.
• CVE-2026-63248. 6.5, and 6.9 under v4.0. CWE-862. Diagnostics nodes carry no access check. An anonymous client on an endpoint with no security (None/None) and no certificate can switch diagnostics on; a client holding a trusted application certificate, connected under SignAndEncrypt, can then read the security diagnostics of other live sessions, covering usernames, login history, the authentication mechanism each used, the security mode and policy in force, and client public certificates.
• CVE-2026-61387. 5.3, and 6.9 under v4.0. CWE-772. Quota accounting for monitored items is not exception-safe: when item creation raises an unchecked error, the server-wide reservation stays taken. A sufficiently nested PubSub ExtensionObject inside a CreateMonitoredItems event filter overflows the stack while decoding, which supplies that error, and an unauthenticated remote client can repeat it until the global quota is spent. Nothing already subscribed stops and other server functions continue; new monitored items fail for every client until a restart.

The defects were reported to the agency by an outside researcher, and the advisory stands at its first revision with nothing added since. That order of events is the useful part. This became public because somebody went looking rather than because a plant went down, which leaves a stretch of time that is only worth having if the inventory question gets asked inside it. No agency can publish a list of which products embed which open source components. That list sits with the companies that sold the software, and they produce it when somebody asks them to.