Das SCADA, das Sie nicht am Dienstag patchen können: AVEVA Enterprise SCADA (ICSA-26-225-01)

Die Kurzfassung

Am 13. August 2026 veröffentlichte CISA ICSA-26-225-01 für AVEVA Enterprise SCADA und Enterprise SCADA HMI, die Leitsoftware, die industrielle Prozesse in der Kritischen Fertigung steuert. Die Schwachstelle CVE-2025-7639 ist ein Problem der Deserialisierung nicht vertrauenswürdiger Daten: Ein manipuliertes serialisiertes Paket, das an die Software gesendet wird, kann verfälscht werden und Codeausführung während der Deserialisierung auslösen. CVSS-v3-Basiswert 7,1, hohe Angriffskomplexität, keine bekannte öffentliche Ausnutzung.

Die Voraussetzung ist die für OT vertraute: Ein Angreifer muss den SCADA- oder HMI-Dienst erreichen, um das Paket zu senden. Diese Erreichbarkeit liegt in Ihrem Einflussbereich.

Was die Meldung besagt

Direkt aus der Meldung und dem CVE-Eintrag:

• Produkte: AVEVA Enterprise SCADA und Enterprise SCADA HMI.
• Die Schwachstelle: CVE-2025-7639, Deserialisierung nicht vertrauenswürdiger Daten mit Codeausführung während der Deserialisierung.
• Betroffene Versionen: Enterprise SCADA 2025 und früher bis zu den aufgeführten Service-Pack-Ständen (2024 bis 2024 SP1 P01, 2023 bis 2023 SP1, 2022 bis 2022 SP2 P2, 2021 bis SP2 P5) sowie Enterprise SCADA HMI 2024 und 2023 und früher.
• Schweregrad: CVSS v3 7,1, hohe Angriffskomplexität.
• Angriffsweg: Ein Angreifer, der ein manipuliertes serialisiertes Objekt an den Dienst übermitteln kann. Codeausführung ist das Ergebnis.
• Abhilfe: AVEVA hat Korrekturen im Sicherheitsbulletin AVEVA-2026-005 veröffentlicht. CISA ergänzt die üblichen ICS-Empfehlungen: das System vom öffentlichen Internet fernhalten, vom Unternehmensnetz isolieren und Fernzugriff über einen kontrollierten Pfad leiten.

CISA meldete keine Ausnutzung in freier Wildbahn. Betrachten Sie es als eine Schwachstelle, die Sie zu Ihren Bedingungen schließen, nicht als einen Brand, den Sie löschen müssen.

Warum das immer wieder passiert

SCADA und sein HMI sind Windows-basierte Anwendungen mit Datenbanken und Netzwerkdiensten, die einen physischen Prozess überwachen, der nicht einfach angehalten werden kann. Das ist die gesamte Spannung der OT-Sicherheit in einem Satz. Die Software weist dieselben Schwachstellenklassen wie jede Unternehmensanwendung auf, Deserialisierung eingeschlossen, doch ein Patch lässt sich nicht an einem beliebigen Dienstag einspielen. Eine Korrektur wartet auf ein validiertes Wartungsfenster, das Wochen oder eine ganze Saison entfernt sein kann, sofern der Hersteller sie überhaupt für Ihre Version zertifiziert. In der Zwischenzeit läuft der Prozess weiter, und der verwundbare Dienst hört weiter zu.

Diese Lücke zwischen „ein Fix existiert" und „wir können ihn sicher einspielen" ist der Ort, an dem OT-Risiko tatsächlich entsteht. Das ist kein Versagen des Anlagenteams. Es ist die Natur von Software, die Maschinen steuert, die man nicht auf Abruf neu starten kann.

Was tatsächlich ausgenutzt wird

Reduzieren Sie die CVE auf ihre Mechanik. Ein Angreifer, der eine Verbindung zum SCADA- oder HMI-Dienst öffnen kann, sendet ein manipuliertes serialisiertes Objekt, und während der Deserialisierung wird daraus Code, der auf dem Host ausgeführt wird, der den Prozess überwacht. Hohe Angriffskomplexität erhöht die Anforderungen an das Paket, doch die erste Zutat, die der Angreifer benötigt, ist einfach: Netzwerkzugang zum Dienst. In einem flachen OT-Segment hat der größte Teil der Anlage diesen Zugang.

