Summary
- Six CVEs affect Eclipse Milo, the widely used open-source OPC UA Java SDK, across versions 0.6.0 to 1.1.4, with CVSS v4.0 scores reaching 9.1.
- The most serious flaw (CVE-2026-60007) enables a padding oracle attack that can recover plaintext credentials from captured Basic128Rsa15-encrypted username tokens.
- A misconfigured copy method (CVE-2026-58080) silently drops all role-based access controls, leaving anonymous clients able to invoke protected methods and delete protected nodes.
- Two memory exhaustion bugs allow unauthenticated remote clients to crash or degrade an OPC UA server with no credentials required.
- The fix is Eclipse Milo 1.1.5; there are no patches for the 0.6.x branch, requiring a migration rather than a simple update.
What was disclosed
CISA published an industrial control systems advisory on 15 October 2026 covering six vulnerabilities in Eclipse Milo, the Eclipse Foundation’s open-source implementation of the OPC UA protocol stack for Java. The affected range spans versions 0.6.0 through 1.1.4. Eclipse Milo is deployed worldwide across chemical, critical manufacturing, energy, and water and wastewater sectors, making the exposure broad and operationally significant.
Credential recovery via padding oracle (CVE-2026-60007, CVSS 4.0: 9.1 Critical)
The most severe of the six is a padding oracle vulnerability in how Milo processes username tokens encrypted with the Basic128Rsa15 security policy. The server returns distinguishable error responses for invalid RSA PKCS#1 v1.5 padding versus other authentication failures. An on-path attacker who captures a victim’s encrypted username token can make repeated unauthenticated ActivateSession requests to probe the padding byte-by-byte, ultimately recovering the plaintext password and authenticating as that user. No prior access is required beyond network positioning.
Silent loss of role-based access controls (CVE-2026-58080, CVSS 4.0: 8.8 High)
Servers that rely on role permissions and build their running configuration using OpcUaServerConfig.copy() are affected by a flaw where that copy operation fails to preserve a configured RoleMapper. The result is that sessions receive no role identifiers and the default access controller skips all role-permission checks entirely. An anonymous client — where anonymous sessions are permitted — can read role-permission metadata, invoke protected methods, and delete protected nodes without any authentication. This vulnerability is particularly insidious because the failure is silent: the server appears to be running correctly while access controls have effectively been removed.
Authorisation bypass via mixed-batch method calls (CVE-2026-62927, CVSS 4.0: 8.7 High)
The OPC UA Call service in affected versions dispatches the original mixed batch to address-space handlers after calculating authorisation, rather than filtering it. An anonymous or low-privileged client can exploit this by batching a denied method call alongside a permitted one. The denied method executes despite the authorisation check having flagged it.
Diagnostics nodes expose session security data (CVE-2026-63248, CVSS 4.0: 6.9 Medium)
OPC UA server diagnostics nodes across all affected versions fail to enforce access authorisation. An anonymous client can enable diagnostics over an unencrypted endpoint. A client presenting a trusted application certificate over a SignAndEncrypt channel can go further, reading security diagnostics for other active sessions — including usernames, login history, authentication mechanisms, security modes and policies, and client certificates.
Two resource exhaustion paths enabling denial of service (CVE-2026-63252, CVE-2026-61387)
CVE-2026-63252 allows an unauthenticated remote client to exhaust the server’s pooled direct memory by repeatedly sending incomplete message chunks and disconnecting before the server releases them. With sufficient repetition, this can terminate the server process. CVE-2026-61387 targets a different resource: the global monitored-item quota. By sending CreateMonitoredItems requests containing deeply nested PubSub ExtensionObjects, an attacker can trigger a StackOverflowError during decoding. Because quota accounting is not exception-safe, the reserved slot is never returned, allowing an unauthenticated client to gradually exhaust the quota and prevent all clients from creating new monitored items until the server is restarted.
Remediation path
The Eclipse Foundation has released version 1.1.5, which addresses all six vulnerabilities. Organisations running Milo 1.0.0 through 1.1.4 can upgrade directly. Those on the 0.6.x branch have no patched release available in that line and must migrate to 1.1.5 or later. The vulnerabilities were reported to CISA by researcher Abhinav Agarwal.
Why it matters
Eclipse Milo underpins OPC UA connectivity in Java-based industrial platforms across sectors where availability and data integrity are safety-critical. The combination of vulnerabilities here is particularly concerning: an attacker who can position themselves on the network path to an OPC UA server could recover operator credentials, then use those credentials to invoke protected operations or delete nodes — including, in some configurations, without needing to capture any traffic at all if anonymous sessions are enabled and the RoleMapper bug is present. The denial-of-service paths require no credentials whatsoever. CISOs responsible for OT environments should treat this as a priority inventory and patching exercise, and should not assume network segmentation alone is sufficient given that some of these bugs are exploitable by clients already permitted inside the control network.
What to do now
- Identify all instances of Eclipse Milo in your environment, including versions embedded in third-party OT platforms and SCADA components.
- Upgrade all Milo deployments to version 1.1.5 or later; there is no patch available for the 0.6.x branch and migration is required.
- Treat any Milo 0.6.x deployment as unpatched and apply compensating controls — including disabling anonymous sessions where possible — until migration is complete.
- Ensure OPC UA servers are not internet-facing and are isolated from corporate networks behind firewalls.
- Where remote access to OPC UA infrastructure is required, enforce use of VPN and keep VPN software current.
- Review server configurations to confirm that OpcUaServerConfig.copy() is not being used in ways that would silently discard a configured RoleMapper, and validate that role-permission checks are functioning as expected after any upgrade.
- Report any suspected malicious activity targeting OPC UA infrastructure to CISA.
