CISA Flags Six Eclipse Milo OPC UA Flaws: Upgrade Java Industrial Systems to 1.1.5+

Because Eclipse Milo provides the underlying protocol stack, serialization, security handling, and client/server Software Development Kits (SDKs) for JVM-based industrial projects, a vulnerability in Milo is rarely just a standalone application bug. Instead, it is a supply-chain problem for engineering workstations, Windows- and Linux-hosted supervisory gateways, human-machine interfaces (HMIs), and industrial middleware across the chemical, critical manufacturing, energy, and water and wastewater sectors. If left unpatched, the bugs exposed in this advisory could allow attackers to bypass method and role authorization, extract user passwords via a cryptographic padding oracle, harvest active session diagnostics, or crash OPC UA servers through memory and quota exhaustion.

Here is a complete breakdown of the six CVEs, how they affect deployed Java and OPC UA environments, and what software developers and IT/OT security teams need to know when planning an upgrade to Eclipse Milo 1.1.5 or newer.

What Is Eclipse Milo and Why Does It Matter to Enterprise IT?​

To understand why a Java library advisory ends up on the desk of infrastructure and Windows system administrators, it helps to look at how modern factory floors and utility networks communicate. OPC UA is the foundational interoperability standard for the Industrial Internet of Things (IIoT), moving sensor telemetry, alarms, and control commands between programmable logic controllers (PLCs) and enterprise-level historians or ERP bridges.

According to Eclipse Foundation project documentation and its GitHub repository, Eclipse Milo is an open-source implementation targeting OPC UA specification version 1.05. Built for Java 17 and later runtimes (including JDK 21 and JDK 24), Milo is distributed through Maven Central via artifacts such as milo-sdk-client and milo-sdk-server. Because Java runs everywhere, Milo frequently powers cross-platform SCADA software, custom Windows Server data collectors, and edge gateways that bridge operational technology (OT) networks with corporate IT infrastructure.

When vulnerabilities surface in Milo’s server SDK or transport handlers, any vendor platform or internal enterprise tool that embeds affected versions (0.6.0 through 1.1.4) inherits those weaknesses.

Summary of Affected Versions and CVE Ratings​

CISA divides the affected releases into two distinct version brackets, though both branches share the exact same remediation floor: Eclipse Milo 1.1.5. Notably, CISA warns that the older 0.6.x branch will not receive backported security patches; organizations still running 0.6.x must migrate to the 1.1.5 or later release line.

Summary Takeaway: Three vulnerabilities reach back to version 0.6.0, while the other three were introduced in the 1.0.0 release line. While CISA's top-level summary assigns an overall vendor CVSS v3 score of 8.2, individual CVSS v4.0 scores climb as high as 9.1 Critical.

Deep Dive: Breaking Down the Six Eclipse Milo Flaws​

1. Authorization Bypass and Access Control Failures (CVE-2026-58080, CVE-2026-62927, CVE-2026-63248)​

Three of the six flaws undermine how an OPC UA server verifies who is allowed to do what. In industrial environments where "read-only" observer accounts or anonymous monitoring sessions coexist with high-privilege control methods, authorization bugs are particularly dangerous.

