Smart Machines & Factories Editorial TeamOn October 15, 2026, CISA published ICSA-26-288-01, disclosing six CVEs in Eclipse Milo, the open-source Java implementation of the OPC UA protocol stack that many vendors embed in SCADA gateways, historian connectors and custom MES-to-PLC bridges rather than license a commercial stack for. Unlike the single-vendor advisories that dominate most ICS patch cycles, a flaw in Milo quietly affects every integrator who pulled the library into a project without necessarily knowing it was there.
A Padding Oracle That Recovers Passwords
The headline flaw, CVE-2026-60007, scores 9.1 Critical on CVSS v4.0. In Milo versions 0.6.0 through 1.1.4, the username-token authentication path returns distinguishable error responses for invalid RSA PKCS#1 v1.5 padding versus other authentication failures. An attacker positioned on the network path who has captured a victim's Basic128Rsa15-encrypted username token can send repeated unauthenticated ActivateSession requests, use the differing error responses as a padding oracle, and recover the victim's password bit by bit — then authenticate directly with the recovered credentials. CISA's advisory does not report active exploitation, but the technique is well understood in cryptographic literature and does not require any special access beyond network position.
ICSA-26-288-01 — Key Facts
- Six CVEs total — CVE-2026-60007, CVE-2026-63252, CVE-2026-63248, CVE-2026-62927, CVE-2026-58080, CVE-2026-61387;
- Worst case — CVE-2026-60007, a Basic128Rsa15 username-token padding oracle, CVSS v4.0 9.1;
- Affected versions — Eclipse Milo 0.6.0 through 1.1.4 for the padding-oracle and related authentication flaws;
- Fix — upgrade to Milo 1.1.5 or later, which closes all six flaw classes, including a RoleMapper authorization bypass and memory-exhaustion issues;
- Exploitation status — CISA does not report in-the-wild exploitation or attribute the flaws to an incident.
Why a Library Flaw Is Harder to Track Than a Product Flaw
Siemens, Rockwell or Schneider advisories map cleanly to a product name and a firmware version a plant team already inventories. Milo is different: it is a dependency, often pulled in a few layers deep by a custom bridge, a historian connector, or an in-house SCADA front end that nobody labeled as "OPC UA software" on the asset list. Tracing exposure means checking build manifests and dependency trees across every custom industrial integration a site has shipped, not just scanning known-vendor firmware versions against a CVE feed. That gap is exactly where OT security teams end up discovering, months after a disclosure like this one, that a tool built two years ago silently inherited a critical flaw through a library nobody re-audited.
The Patch Is Easy; Finding Every Instance Is Not
Bumping a Maven or Gradle dependency to Milo 1.1.5 is a small, low-risk change on its own. The real work is the audit beforehand: enumerating every custom OPC UA client or server a plant has running, confirming which ones actually embed Milo versus a different stack, and verifying the authentication path in each one before and after the upgrade so a patch doesn't silently break an integration a vendor never documented. That is a software engineering task — dependency auditing, build-pipeline changes, regression testing against real PLC and historian endpoints — not a firmware flash a maintenance technician can push from a USB stick.
YuSMP Group builds and maintains the custom web-based dashboards and integration layers that plants use to monitor exactly this kind of OPC UA traffic, and can audit a site's existing connectors for exposure to flaws like CVE-2026-60007 before scheduling the Milo 1.1.5 upgrade across production systems.
Sources: CISA ICS Advisory ICSA-26-288-01, October 15, 2026; OpenCVE, CVE-2026-60007 record.