Die mitgelieferten MongoDB-Schwachstellen in ABB Ability Zenon: Was ICSA-26-218-01 OT-Teams lehrt

Die Kurzfassung

Am 6. August 2026 hat CISA ICSA-26-218-01 zu ABB Ability Zenon veröffentlicht, der SCADA-, HMI- und IIoT-Plattform, die in Energie, Wasser, Fertigung sowie Lebensmitteln und Getränken im Einsatz ist. Das Advisory listet 13 Schwachstellen, CVSS v3 bis 7,8, und beschreibt die Auswirkung als Umgehung von Sicherheitsmechanismen, Absturz von Systemen, Ausführung nicht autorisierter Aktionen oder Kompromittierung von Daten.

Auffällig ist, wo diese Schwachstellen sitzen. Keine steckt in Zenons Steuerungslogik. Alle 13 sitzen in einer MongoDB 4.2, die ABBs IIoT-Dienste in die Plattform einbetten. Die neueste, CVE-2025-14847, lässt einen nicht authentifizierten Client nicht initialisierten Speicher über einen fehlerhaften komprimierten Header lesen. Der Rest sind MongoDB-Server-Probleme aus 2020 und 2021, von Autorisierungsumgehung bis Denial of Service.

Dieser Unterschied ist wichtig für Ihre Reaktion. Sie können eine Datenbank, die ABB in sein Produkt einbaut, nicht selbst aktualisieren. Sie bewegt sich im Release-Zyklus von ABB, und der kann auf einem validierten, verfügbarkeitskritischen System langsam sein. Die sinnvolle Reaktion ist also nicht, zu warten, sondern zu ändern, was das Ding überhaupt erreichen kann.

Was das Advisory sagt

Direkt aus dem Advisory und den CVE-Einträgen:

• Produkt: ABB Ability Zenon. Betroffene Komponente ist ABB IIoT services mit MongoDB 4.2, gelistet über alle Versionen dieses Aufbaus.
• Die Schwachstellen: 13 CVEs. Eine ist neu, CVE-2025-14847, ein nicht authentifiziertes Heap-Lesen. Der Rest sind MongoDB-Server-CVEs aus 2020 und 2021, darunter CVE-2020-7921 (eine Schwachstelle im Autorisierungssubsystem, die eine Umgehung der IP-Allowlist erlaubt), CVE-2020-7925 (eine Parser-Schwachstelle, die ein nicht authentifizierter Angreifer treffen kann) und eine Reihe von Denial-of-Service- und Speicherzugriffs-Fehlern (CVE-2020-7928, 7929, 7923, 7924 und CVE-2021-20330, 32036, 32040, 20333, 20328, 20334).
• Schweregrad: CVSS v3 bis 7,8.
• Was es ermöglicht, laut CISA: Sicherheitsmechanismen umgehen, Systeme zum Absturz bringen, nicht autorisierte Aktionen ausführen oder Daten kompromittieren.
• Wie es erreicht wird: Die über das Netzwerk erreichbaren Fehler brauchen einen Angreifer, der eine Verbindung zur Datenbank öffnen kann. Manche brauchen gar kein Konto.
• Behebung: ABB hat eine Anleitung im Advisory. CISA ergänzt seine übliche ICS-Empfehlung: das System vom öffentlichen Internet fernhalten, vom Unternehmensnetz isolieren und den Fernzugriff über einen kontrollierten Pfad führen.

CISA hat keine aktive Ausnutzung in freier Wildbahn gemeldet. Lesen Sie es als eine Exposition, die es zu schließen gilt, nicht als Brand, den es zu löschen gilt.

Warum das immer wieder passiert

Lesen Sie über den Namen ABB hinweg, und das ist eine Geschichte darüber, woraus jede OT-Plattform gebaut ist. Keines dieser Produkte ist eine einzige Binärdatei. Hersteller bündeln Datenbanken, Historians, Webserver, Message Broker und Sprach-Runtimes, um schneller Funktionen auszuliefern, und jede davon trägt ihre eigenen Schwachstellen in Ihre Anlage.

Das Problem ist die zeitliche Abfolge. Sie können die mitgelieferte MongoDB nicht austauschen, ohne den Support und die erneute Validierung der Plattform zu riskieren, die von ihr abhängt. Die eigentliche Behebung kommt, wenn ABB neu baut und neu ausliefert, und in OT kann das gegen ein zertifiziertes System, das niemand neu starten will, dauern. In der Zwischenzeit macht die Komponente weiter ihre Arbeit, antwortet auf einem Port, in einem Netz, genau wie vorgesehen.

Eine Datenbank aus der 4.2-Ära, die fünf Jahre alte CVEs in einer Plattform von 2026 trägt, ist keine Schlamperei. Es ist die normale Lücke zwischen dem Moment, in dem eine Abhängigkeit einen Fix ausliefert, und dem Moment, in dem ein Hersteller ihn sicher in ein Industrieprodukt einfügen kann. Die Exposition ist darin angelegt, wie OT-Software zusammengesetzt wird, und deshalb wird Patchen allein ihr immer einen Schritt hinterherhinken.

Was tatsächlich ausgenutzt wird

