CODESYS & Schutzgeräte: Was Angreifer wirklich tun
Für die neuen CODESYS-Lücken (CVE-2026-76992, CVE-2026-79625) und die Schwachstellen im ABB-Engineering-Tool PCM600 ist bisher keine Ausnutzung bekannt. Das ist aber keine Entwarnung. Die realen Angriffe auf Schutzgeräte kamen bislang ohne Zero-Day aus, über Standardpasswörter, offene Dienste und Fernzugänge ohne MFA. Wer Schutztechnik oder CODESYS-Steuerungen betreibt, sollte deshalb zuerst Zugänge und Konfiguration prüfen und erst danach auf den Patch warten.
Was ist diese Woche neu?
- CODESYS (CERT@VDE VDE-2026-094, BSI-Warnung vom 02.10.2026): Mit CVE-2026-76992 (CVSS 7,5) kann ein bösartiges Gateway den Gateway Client ohne Anmeldung zum Absturz bringen. Betroffen sind auch Development System und HMI. Bei CVE-2026-79625 (CVSS 8,1) kann ein angemeldeter Nutzer mit Monitoring-Rechten über eine Race Condition Speicher in der Runtime beschädigen. Für Linux- und Raspberry-Pi-Runtimes kommt der Fix mit Version 4.23.0.0 erst im 4. Quartal.
- ABB PCM600 (CISA ICSA-26-274-03, 01.10.2026): Mit PCM600 werden Relion-Schutzrelais parametriert. Ein lokaler Nutzer kann bis Version 2.14 SYSTEM-Rechte bekommen (CVE-2026-15952). Dazu kommt ein Path Traversal beim Entpacken (CVE-2026-15953). Einen Patch gibt es noch nicht.
Keine dieser Lücken steht im CISA-KEV-Katalog, und ein öffentlicher Exploit ist nicht bekannt (Stand 03.10.2026).
Welche Angriffe auf Schutzgeräte sind wirklich belegt?
Ukraine, Dezember 2016 (Industroyer): Die Malware enthielt ein Modul gegen SIPROTEC-4-Schutzgeräte. Es nutzte die damals bekannte Lücke CVE-2015-5374 aus, ein einzelnes UDP-Paket legte das Gerät lahm. Belegt ist, dass das Modul eingesetzt wurde. Ob es tatsächlich wirkte, bewerten Analysten bis heute unterschiedlich.
Polen, Dezember 2025: Bei Angriffen auf mehr als 30 Wind- und Solarparks sowie ein Heizkraftwerk wurden Firmware und Dateien von RTUs, HMIs und Schutzgeräten zerstört. Laut dem Folgebericht von CERT Polska (August 2026) betraf das unter anderem Hitachi Energy Relion 650. Gelöscht wurde über ein ab Werk aktives FTP-Konto mit Standardpasswort, der Einstieg lief über eine Firewall ohne MFA. Strom und Wärme flossen weiter, die Kommunikation zu den Anlagen fiel aus. Ein CVE wurde dafür nicht gebraucht.
Daraus ziehe ich als Max Gilg, OT-Cybersecurity-Experte aus Rosenheim, einen klaren Schluss: Schutzgeräte fallen nicht durch exotische Zero-Days, sondern durch Werkseinstellungen, die niemand geändert hat.
Und CODESYS?
CODESYS stammt aus Kempten und läuft in sehr vielen Steuerungen in DACH, auch unter fremdem Namen, etwa bei WAGO oder auf Linux-Runtimes. 2022 entdeckten Dragos und Mandiant das staatliche Angriffswerkzeug PIPEDREAM (INCONTROLLER), bevor es eingesetzt wurde. Ein Teil davon spricht CODESYS V3 direkt an: Es lädt Programme, stoppt und startet Steuerungen und nutzt dafür ganz normale Engineering-Funktionen, keine Schwachstelle. CISA (AA22-103A) und das BSI haben damals gewarnt.
Laborarbeiten zeigen, was zusätzlich möglich ist. Microsoft hat 2023 15 Lücken im CODESYS V3 SDK beschrieben. Nozomi hat im April 2026 gezeigt, wie sich drei Lücken zu einer Backdoor in der Steuerungsanwendung verketten lassen. Eine Ausnutzung in the wild ist für beide Fälle nicht belegt.
Das Engineering-Protokoll von CODESYS V3 läuft standardmäßig über TCP-Port 11740. Laut Shodan sind Anfang Oktober 2026 weltweit rund 2.160 Systeme erreichbar, die sich als CODESYS zu erkennen geben, davon 80 in Deutschland, 34 in der Schweiz und 10 in Österreich. Die echte Zahl dürfte höher liegen, weil viele Hersteller CODESYS unter eigenem Namen ausliefern. Eine SPS, deren Engineering-Port im Internet hängt, braucht keinen Exploit. Wer sie findet, kann sie programmieren.
Gibt es Fälle in Bayern, Österreich oder der Schweiz?
Einen öffentlich dokumentierten Angriff auf Schutzgeräte oder CODESYS-Steuerungen in DACH kenne ich nicht. Am nächsten dran ist der Fall Polen. Die Hersteller sitzen aber hier: Siemens, CODESYS in Kempten, ABB und Hitachi Energy in Zürich. In den Umspannwerken der Stadtwerke zwischen Rosenheim, Salzburg und Innsbruck stecken genau diese Geräte. Für Betreiber unter NIS2 sind Schutztechnik und Engineering-Stationen damit Pflichtteil des Risikomanagements.
Was sollten Betreiber jetzt tun?
Ich ordne das den SANS Five ICS Critical Controls zu:
- ICS Incident Response (CC1): Firmware-Stände und Parametersätze der Schutzgeräte offline sichern. In Polen hat das den Wiederanlauf entschieden.
- Defensible Architecture (CC2): Werkskonten und Standardpasswörter an Schutzgeräten ändern, FTP und andere Dienstkonten abschalten, wenn sie nicht gebraucht werden. Engineering-Stationen mit PCM600, DIGSI oder CODESYS in eine eigene Zone legen.
- Network Visibility & Monitoring (CC3): Programm-Downloads, Start/Stop-Befehle und Zugriffe auf Port 11740 sichtbar machen. PIPEDREAM nutzt legitime Funktionen, die erkennt man nur im Verkehr.
- Secure Remote Access (CC4): Fernzugänge zu Umspannwerken und Anlagen nur mit MFA und nur über einen Jump Host. Polen hat gezeigt, was eine Firewall ohne MFA anrichtet.
- Risk-Based Vulnerability Management (CC5): Prüfen, welche Geräte tatsächlich betroffen sind. Bei CODESYS die Monitoring-Rechte auf wenige Konten beschränken, bis Version 4.23.0.0 verfügbar ist.
Mit KI-Unterstützung schaffen auch kleine Teams diese fünf Punkte. Man muss sich dafür auf sie konzentrieren statt auf einzelne Produkte.
Wenn Sie wissen wollen, welche Ihrer Steuerungen und Schutzgeräte betroffen sind, hilft unser OT-Asset-Inventar. Eine Priorisierung der Lücken bekommen Sie mit unserem OT-Schwachstellen-Management.
Häufige Fragen
Werden die neuen CODESYS-Lücken schon ausgenutzt?
Nein, für CVE-2026-76992 und CVE-2026-79625 ist bis 03.10.2026 keine Ausnutzung bekannt. Sie stehen nicht im CISA-KEV-Katalog, und es gibt keinen öffentlichen Exploit. Bis zum Fix sollten nur geprüfte Engineering-Rechner Zugang zur Steuerung haben.
Darf der Servicetechniker per Fernwartung auf Schutzgeräte und SPS zugreifen?
Ja, aber nur über einen Jump Host mit MFA, zeitlich begrenzt und protokolliert. Der Angriff in Polen 2025 lief über eine Firewall ohne MFA und ein Werkskonto mit Standardpasswort.
Welches Protokoll nutzt CODESYS zum Programmieren?
CODESYS V3 nutzt ein eigenes Engineering-Protokoll, standardmäßig über TCP-Port 11740. Ältere V2-Steuerungen nutzen TCP 1200 oder 2455. Diese Ports gehören nie ins Internet.
Gab es in Deutschland oder Österreich schon Angriffe auf Schutzgeräte?
Ein öffentlich dokumentierter Fall in DACH ist nicht bekannt. Belegt sind die Ukraine 2016 und Polen 2025. Die betroffenen Gerätetypen sind in Umspannwerken in Bayern, Salzburg und Tirol aber weit verbreitet.