• Lost Role Mapping on Config Copy (CVE-2026-58080): Carrying the highest CVSS v3.1 score in the advisory (8.2 High, CVSS v4.0 8.8 High), this flaw affects Milo 1.0.0 through 1.1.4. When a developer or server application uses OpcUaServerConfig.copy() to construct its active runtime configuration, the method fails to preserve a configured RoleMapper. Consequently, if a server relies on role permissions and passes its configuration through copy(), incoming sessions are assigned no role IDs at all. Even worse, the default access controller responds to the missing role IDs by skipping role-permission checks entirely. On servers that allow anonymous sessions, an unauthenticated user can suddenly read role-permission metadata, execute protected methods, or delete protected address-space nodes.
• Batched Method Call Smuggling (CVE-2026-62927): Also affecting versions 1.0.0 through 1.1.4 (CVSS v3.1 7.5, CVSS v4.0 8.7), this bug is a classic time-of-check to time-of-use (TOCTOU) style logic error in batch processing. In OPC UA, a client can bundle multiple method invocations into a single Call service request. Milo's Call service properly calculates authorization for the items in the batch, but then mistakenly dispatches the original, unfiltered mixed batch to the address-space handlers. By piggybacking a forbidden method alongside a permitted one in the same batch, an anonymous or low-privileged client can trick the server into executing the denied method.
• Exposed Server and Session Diagnostics (CVE-2026-63248): Affecting versions 0.6.0 through 1.1.4 (CVSS v3.1 6.5, CVSS v4.0 6.9), Milo’s OPC UA server diagnostics nodes fail to enforce access authorization. This creates a two-stage exposure. First, an anonymous client connecting over an unsecured None/None endpoint without a certificate can switch server diagnostics on. Second, if a client connects over a SignAndEncrypt endpoint using a trusted client application certificate, it can read the security diagnostics nodes for other active sessions on the server—exposing active usernames, login histories, authentication mechanisms, security modes and policies, and public client certificates.

2. Cryptographic Credential Recovery: The Padding Oracle (CVE-2026-60007)​

For security architects, CVE-2026-60007 (affecting 0.6.0 through 1.1.4) is arguably the most insidious bug in the advisory, earning a 9.1 Critical rating under CVSS v4.0 (and 7.4 High under CVSS v3.1 due to attack complexity).

When an OPC UA client authenticates using a username and password encrypted under the legacy Basic128Rsa15 algorithm, Milo’s username-token processing returns distinguishable error responses depending on whether the RSA PKCS#1 v1.5 padding was invalid or whether authentication failed for another reason (such as a bad password).

Why does a slightly different error message matter? In cryptography, this is the textbook recipe for a Bleichenbacher padding oracle attack. If an on-path attacker captures a legitimate user's Basic128Rsa15-encrypted username token off the wire, they do not need to crack the RSA key. Instead, they can fire repeated, unauthenticated ActivateSession requests at the Milo server, watching how the server responds to mutated ciphertexts. Using those distinguishable error responses as a guide, the attacker can mathematically reconstruct the plaintext password byte by byte and subsequently log in as the legitimate user.

3. Unauthenticated Denial of Service (CVE-2026-63252, CVE-2026-61387)​

Availability is sacred in operational technology, and the remaining two vulnerabilities allow unauthenticated remote clients to degrade or halt server operations without needing a valid login.

• Pooled Direct Memory Exhaustion (CVE-2026-63252): Affecting 0.6.0 through 1.1.4 (CVSS v3.1 7.5, CVSS v4.0 8.7), this flaw resides in the OPC UA Secure Conversation (UASC) server transport handlers. When a client sends partial message chunks and abruptly disconnects before completing the message, the transport handler fails to release the retained memory buffers. Because high-performance Java networking stacks (like Netty, which Milo uses under the hood) rely on pooled direct memory outside the normal JVM heap, an unauthenticated attacker can repeatedly transmit incomplete chunks and drop the connection until pooled direct memory is completely exhausted—potentially crashing the server process.
• Monitored-Item Quota Exhaustion (CVE-2026-61387): Affecting 1.0.0 through 1.1.4 (CVSS v3.1 5.3, CVSS v4.0 6.9), this bug combines an unchecked recursion error with leaky resource accounting. When a client requests new monitored items, Milo reserves slots against a finite server-global monitored-item quota. However, the quota accounting is not exception-safe: if item creation crashes with an unchecked error, the reservation is never returned to the pool. An attacker can intentionally trigger an unchecked StackOverflowError during decoding by sending deeply nested PubSub ExtensionObjects inside a CreateMonitoredItems event filter. By repeating this until the global counter hits its ceiling, an unauthenticated client can block all clients from creating new monitored items until the server is restarted (though CISA notes that existing monitored items and other server functions continue running).

