Eclipse Milo: Sechs Schwachstellen in der OPC-UA-Bibliothek und was Betreiber jetzt prüfen sollten

Worum es geht

OPC UA ist in vielen Anlagen die Schnittstelle zwischen Steuerung, Leitsystem, MES und Cloud. Wer einen OPC-UA-Server oder -Client nicht komplett selbst schreibt, nimmt dafür eine fertige Bibliothek. Eclipse Milo ist eine davon: Laut Projektbeschreibung eine quelloffene Implementierung der OPC-UA-Spezifikation für Java, verteilt über Maven Central. Damit landet Milo nicht als eigenes Produkt in der Anlage, sondern als Bestandteil von Gateways, Edge-Software, Datensammlern oder selbst entwickelten Anwendungen.

Am 15. Oktober 2026 hat die CISA dazu die Advisory ICSA-26-288-01 veröffentlicht. Als betroffene Sektoren nennt sie Chemie, kritische Fertigung, Energie sowie Wasser und Abwasser, mit weltweiter Verbreitung. Gemeldet hat die Schwachstellen laut CISA der Forscher Abhinav Agarwal. Ob die Lücken bereits ausgenutzt werden, steht nicht in der Advisory.

Die Lücken im Überblick

Die Advisory führt sechs CVEs auf. Drei davon betreffen alle Versionen ab 0.6.0, drei erst die 1.x-Reihe ab 1.0.0. Behoben sind alle in Version 1.1.5. Die CVSS-Werte stammen aus der CISA-Advisory.

Berechtigungen, die nicht greifen

Die beiden Lücken mit der größten praktischen Tragweite sehe ich bei den Berechtigungen. CVE-2026-58080 trifft Server, deren Konfiguration über die Methode OpcUaServerConfig.copy() erzeugt wird. Dabei fällt laut CISA der RoleMapper weg, also die Zuordnung von Clients zu Rollen. Rollenbasierte Prüfungen laufen dann ins Leere. Ist anonymer Zugriff erlaubt, kann ein anonymer Client Rollen-Metadaten lesen, geschützte Methoden aufrufen und Knoten löschen.

CVE-2026-62927 betrifft den Call-Service, über den Clients Methoden auf dem Server aufrufen. Ein anonymer oder wenig berechtigter Client kann laut Advisory eine verbotene Methode zusammen mit einer erlaubten in dieselbe Anfrage packen, und der Server führt beide aus. In einer Anlage hängen an solchen Methoden oft echte Aktionen, etwa das Starten eines Ablaufs oder das Zurücksetzen von Zählern.

Mitgelesene Passwörter und Diagnosedaten

CVE-2026-60007 ist nach CVSS 4.0 mit 9.1 die am höchsten bewertete Lücke. Sie betrifft Benutzernamen-Token, die mit der Security Policy Basic128Rsa15 verschlüsselt werden. Ein Angreifer auf dem Übertragungsweg kann über ein Padding-Oracle das Passwort aus dem mitgeschnittenen Token zurückgewinnen. Er muss also im Netz mithören können, kommt dann aber an echte Zugangsdaten.

Bei CVE-2026-63248 fehlen Berechtigungsprüfungen an den Diagnoseknoten des Servers. Laut CISA kann ein anonymer Client die Diagnose über eine ungesicherte Verbindung (Security Mode None) einschalten. Mit einem vertrauenswürdigen Client-Zertifikat und verschlüsselter Verbindung lassen sich dann die Sicherheitsdaten anderer Sitzungen lesen: Benutzernamen, Anmeldehistorie, Authentifizierungsart, Security Mode, Security Policy und das öffentliche Client-Zertifikat.

Server lahmlegen

Die übrigen zwei Lücken zielen auf die Verfügbarkeit. Bei CVE-2026-63252 schickt ein Angreifer ohne Anmeldung unvollständige Nachrichtenteile, die der Server im Speicher hält, bis er ausfällt. CVE-2026-61387 ist subtiler: Verschachtelte ExtensionObjects in einer Anfrage zum Anlegen von Monitored Items lösen einen StackOverflowError aus, dabei wird das Kontingent nicht wieder freigegeben. Bestehende Items laufen laut CISA weiter, neue lassen sich bis zum Neustart nicht mehr anlegen. Für ein Leitsystem, das sich nach einem Verbindungsabbruch neu anmeldet, kann das einen Ausfall der Datenübertragung bedeuten.

Welche Version du brauchst

Die CISA empfiehlt das Update auf Milo 1.1.5. Laut GitHub ist 1.1.5 am 16. Juli 2026 erschienen. Die Release Notes enthalten passende Einträge, zum Beispiel „Close username-token padding oracle“ und „Preserve role mappings when copying server config“. Die Fixes waren also schon rund drei Monate verfügbar, bevor die Advisory kam. Aktuell in der 1.1-Reihe ist zum Stand dieses Artikels Version 1.1.8 vom 6. Oktober 2026. Daneben gibt es einen ersten Release Candidate für 1.2.0, den ich nicht für den Produktivbetrieb einplanen würde.