Unter der CVE-Liste ist das Risiko klar. Ein Angreifer erreicht eine Datenbank, die nie hätte erreichbar sein dürfen, und spricht mit ihr. Bei den nicht authentifizierten Schwachstellen ist das der gesamte Angriff. Keine Malware, keine Zero-Day-Kette, kein gestohlenes Konto. Netzwerkreichweite und eine präparierte Anfrage.

Deshalb ist CISAs Rat in diesem Advisory derselbe, den es in fast jedem druckt: das System nicht exponieren, isolieren und den Fernzugriff hinter einen kontrollierten Pfad legen. Die Fehler zu beheben ist ABBs Sache. Die Erreichbarkeit ist Ihre.

Die Frage, die sich in Ihrem eigenen Netz zu stellen lohnt, ist nicht, ob MongoDB gepatcht ist. Sie ist, was aktuell eine Verbindung zu den IIoT-Diensten öffnen kann und ob Sie es merken würden, wenn etwas es täte. In einem flachen Anlagennetz lautet die Antwort meist: alles im Subnetz, und nein.

Die Maßnahme, die es wirklich eingrenzt

Sie schließen das ohne den Patch, indem Sie die Komponente nur noch über einen Durchsetzungspunkt erreichbar machen.

Ein Industrial Proxy sitzt im Zugriffspfad zu den IIoT-Diensten von ABB Ability Zenon und vermittelt jede Sitzung, die sie erreicht. In der Praxis:

• Die Datenbank antwortet nicht mehr beliebigen Clients im Subnetz. Der einzige Weg zu ihr ist eine Sitzung, die der Proxy bereits authentifiziert hat, womit die nicht authentifizierten Schwachstellen genau das verlieren, was sie am meisten brauchen: einen nicht authentifizierten Aufrufer.
• Jede Sitzung ist an eine benannte Person oder einen benannten Dienst gebunden, auf das beschränkt, was die Arbeit erfordert, mit MFA am Proxy. Am ABB-Stack wird nichts verändert, also muss dafür nichts gepatcht, neu validiert oder neu gestartet werden.
• Jede Sitzung, die die IIoT-Dienste berührt, wird protokolliert, sodass "würden wir es merken" endlich eine Antwort hat.
• Es installiert nichts auf der Plattform. Es ist ein IEC-62443-Conduit zwischen der Steuerungszone und allem darüber, also die Idee der Industrial DMZ, heruntergebrochen auf eine einzelne mitgelieferte Komponente.

Das ersetzt das Patchen nicht. Wenden Sie ABBs Behebung an, wenn Ihr Änderungsprozess es erlaubt. Was es Ihnen bringt, ist Zeit, die das Patchen nicht bringen kann: Die Exposition ist jetzt geschlossen, sie bleibt geschlossen über die nächste CVE einer eingebetteten Komponente hinweg, von der Sie noch nichts gelesen haben, und nichts davon berührt ein zertifiziertes System, das Sie sich nicht zu stören leisten können. Die Mechanik steht in was ein Industrial Proxy ist, und die Audit-Seite in OT-Mikrosegmentierung mit SIEM-Integration.

Das Johnson-Controls-Advisory, kurz

CISA hat am selben Tag ein zweites Advisory ausgeliefert, ICSA-26-218-02, für den Johnson Controls TL280 Netzwerk-Alarmkommunikator in der kritischen Fertigung. Die Schwachstelle sind fest einprogrammierte Zugangsdaten in der Firmware (CVE-2026-27871, CVSS v3 4,1), und Johnson Controls behebt sie per Firmware-Update.

Geringerer Einsatz, andere Box, vertraute Form. Sie können eine fest einprogrammierte Zugangsdaten in fremder Firmware nicht rückgängig machen. Was Sie tun können, ist sicherzustellen, dass das Gerät nur auf einem Pfad antwortet, der jeden, der sich verbindet, authentifiziert und protokolliert, sodass eine geleakte statische Zugangsdaten nicht dasselbe ist wie eine offene Tür. Zwei Advisories, ein Tag, derselbe zugrunde liegende Schritt.

Wo Sie diese Woche anfangen

1. Finden Sie ABB Ability Zenon und seine IIoT-Dienste in Ihrer Umgebung, und notieren Sie, welche Segmente aktuell eine Verbindung zu ihnen öffnen können.
2. Bestätigen Sie, dass die Datenbank nicht vom Unternehmensnetz oder aus dem Internet erreichbar ist. Falls doch, schließen Sie das zuerst.
3. Wenden Sie ABBs Behebung über Ihren normalen Änderungsprozess an und verfolgen Sie sie, aber lassen Sie das Patch-Datum nicht das Einzige sein, was zwischen einem nicht authentifizierten Client und der Komponente steht.
4. Verschieben Sie die IIoT-Dienste hinter einen Durchsetzungspunkt, sodass der Zugriff an Identität gebunden, minimal berechtigt und aufgezeichnet ist.
5. Führen Sie dieselbe Prüfung an den anderen mitgelieferten Teilen Ihres SCADA- und HMI-Stacks durch. Das nächste Advisory wird eine andere Datenbank oder Runtime nennen, und die Reaktion wird sich nicht ändern.

ICSA-26-218-01 ist ein guter Anlass, etwas Umfassenderes zu beheben als eine einzelne Komponente. In OT dürfen Sie die Schwachstelle selten nach Ihrem eigenen Zeitplan patchen, also legen Sie stattdessen die Bedingungen dafür fest, was sie erreichen kann.