Summary Takeaway: Whether an attacker wants to crash a gateway via direct memory leaks (CVE-2026-63252), lock out new telemetry subscriptions (CVE-2026-61387), decrypt captured credentials (CVE-2026-60007), or bypass role and method controls (CVE-2026-58080, CVE-2026-62927), the flaws span the full triad of confidentiality, integrity, and availability.

Remediation, Version Landscape, and Developer Guidance​

How should development teams and system administrators respond? CISA and the Eclipse Foundation recommend upgrading to Eclipse Milo 1.1.5 or later.

A review of the official eclipse-milo/milo GitHub repository shows that the project maintainers have remained active beyond the initial 1.1.5 remediation floor:

• Version 1.1.5 serves as the minimum security baseline that resolves all six CVEs reported in CISA’s advisory.
• Versions 1.1.6 (released July 2026), 1.1.7 (September 2026), and 1.1.8 (October 6, 2026) have since been published to Maven Central. Version 1.1.8 is marked as the latest stable release in the 1.1.x maintenance branch, adding OSGi manifest fixes for shaded Guava classes alongside updated dependencies such as Netty 4.1.138.Final and Bouncy Castle 1.86.
• Version 1.2.0-RC1 (released October 12, 2026) is currently in pre-release testing with new features like ECC security policies and Reverse Connect, though its release notes warn of source and binary compatibility breaks.

For production patching today, staying on the latest stable 1.1.x release (1.1.5 through 1.1.8) offers the cleanest remediation path for existing 1.0.x and 1.1.x deployments.

Step-by-Step Action Plan for IT, OT, and DevOps Teams​

1. Audit Your Java Dependency Trees and Installed Gateways:
   Because Milo is an SDK and stack library (org.eclipse.milo), it will rarely show up in Windows Add/Remove Programs. Software teams should inspect their pom.xml or Gradle build files—or run mvn dependency:tree—to locate references to milo-sdk-server, milo-sdk-client, or milo-stack-core in versions 0.6.0 through 1.1.4. Administrators managing third-party industrial software should check their Software Bills of Materials (SBOMs) or scan application lib/ directories for milo-*.jar files.
2. Plan Migrations Off the 0.6.x Branch Carefully:
   If your organization maintains legacy applications built on Eclipse Milo 0.6.x, remember that there is no 0.6.x patch. Moving from 0.6.x to 1.1.5+ crosses the major 1.0.0 API milestone (which requires JDK 17 or higher at build and runtime). Treat this upgrade as a proper engineering migration with staging tests rather than a blind drop-in JAR swap.
3. Eliminate Weak Cryptographic Policies Where Possible:
   While upgrading to 1.1.5+ closes the Basic128Rsa15 padding oracle (CVE-2026-60007), Basic128Rsa15 relies on SHA-1 and PKCS#1 v1.5—algorithms long deprecated in modern security standards. Where legacy PLCs and clients allow it, configure OPC UA server endpoints to require modern security policies and disable None/None unsecured endpoints unless strictly necessary.
4. Enforce CISA’s Network Isolation Practices:
   Patching OT and industrial middleware often requires scheduled maintenance windows and thorough impact analysis. In the interim, CISA recommends ensuring that no control system devices or OPC UA endpoints are exposed to the public internet, placing ICS networks behind dedicated firewalls isolated from corporate business networks, and restricting remote access to updated Virtual Private Networks (VPNs)—keeping in mind that a VPN is only as trustworthy as the endpoint connecting through it.

Summary Takeaway: Open-source libraries like Eclipse Milo quietly do the heavy lifting behind critical manufacturing and utility operations worldwide. Auditing your Java applications and upgrading Milo dependencies to at least version 1.1.5 (or the current 1.1.8 maintenance release) ensures that authorization checks, memory pools, and session credentials stay locked down against both network eavesdroppers and unauthenticated disruption.