Die relevante Frage für Ihr eigenes Netz lautet daher nicht nur, ob AVEVA gepatcht ist. Sie lautet: Was kann derzeit eine Verbindung zu den SCADA- und HMI-Servern öffnen, und würden Sie es bemerken, wenn etwas dies täte? In einem flachen Steuerungsnetz lauten die ehrlichen Antworten meist „die meisten Dinge" und „nein".

Die Maßnahme, die tatsächlich Grenzen setzt

Sie schließen diese Schwachstelle, ohne auf das Wartungsfenster zu warten, indem Sie SCADA und HMI nur über einen Durchsetzungspunkt erreichbar machen.

Das Access Gate sitzt im Zugriffspfad zu diesen Servern und vermittelt jede Sitzung, die sie erreicht. In der Praxis:

• Die Server antworten nicht mehr auf beliebige Clients im Subnetz. Der einzige Weg zu ihnen führt über eine Sitzung, die das Gate bereits authentifiziert hat, eine Deserialisierungsschwachstelle verliert damit das, was sie am meisten benötigt: einen nicht authentifizierten Aufrufer im Netz.
• Jede Sitzung ist an eine namentlich bekannte Person oder einen Dienst gebunden, auf die Aufgabe beschränkt, mit MFA am Gate und aufgezeichnet. Am AVEVA-Stack wird nichts verändert, sodass für diese Wirkung nichts neu validiert oder neu gestartet werden muss.
• Da das Access Gate ein Compute-Element im Netzwerkpfad ist, ein agentenloser Durchsetzungspunkt vor dem Asset, kein Cloud-Dienst, wendet es Identität und minimale Rechtevergabe direkt neben dem SCADA-Server an, ohne dort etwas zu installieren.

Das ersetzt das Upgrade nicht. Spielen Sie AVEVAs Korrekturen ein, sobald Ihr Änderungsprozess es erlaubt. Was der Durchsetzungspunkt Ihnen verschafft, ist Zeit, die der Patch nicht bieten kann: Die Schwachstelle ist jetzt geschlossen, bleibt durch die nächste SCADA-Meldung, die Sie noch nicht gelesen haben, geschlossen, und nichts davon hängt von einem Wartungsfenster ab. Die Mechanik ist in Was ein Industrial Proxy ist beschrieben, die Segmentierungsseite in OT-Netzwerksicherheit, und die Zugriffsseite in Sicherer OT- und Lieferanten-Fernzugriff für die Integratoren, die diese Systeme warten.

Wo Sie diese Woche beginnen

1. Ermitteln Sie jede Enterprise SCADA- und SCADA HMI-Instanz und notieren Sie, welche Segmente derzeit eine Verbindung zu ihnen öffnen können.
2. Bestätigen Sie, dass die Server weder vom Unternehmensnetz noch vom Internet erreichbar sind. Falls doch, schließen Sie das zuerst.
3. Spielen Sie AVEVAs Korrekturen im Rahmen Ihres normalen Änderungsprozesses ein und verfolgen Sie diese, aber lassen Sie das Patch-Datum nicht als einzige Barriere zwischen einem netzwerkerreichbaren Client und Codeausführung stehen.
4. Stellen Sie die SCADA- und HMI-Server hinter einen Durchsetzungspunkt, sodass der Zugriff identitätsgebunden, minimal berechtigt und aufgezeichnet ist, auch für die Integratoren, die sie warten.
5. Führen Sie dieselbe Prüfung für den Rest des OT-Stacks durch. Die nächste Meldung wird ein anderes Produkt nennen, und die Reaktion wird sich nicht ändern.

ICSA-26-225-01 ist ein guter Anlass, etwas Grundlegenderes als einen einzelnen Server zu beheben. Die Software, die den Prozess steuert, ist letztlich nur ein Server in Ihrem Netz, und in OT können Sie die Schwachstelle selten nach Ihrem eigenen Zeitplan patchen. Also legen Sie fest, was sie erreichen kann.