Which versions of Eclipse Milo are affected by CVE-2026-60007?

Eclipse Milo OPC UA SDK versions 0.6.0-1.1.4 contain a critical password recovery vulnerability affecting any organization using this open-source library for industrial control systems or connected…

How to fix or mitigate CVE-2026-60007?

Within 24 hours: identify all systems and applications using Eclipse Milo versions 0.6.0 through 1.1.4 and document their network exposure. Within 7 days: implement network-layer restrictions (firewall rules, network segmentation) to limit OPC UA endpoint access to trusted sources only, enable detailed logging for all ActivateSession requests and authentication failures, and enforce encryption protocols above Basic128Rsa15 where alternatives exist. Within 30 days: monitor the Eclipse Foundation's public repository for a patched version release and establish a process to upgrade immediately upon availability; pending a patch, evaluate alternative OPC UA implementations or consider air-gapping high-risk systems until a fix is released.

Eclipse Milo CVE-2026-60007

Q: What is the CVSS score of CVE-2026-60007?

CVE-2026-60007 has a CVSS 4.0 base score of 9.1 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.5%.

EUVD-2026-52660 CRITICAL

Observable Response Discrepancy (CWE-204)

2026-08-04 eclipse

GHSA-jrjq-9cmf-3h6f

Information Disclosure Oracle Eclipse Milo Eclipse Foundation

9.1

CVSS 4.0 · Vendor: eclipse

Severity by source

Vendor (eclipse) PRIMARY

9.1 CRITICAL

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.4 HIGH

Unauthenticated ActivateSession probing gives PR:N, but the adaptive on-path padding-oracle attack needing a captured token and many requests forces AC:H; password recovery yields C:H and credential reuse yields I:H, with no availability impact.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (eclipse).

CVSS VectorVendor: eclipse

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 04, 2026 - 13:08 vuln.today

Analysis Generated

Aug 04, 2026 - 13:08 vuln.today

CVE Published

Aug 04, 2026 - 11:55 cve.org

CRITICAL 9.1

DescriptionCVE.org

In Eclipse Milo versions 0.6.0 through 1.1.4, username-token processing returns distinguishable errors for invalid RSA PKCS#1 v1.5 padding and other authentication failures, allowing an on-path attacker who captures a victim's Basic128Rsa15-encrypted username token to use repeated unauthenticated ActivateSession requests as a padding oracle, recover the victim's password, and authenticate with the recovered credentials.

AnalysisAI

Password recovery in Eclipse Milo (the open-source OPC UA SDK for Java) versions 0.6.0 through 1.1.4 allows an on-path attacker to break username-token confidentiality via a Bleichenbacher-style padding oracle. The server returns distinguishable error responses for invalid RSA PKCS#1 v1.5 padding versus other authentication failures during username-token processing, so an attacker who captures a victim's Basic128Rsa15-encrypted username token can send repeated unauthenticated ActivateSession requests to recover the cleartext password and then authenticate as the victim. No public exploit identified at time of analysis and it is not listed in CISA KEV; the weakness and its upstream fix are confirmed by the Eclipse Foundation.

Technical ContextAI

Eclipse Milo is a widely-used Java implementation of the OPC UA (IEC 62541) industrial automation protocol stack and SDK, providing both client and server components. The flaw lives in AbstractUsernameIdentityValidator, which decrypts and validates the UserNameIdentityToken presented during the ActivateSession service call. When the Basic128Rsa15 security policy is in use, the encrypted password is protected with RSA using PKCS#1 v1.5 padding, a scheme long known to be vulnerable to adaptive chosen-ciphertext (Bleichenbacher) attacks whenever the decrypting party leaks whether padding was well-formed. This maps to CWE-204 (Observable Response Discrepancy): decryption/padding failures surfaced with status codes such as Bad_EncodingLimitsExceeded or Bad_UserAccessDenied, while other failures returned different codes, handing the attacker a decryption oracle. The fix (commit db59fae) collapses all these paths to a single uniform Bad_IdentityTokenInvalid response and strips exception causes, removing the distinguishing signal.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed. Upgrade Eclipse Milo to a release that incorporates commit db59fae993a3a1bc66fffc8a2796d444b40285fb, which makes all username-token decryption and authentication failures return an identical Bad_IdentityTokenInvalid status without a distinguishing exception cause; consult the Eclipse advisory at https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/598 for the exact fixed version once published (the affected range ends at 1.1.4). As the most effective compensating control until patched, disable the Basic128Rsa15 security policy on all server endpoints and require modern policies such as Basic256Sha256 or Aes128_Sha256_RsaOaep that use OAEP padding rather than PKCS#1 v1.5 - the trade-off is that legacy clients supporting only Basic128Rsa15 will no longer connect. Additionally restrict network reachability of the OPC UA endpoint to trusted segments to remove the on-path capture and probing capability; note this reduces but does not eliminate risk from a determined on-path adversary. Rotating any passwords that may have been exposed on an untrusted network is also prudent.