Reiner lokaler Triage-Scanner zur Erkennung von CVE-2026-58115 (CVSS 10.0) in Siemens SIMATIC IoT2050 Node-RED: bewertet Industrial-OS-Versionen gegen V4.3.4.1 und settings.js auf adminAuth. Keine Payloads, keine Remote-Sondierung.
node-red-scannerLokale Triage für CVE-2026-58115, die 10.0-Schwachstelle fehlender Authentifizierung in Node-RED auf Siemens SIMATIC IoT2050 Advanced-Gateways. Gib ihm eine Industrial OS-Version, die dir gehört, oder eine settings.js-Datei, die dir gehört, und es sagt dir, ob diese Installation noch offen ist. Es greift nie auf das Netzwerk zu, sondiert nie einen Server, stellt nie einen Flow bereit, sendet nie eine Payload.
Die SchwachstelleNode-RED ist ein flow-basierter Editor, der auf Node.js aufbaut und in industrielle Komponenten eingebunden ist: Siemens bettet ihn in das SIMATIC IoT2050 Advanced-Gateway ein. Auf betroffenen Gateways erzwingt die Node-RED HTTP-Schnittstelle keine Authentifizierung, sodass ein nicht authentifizierter Remote-Angreifer bösartige Flows erstellen und beliebigen Code auf dem zugrunde liegenden Server mit maximalen Privilegien ausführen kann.
In Node-RED-Begriffen ist das eine einzige Anfrage. Ein inject-Node, der mit einem exec-Node verbunden ist, feuert, sobald der Flow bereitgestellt wird, und der exec-Node führt Shell-Befehle aus. VulnCheck hat genau das am 30. Oktober 2026 in freier Wildbahn beobachtet: ein einzelnes POST /flows, das einen selbstauslösenden Flow bereitstellte, der ein Linux-Bot-Binary herunterlud, sowie spätere Versuche, die stattdessen persistente Webshells installierten. Zwischen dem 30. Oktober und dem 1. November traf dieselbe Quelle diese Schwachstelle 16 Mal. Das Tool reproduziert nichts davon. Seine Aufgabe ist es, dir zu sagen, bevor ein Angreifer es tut, ob deine Installation offen ist.
Was es prüftEine von dir angegebene Industrial OS-Version (--industrial-os 4.3.4.0): bewertet gegen den von Siemens korrigierten Build, nur für IoT2050 Advanced-GatewaysEine von dir angegebene Einstellungsdatei (--settings settings.js): bewertet auf ein aktives, nicht auskommentiertes adminAuth, für jede eigenständige Node-RED-InstallationDieser Host (--local): die settings.js in den üblichen Node-RED-Benutzerverzeichnissen, oder NOT FOUNDEine von dir angegebene Flows-Datei (--flows flows.json): ein Offline-Audit auf Kompromittierungsindikatoren, bewertet als REVIEW, niemals allein als KompromittierungsurteilEin Offline-Inventar (--inventory-json inventory.json): eine JSON-Liste von {name, industrial_os}-Einträgen, für eine Flotte von GatewaysDie vollständige Tabelle (--list): der betroffene Bereich und der korrigierte BuildDie Falle: Dies ist eine Konfigurationsschwachstelle, keine VersionsschwachstelleSignal | Betroffen | Korrigiert |
|---|---|---|
SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2), Industrial OS mit installiertem Node-RED | unter V4.3.4.1 | V4.3.4.1 oder später |
Eigenständiges Node-RED, jede Version | settings.js ohne aktives adminAuth | adminAuth gesetzt, oder disableEditor: true |
Bewerte keine Node-RED-Versionsnummer gegen diese CVE. Es gibt keine Node-RED-Version, die sie behebt, denn die Schwachstelle ist fehlende Authentifizierung, kein Fehler in einer bestimmten Version. Ein Upgrade von Node-RED, während adminAuth nicht gesetzt bleibt, lässt den Editor genau so offen wie zuvor. Auf einem IoT2050 ist die Behebung das Industrial OS-Update auf V4.3.4.1 oder später, das die Authentifizierung an der Web-Schnittstelle erzwingt. Bei einer eigenständigen Installation ist die Behebung, adminAuth selbst in settings.js zu setzen.
Zwei weitere Dinge, die man nicht falsch machen sollte. Erstens: Ein auskommentiertes adminAuth ist keine Authentifizierung. Das Tool entfernt //- und /* */-Kommentare vor der Bewertung, sodass eine Einstellungsdatei, die adminAuth nur in einem Kommentar erwähnt, weiterhin als VULNERABLE bewertet wird. Zweitens: Ein exec-Node in einer Flows-Datei ist kein Beweis für eine Kompromittierung. Viele legitime Flows verwenden exec-Nodes, daher bewertet die Flows-Prüfung als REVIEW und teilt einem Menschen mit, was er sich ansehen sollte: exec-Nodes, http-in-Nodes, die mit exec-Nodes verbunden sind, und die beobachteten Dropper-Marker (/dev/shm-Drops, bot-linux-amd64). Eine CLEAN-Flows-Bewertung bedeutet, dass keiner dieser Marker in dieser Datei vorhanden ist, mehr nicht. Sie sagt nichts über Flows aus, die bereitgestellt und gelöscht wurden.
Verwendung# vulnerable gateway
python3 node_red_scanner.py --industrial-os 4.3.4.0
# fixed gateway
python3 node_red_scanner.py --industrial-os 4.3.4.1
# standalone install, open editor
python3 node_red_scanner.py --settings ~/.node-red/settings.js
# offline compromise-indicator audit of a flows file you own
python3 node_red_scanner.py --flows flows.json
# on the host itself
python3 node_red_scanner.py --local
# machine-readable output for fleets
python3 node_red_scanner.py --industrial-os 4.3.4.0 --json
# the full fixed-version table
python3 node_red_scanner.py --list
Exit-Codes: 0 = nichts Verwundbares gefunden, 2 = verwundbar oder Prüfungsbefund, 1 = Scanfehler. UNKNOWN ändert den Exit-Code nicht, ist aber nicht sauber.
Wo Quellen voneinander abweichen und was noch unbestätigt istZuerst die Zeitlinie. Siemens veröffentlichte den Advisory SSA-834709 am 11. August 2026, und der CISA-Advisory ICSA-26-237-03 folgte im selben Monat. Zu diesem Zeitpunkt meldete CISA keine bestätigte Ausnutzung in freier Wildbahn. Das änderte sich Ende Oktober: VulnCheck erfasste die Ausnutzung am 30. Oktober, meldete sie am 2. November, und The Register berichtete am selben Tag darüber. Dieses Tool folgt den Ausnutzungsnachweisen vom November, nicht der Position vom August, und sagt das klar: Dies ist eine neu ausgenutzte Schwachstelle, keine neu offengelegte. Der Trend-Auslöser hier ist der Ausnutzungsbericht vom 2. November, innerhalb der letzten 72 Stunden.
Zweitens der KEV-Status. Zum Zeitpunkt dieses Builds befindet sich die Schwachstelle laut sowohl VulnCheck als auch The Register im KEV-Katalog von VulnCheck, nicht im KEV von CISA. Zitiere sie nicht als CISA KEV-Eintrag, bis CISA sie listet.
Drittens der Geltungsbereich. Der Siemens-Advisory deckt nur SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) ab, das Industrial OS mit installiertem Node-RED ausführt. Die zugrunde liegende Bedingung – ein nicht authentifizierter Node-RED-Editor – gilt für jede Node-RED-Installation ohne adminAuth, und die Einstellungsprüfung bewertet das separat, gekennzeichnet als eigenständige Bewertung, nicht als Anspruch auf einen Siemens-Bereich. VulnCheck merkt an, dass die Emerson-Dokumentation ebenfalls die Nutzung von Node-RED hervorhebt, aber nicht validiert hat, ob deren Produkte betroffen sind; dieses Tool trifft keine Aussage über Emerson-Komponenten.
Viertens wurde zum Zeitpunkt dieses Builds kein weithin verfügbarer lokaler Triage-Scanner für diese Schwachstelle gefunden. Was existiert, ist Log-Erkennung: Sigma- / Splunk- / KQL-Regeln für das Deploy-Muster POST /flows sowie die eigene Erkennung von VulnCheck. Diese überwachen den Datenverkehr im Nachhinein. Dieses Tool ist die andere Seite davon: eine Offline-Prüfung der Version und der Konfiguration, bevor irgendetwas bereitgestellt wird. Falls ein eigenständiger Scanner dies bereits gut abdeckt, öffne ein issue und sag es.
Gegenmaßnahmen, wenn du heute nicht patchen kannst