Für die alte Reihe 0.6.x gibt es laut CISA keinen Fix, die Lösung ist eine Migration auf 1.1.5 oder neuer. Weil das ein Wechsel der Hauptversion ist, rechne ich dabei mit Anpassungen im Code. Ein Detail hilft bei der Suche: In der 1.x-Reihe heißen die Maven-Artefakte milo-sdk-server, milo-sdk-client und milo-stack-core, in der 0.6-Reihe heißen sie ohne Präfix sdk-server, sdk-client und stack-core. Beide liegen unter der Gruppe org.eclipse.milo.

Was das für Betreiber bedeutet

Die meisten Betreiber werden Milo nie selbst eingebunden haben. Die eigentliche Frage ist deshalb: In welchen Produkten steckt es? Die CISA-Advisory nennt keine Hersteller oder Produkte, die Milo verwenden. Ich würde mir die Antwort daher nicht selbst zusammenraten, sondern bei den Lieferanten von Java-basierten OPC-UA-Komponenten nachfragen, etwa Edge-Gateways, Protokollkonvertern oder Datensammlern. Wer eine Stückliste der Softwarebestandteile (SBOM) bekommt, kann dort gezielt nach org.eclipse.milo suchen.

Genau für solche Fälle schreibt der Cyber Resilience Act Herstellern künftig vor, die Komponenten ihrer Produkte zu dokumentieren, unter anderem mit einer SBOM. Wie die Fristen aussehen, habe ich im CRA-Fahrplan für Hersteller zusammengefasst.

Bis ein Update eingespielt ist, sind die bekannten Schutzmaßnahmen entscheidend. Die CISA empfiehlt in ihrer Advisory wie üblich, Steuerungssysteme nicht aus dem Internet erreichbar zu machen, sie hinter Firewalls vom Büronetz zu trennen und Fernzugriffe nur über abgesicherte Wege wie ein aktuelles VPN zuzulassen. Wie man Netze in Zonen aufteilt und die Verbindungen dazwischen regelt, beschreibe ich im Artikel zu IEC 62443.

Was du jetzt tun solltest

1. OPC-UA-Server finden. Prüfe, welche Geräte in deinen Netzen OPC UA anbieten. Der bei der IANA registrierte Standardport ist TCP 4840, Hersteller nutzen aber oft andere Ports. Wie ich dabei vorgehe, steht in Modbus TCP, OPC UA und Profinet prüfen.
2. Hersteller fragen. Frag bei den Lieferanten Java-basierter OPC-UA-Komponenten schriftlich nach, ob Eclipse Milo enthalten ist und in welcher Version. Notiere dir die Antwort mit Datum.
3. Eigene Software prüfen. Wenn ihr selbst entwickelt, durchsuche den Abhängigkeitsbaum, zum Beispiel mit mvn dependency:tree oder gradle dependencies, nach org.eclipse.milo. Auf installierten Systemen helfen Dateinamen wie milo-sdk-server-*.jar oder sdk-server-*.jar.
4. Aktualisieren. Hebe 1.x-Installationen auf mindestens 1.1.5 an, besser auf die aktuelle 1.1-Version. Plane für 0.6.x die Migration ein und behandle sie bis dahin als ungepatcht.
5. Angriffsfläche verkleinern. Schalte anonymen Zugriff ab, wo er nicht gebraucht wird. Biete keine Endpunkte mit Security Mode None und keine Basic128Rsa15-Policy an, wenn deine Clients modernere Verfahren beherrschen. Das ist meine Empfehlung, nicht die der CISA, und muss mit allen Clients getestet werden.
6. Zugriff begrenzen. Lass OPC-UA-Ports in der Firewall nur von den Clients zu, die sie wirklich brauchen, und nie direkt aus dem Internet.
7. Passwörter wechseln. Wenn Clients sich bisher mit Benutzername und Passwort über Basic128Rsa15 angemeldet haben, würde ich diese Passwörter nach dem Update ändern.

Häufige Fragen

Quellen

• CISA: ICS Advisory ICSA-26-288-01, Eclipse Milo (15.10.2026)
• Eclipse Milo auf GitHub: Releases und Release Notes (u. a. 1.1.5 vom 16.07.2026, 1.1.8 vom 06.10.2026)
• Eclipse Milo auf GitHub: Projektbeschreibung und Maven-Artefakte
• Maven Central: Gruppe org.eclipse.milo
• IANA: Service Name and Transport Protocol Port Number Registry, Eintrag opcua-tcp (4840)
• EUR-Lex: Verordnung (EU) 2024/2847 (Cyber Resilience Act), Anhang I Teil II

Stand: 22.10.2026.