CVE-2026-61387 is a high severity denial of service in Eclipse Milo, the Java OPC UA SDK. A deeply nested CreateMonitoredItems request triggers a StackOverflowError and leaks the global quota, blocking new monitored items for every client until restart. Versions 1.0.0 through 1.1.4 are affected.
What's affected
- Product: Eclipse Milo, versions 1.0.0 through 1.1.4.
- Fixed: a release after 1.1.4. The record does not name the version, so confirm it in the Milo release notes.
- Exposed: servers that enforce a finite global monitored-item limit and accept requests from unauthenticated clients.
- Scope of damage: existing monitored items and other server functions keep working. Only creating new ones fails.
How to check if you're exposed
Find the Milo version your build resolves.
mvn dependency:tree -Dincludes=org.eclipse.milo
./gradlew dependencies --configuration runtimeClasspath | grep -i milo
Compare it with the affected range above, and look at transitive use as well: Milo is often embedded in industrial gateways and data collection products that do not list it prominently.
Then check how the server is exposed. If unauthenticated or anonymous clients can reach your OPC UA endpoint, the flaw can be triggered without credentials. Watch for a symptom: clients that can connect but fail every attempt to create monitored items, with errors about quota or too many items, until the server restarts.
What to do now
- Upgrade Eclipse Milo to a release after 1.1.4.
- Disable anonymous access and restrict network access to the server to known clients.
- If you see new monitored items failing while the server looks healthy, restart it as a stopgap and investigate the source of the requests.
- Alert on StackOverflowError in server logs.
- Run the free in-browser dependency scan on your lockfile or manifest to see every affected package in one pass.
Why it matters
The weaknesses are CWE-400 (Uncontrolled Resource Consumption), CWE-460 (Improper Cleanup on Thrown Exception) and CWE-772 (Missing Release of Resource after Effective Lifetime). Two commits fix two parts of one problem. One bounds recursive ExtensionObject decoding so nested bodies share the depth limit, and the other makes the monitored item quota exception safe, so a failed creation gives its reservation back.
Together they matter because a small hostile request can raise the error, and the server did not undo its counter increment when the error escaped. Repeating it exhausts the finite global quota. The record scores it 7.5 (High) and does not mark it as exploited in the wild.
Quick check
Do existing subscriptions stop working?
No. The record says existing monitored items and other server functions remain unaffected. Only creating new monitored items is blocked until restart.
Sources
Last reviewed: 18 October 2026.
