Node-RED-Sicherheitslücke CVE-2026-58115: Wer betroffen ist und wie adminAuth schützt

Node-RED im Einsatz und unklar, ob die Instanz ohne Anmeldung erreichbar ist? WZ-IT prüft Node-RED-Instanzen auf Erreichbarkeit und Konfiguration, richtet adminAuth und den Zugriff über VPN ein und betreibt Node-RED mit Monitoring und Wartung, siehe Node-RED, IoT und CVE-Monitoring. Termin vereinbaren

Am 11. August 2026 hat Siemens das Advisory SSA-834709 zu fehlender Authentifizierung in Node-RED auf SIMATIC-IoT2050-Geräten veröffentlicht, mit der Kennung CVE-2026-58115 und CVSS 10.0. Am 2. November 2026 berichtete VulnCheck, dass ein Honeypot am 30. Oktober einen vollständigen Angriff aufgezeichnet hat: Ein einziger Request an die Admin-API übergab einen Flow, der einen Linux-Bot nachladen und starten sollte. Medien wie The Register berichteten ab dem 2. November.

Die Berichte vermischen zwei Dinge. Die Kennung gehört zu einem Siemens-Produkt. Der beobachtete Angriff trifft aber nach Angabe von VulnCheck Node-RED-Instanzen ohne adminAuth. Dieser Beitrag trennt beides anhand der Primärquellen, nennt Versionen, Bewertung und Ausnutzungsstatus in Tabellen und liefert Prüfbefehle und ein Konfigurationsbeispiel für Administratoren. Alle Angaben haben den Stand 9. November 2026.

Inhaltsverzeichnis

1. Die Lücke in Kürze
2. Kernlücke oder Produktlücke: Was die Quellen sagen
3. Betroffene Geräte und Fixversion
4. Was VulnCheck beobachtet hat
5. Exploit-Status und KEV
6. Welche Node-RED-Installationen gefährdet sind
7. Prüfbefehle für Administratoren
8. adminAuth in der settings.js einrichten
9. Editor nicht öffentlich erreichbar machen
10. Anzeichen einer Kompromittierung
11. Checkliste: Node-RED absichern
12. Unser Vorgehen bei WZ-IT
13. Weiterführende Guides

Die Lücke in Kürze

Quellen: Siemens SSA-834709, NVD CVE-2026-58115, VulnCheck.

Der Vektor beschreibt eine Lücke, die über das Netz ohne Rechte und ohne Nutzerinteraktion ausnutzbar ist. S:C (Scope Changed) bedeutet nach der CVSS-3.1-Spezifikation, dass die Schwachstelle Ressourcen in Komponenten jenseits ihres eigenen Sicherheitsbereichs beeinträchtigen kann. Siemens hat die Lücke so eingestuft.

Kernlücke oder Produktlücke: Was die Quellen sagen

Die Frage, ob CVE-2026-58115 eine Lücke in Node-RED selbst ist, beantworten die Quellen auf drei Ebenen unterschiedlich.

Einordnung. Nach den Quellen ist CVE-2026-58115 eine Produktlücke von Siemens: Auf den betroffenen Geräten wird für die Node-RED-HTTP-Schnittstelle keine Anmeldung erzwungen ("do not enforce authentication"). Für den Node-RED-Kern haben wir weder einen Fix noch ein Advisory gefunden, und das Projekt dokumentiert den offenen Zustand ohne Konfiguration als Standard. Nach unserer Einschätzung ist das keine Schwachstelle im Code von Node-RED, sondern ein Betriebszustand: Der Angriff funktioniert gegen Instanzen, deren Admin-API ohne Anmeldung erreichbar ist, etwa im Auslieferungszustand ohne adminAuth, sobald der Angreifer den Port erreicht. Dass VulnCheck die Siemens-Kennung für alle diese Instanzen verwendet, ist eine Zuordnung von VulnCheck und steht so nicht in der Siemens-Advisory. VulnCheck weist selbst darauf hin, dass die Beschreibung auf der Canary-Signatur und dem beobachteten Verkehr beruht. Ein Statement des Node-RED-Projekts zu dem Fall haben wir nicht gefunden.

Die Fehlerklasse ist nicht neu. Für den Industrie-PC IndustrialPI 4 von Pilz gilt seit 2025 dasselbe Muster: VDE-2025-045 beschreibt, dass für den Node-RED-Server standardmäßig keine Authentifizierung konfiguriert ist, ebenfalls mit CVSS 10.0. Die folgende Tabelle grenzt die Fälle voneinander ab; FUXA ist ein anderes Produkt, das Node-RED nur als Plugin einbindet.

Betroffene Geräte und Fixversion

Quelle: Siemens SSA-834709, Stand Revision V1.1 vom 4. November 2026.

Fünf Hinweise zur Einordnung:

• Nur mit installiertem Node-RED. Die Advisory gilt für Geräte, auf denen Industrial OS mit Node-RED läuft. Ohne installiertes Node-RED besteht diese Angriffsfläche nicht.
• Modellliste. Die Revision V1.1 vom 4. November hat laut Revisionshistorie die Liste der betroffenen Produkte präzisiert sowie Titel und Zusammenfassung angepasst. Die CISA-Meldung ICSA-26-237-03 führt dagegen nur die IoT2050 Advanced. Maßgeblich ist die aktuelle Siemens-Fassung mit vier Modellen.
• Schreibweise der Version. Siemens schreibt V4.3.4-1, die maschinenlesbare Fassung (CSAF) und manche Datenbanken 4.3.4.1. Gemeint ist derselbe Stand.
• Maßnahmen ohne Update. Siemens nennt zwei: Node-RED deinstallieren oder die Installation nach dem Node-RED-Handbuch härten. Außerdem sollen Geräte nur in einem geschützten Netz betrieben werden, nach den Industrial-Security-Richtlinien von Siemens.
• Was die Advisory nicht sagt. Sie nennt keinen Befehl, mit dem sich die installierte Version auslesen lässt, und beschreibt nicht, welche Anmeldung das behobene Image voreinstellt. Die Version ist nach den Siemens-Produktunterlagen zu ermitteln; ob der Zugang nach dem Update geschützt ist, zeigen die Prüfbefehle weiter unten.

Was VulnCheck beobachtet hat

VulnCheck beschreibt die Beobachtung im Bericht Exploitation Targeting Node-RED (2. November 2026, Update vom 1. November). Die Angaben stammen aus der Canary-Telemetrie von VulnCheck, einer Honeypot-Infrastruktur.

Ablauf des Angriffs. Ein einzelner POST /flows (User-Agent curl/8.5.0) übergibt einen Flow aus drei Teilen: ein leeres Tab, ein inject-Node, der einmal nach einer Sekunde auslöst, und ein exec-Node. Der exec-Node führt aus, was eine base64-kodierte Zeichenkette enthält, sodass einfache Filter auf wget oder curl im Request-Body nichts finden. Der Canary antwortete wie eine verwundbare Instanz mit HTTP 200 und einem neuen Revisions-Hash; deshalb wertet die VulnCheck-Signatur das Ereignis als erfolgreiche Ausnutzung. Der Ablauf ergibt sich aus dem entschlüsselten Befehl; einen Download oder eine Ausführung auf dem Canary weist der Bericht nicht aus.

Was unbekannt ist. VulnCheck hat weder die Bot-Datei noch wget.sh oder .kworker beschafft. Ob es sich um einen Kryptominer, einen DDoS-Bot, eine Reverse Shell oder etwas anderes handelt, ist offen. Der Bericht nennt keine Hashes. Dieselbe Adresse hat laut VulnCheck in den vergangenen Tagen insgesamt 125 Treffer gegen acht CVEs in Apache Solr, Camunda, Gitea, MLflow, Traefik, Joomla und Node-RED erzielt; VulnCheck liest das als opportunistisches Massenscannen und nicht als gezielten Angriff, und betont, dass die Adresse in der Microsoft-Cloud wenig über den Betreiber sagt.

Exploit-Status und KEV

Zahlen zu offen erreichbaren Instanzen nennt keine der geprüften Quellen, und wir haben keine eigenen Scan-Daten. Eine Angabe wie "Tausende offene Instanzen" ist deshalb nicht belegt.

Welche Node-RED-Installationen gefährdet sind

Drei Annahmen, die sich nicht halten lassen:

• "Es ist ein Node-RED-Bug, also hilft ein Update." Die Releases 5.0.9 und 4.1.17 ändern den Standard nicht; die Anmeldung muss konfiguriert werden.
• "Die Instanz steht hinter einer Firewall." Das verringert die Angreifer auf Hosts mit Netzzugang, schützt aber nicht vor jedem Rechner im selben Netz. Bei Docker kommt hinzu, dass veröffentlichte Ports an den Firewall-Regeln von ufw vorbeilaufen (siehe unten).
• "Ein geänderter Pfad für den Editor schützt." httpAdminRoot verschiebt die Pfade, ist aber keine Zugriffskontrolle.

Prüfbefehle für Administratoren

Alle Befehle dürfen nur gegen eigene Systeme laufen. Die Ausgaben zeigen, wie die Instanz im Netz steht.

1. Auf welcher Adresse lauscht Node-RED?

sudo ss -tlnp | grep 1880

Steht in der Ausgabe 0.0.0.0:1880, *:1880 oder [::]:1880, lauscht der Prozess auf allen Schnittstellen. Bei 127.0.0.1:1880 ist er direkt nur lokal erreichbar; ein Proxy oder Tunnel auf dem Host kann ihn weiterreichen. Der Port 1880 ist der Standard (uiPort); wurde er geändert, die eigene Nummer einsetzen.

2. Docker: Wie ist der Port veröffentlicht?

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'

Unter Ports bedeutet 0.0.0.0:1880->1880/tcp oder [::]:1880->1880/tcp, dass der Port auf allen Schnittstellen des Hosts veröffentlicht ist. 127.0.0.1:1880->1880/tcp ist ab Docker 28.0.0 nur vom Host aus erreichbar (zu älteren Versionen siehe unten). Docker nennt veröffentlichte Ports "insecure by default" (Docker, Port publishing) und leitet den Verkehr vor den ufw-Regeln um, sodass eine ufw-Sperre veröffentlichte Ports nicht schützt (Docker, Packet filtering).

3. Ist die Anmeldung aktiv?

curl -s --max-time 5 http://127.0.0.1:1880/auth/login; echo
curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 http://127.0.0.1:1880/flows

Nach der Admin-API liefert /auth/login bei inaktiver Anmeldung {}. Bei aktiver Anmeldung kommt ein Objekt mit "type":"credentials", bei Anmeldung über Passport-Strategien mit "type":"strategy" (Quellcode). GET /flows antwortet ohne Token mit HTTP 200, wenn die Instanz offen ist oder ein anonymer Standardnutzer mit Leserecht eingerichtet ist (Dokumentation), und mit HTTP 401, wenn ein Token verlangt wird. Der Statuscode allein zeigt nicht, welche Komponente antwortet: Auch ein vorgeschalteter Proxy kann 401 liefern. Aussagekräftig ist die Kombination aus /auth/login und /flows. Einen Deploy-Versuch (POST /flows) enthält die Prüfung bewusst nicht. Hat die Instanz httpAdminRoot gesetzt, steht der Pfad dahinter, etwa /admin/flows.

4. Dieselbe Prüfung von einem anderen Rechner im Netz. 127.0.0.1 durch die Adresse des Servers ersetzen. Liefert /auth/login von dort {}, ist die Admin-API zumindest von diesem Rechner aus ohne Node-RED-Anmeldung erreichbar; ob das für andere Quelladressen genauso gilt, hängt von vorgeschalteten Kontrollen wie Firewall oder Proxy ab. Liefert /flows HTTP 200 und ist die Antwort ein JSON-Array mit Node-Objekten, ist mindestens Lesezugriff möglich; ein Statuscode 200 allein kann auch von einer Proxy- oder Fallback-Seite stammen. Mit einem kleinen Skript lassen sich mehrere Instanzen nacheinander prüfen:

#!/usr/bin/env bash
# Prüft eine eigene Node-RED-Instanz: Ist die Admin-API ohne Anmeldung erreichbar?
# Aufruf: ./check-nodered.sh http://192.0.2.10:1880
BASE="${1:-http://127.0.0.1:1880}"

login=$(curl -s --max-time 5 "$BASE/auth/login")
echo "Anmeldeschema (GET /auth/login): ${login:-keine Antwort}"

code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "$BASE/flows")
echo "GET /flows ohne Token: HTTP $code"
case "$code" in
  200)
    if [ "$login" = "{}" ]; then
      echo "-> OFFEN: keine Anmeldung aktiv, Flows lesbar, Deploy ohne Anmeldung zu erwarten"
    else
      echo "-> Flows ohne Token lesbar, Anmeldung aktiv: anonymen Standardnutzer und dessen Rechte prüfen"
    fi ;;
  401) echo "-> Token verlangt (adminAuth oder vorgeschaltete Zugriffskontrolle)" ;;
  000) echo "-> nicht erreichbar" ;;
  *)   echo "-> unerwartet, Pfad-Präfix (httpAdminRoot) und Proxy prüfen" ;;
esac

Das Skript haben wir gegen einen lokalen Testserver geprüft, der die in der Admin-API-Dokumentation beschriebenen Antworten nachbildet: offene Instanz, aktive Anmeldung, anonymer Lesezugriff, Statuscode 401 ohne Anmeldeschema, unerwarteter Statuscode und nicht erreichbarer Server. Eine echte Node-RED-Instanz war nicht Teil des Tests.

adminAuth in der settings.js einrichten

Die Einstellung adminAuth schützt den Editor und die Admin-API. In der mitgelieferten settings.js ist sie auskommentiert (Vorlage im Repository). Die Datei liegt bei einer Installation per Skript im Benutzerverzeichnis ~/.node-red/settings.js, im offiziellen Docker-Image unter /data/settings.js. Welche Datei Node-RED lädt, steht beim Start in der Log-Zeile "Settings file".

Schritt 1: Passwort-Hash erzeugen.

node-red admin hash-pw

Der Befehl existiert ab Node-RED 1.1.0 und fragt das Passwort ab. Im Docker-Container läuft er so, wie es das Docker-Image vorsieht:

docker exec -it mynodered npx node-red admin hash-pw

Der ausgegebene Wert ist ein bcrypt-Hash und beginnt mit $2a$ oder $2b$. Die Beispiel-Hashes aus der Dokumentation gehören zu bekannten Passwörtern und dürfen nicht übernommen werden.

Schritt 2: Block in der settings.js eintragen. Die folgende Konfiguration folgt der offiziellen Anleitung; Hashes sind Platzhalter:

module.exports = {
    uiPort: process.env.PORT || 1880,

    // Gesamten HTTP-Listener (Editor, Admin-API, HTTP-In, Dashboard) nur auf dem lokalen Host
    // oder einer VPN-Adresse annehmen (im Docker-Container weglassen, siehe unten)
    uiHost: "127.0.0.1",

    // Editor und Admin-API: Anmeldung erzwingen
    adminAuth: {
        type: "credentials",
        users: [
            {
                username: "admin",
                password: "$2b$08$HASH-AUS-hash-pw-HIER-EINTRAGEN",
                permissions: "*"
            },
            {
                username: "lesezugriff",
                password: "$2b$08$ANDERER-HASH-AUS-hash-pw",
                permissions: "read"
            }
        ],
        sessionExpiryTime: 86400
    },

    // HTTP-In-Routen und node-red-dashboard: eigener Benutzer, eigener Hash
    httpNodeAuth: { user: "dashboard", pass: "$2b$08$DRITTER-HASH-AUS-hash-pw" }
};

In einer vorhandenen settings.js werden nur die Zeilen uiHost, adminAuth und httpNodeAuth ergänzt oder einkommentiert; der übrige Inhalt bleibt. Im Docker-Container entfällt uiHost (siehe unten). Die Syntax des Beispiels haben wir mit Node.js geladen und geprüft; mit einer laufenden Node-RED-Instanz haben wir es nicht getestet.

Schritt 3: Node-RED neu starten.

Schritt 4: Ergebnis prüfen. GET /auth/login zeigt "type":"credentials", und GET /flows liefert ohne Token HTTP 401 (Prüfbefehl 3), solange kein anonymer Standardnutzer eingerichtet ist. Erscheint beim Öffnen des Editors kein Anmeldedialog, wurde meist eine andere Datei bearbeitet als die, die Node-RED lädt, oder der Dienst wurde nicht neu gestartet.

Quelle: Node-RED, Securing Node-RED und Konfiguration. Über permissions: "read" lassen sich Nutzer mit reinem Lesezugriff anlegen; mit default: { permissions: "read" } in adminAuth erhält zusätzlich jeder ohne Anmeldung diesen Lesezugriff, was die Anleitung als Option beschreibt. Die Rechte des Standardnutzers sind frei wählbar; mit permissions: "*" hätte jeder ohne Anmeldung auch Schreibzugriff. Vorgeschaltete Zugriffskontrollen wie ein Reverse Proxy oder httpAdminMiddleware können die Admin-API ebenfalls absichern; adminAuth ist die in der Anleitung beschriebene Standardlösung. Wer den Editor über OAuth oder OpenID anmelden möchte, findet in der Anleitung die Variante mit Passport-Strategien.

Editor nicht öffentlich erreichbar machen

adminAuth ist die erste Schicht. Die zweite ist, dass der Editor gar nicht erst aus dem Internet erreichbar ist. Das Admin-Interface braucht in der Regel nur ein kleiner Kreis von Administratoren.

• Nur lokal oder an einer VPN-Adresse binden. Mit uiHost: "127.0.0.1" lauscht Node-RED nur lokal, und zwar mit dem gesamten HTTP-Listener: Auch HTTP-In-Routen und Dashboards sind dann nur lokal erreichbar. Soll der Editor über ein privates Netz erreichbar sein, kann uiHost auf die VPN-Adresse des Hosts zeigen. Standard ist 0.0.0.0, also alle IPv4-Schnittstellen (Konfigurationsdokumentation). Im Docker-Container bleibt uiHost unverändert (siehe nächster Punkt).

• Docker-Port nur an localhost veröffentlichen. Docker leitet veröffentlichte Ports im Standard-Bridge-Netz an die Adresse des Containers weiter; ein Prozess, der im Container nur auf 127.0.0.1 lauscht, nimmt diese Verbindungen nicht an. Node-RED bleibt im Container deshalb bei 0.0.0.0, und die Begrenzung steht allein in der Host-Adresse des -p-Flags. Statt -p 1880:1880 den Port mit Adresse angeben:

  docker run -d -p 127.0.0.1:1880:1880 -v node_red_data:/data --name mynodered nodered/node-red
  

  In Compose lautet der Eintrag "127.0.0.1:1880:1880" unter ports. In Docker-Versionen vor 28.0.0 konnten Rechner im selben Layer-2-Segment auch an localhost veröffentlichte Ports erreichen (Docker, Port publishing); bei älteren Docker-Hosts ist ein Update ratsam.

• Zugriff über Mesh-VPN oder WireGuard. Administratoren erreichen den Editor dann nur mit einem Gerät, das im privaten Netz angemeldet ist. Das Muster beschreiben die Seiten zu VPN und Secure Access und zu NetBird sowie der Beitrag VPN ablösen: Zero Trust und Mesh-VPN.

• Reverse Proxy nur für HTTP-In-Pfade. Müssen Webhooks oder ein Dashboard öffentlich sein, gehören nur die dafür vorgesehenen Pfade (httpNodeRoot, etwa /ui) hinter den Proxy, mit httpNodeAuth oder einem Token im Flow. Die Pfade der Admin-API (/flows, /auth, /settings, /nodes) bleiben draußen. Der Editor hält eine WebSocket-Verbindung zur Runtime offen (Quellcode comms.js); läuft er hinter einem Proxy, muss dieser sie weiterreichen.

• Firewall am Perimeter. Port 1880 am Eingang des Netzes sperren und das Ergebnis von außen prüfen, nicht nur die Regel lesen.

• Keine unnötigen Rechte. Node-RED als eigener Benutzer betreiben statt als root. Für den Container gilt dasselbe; wo es nicht nötig ist, kein -u root und keinen Docker-Socket einhängen.

Diese Schichten ersetzen adminAuth nicht, sondern ergänzen es. Sind VPN und adminAuth unabhängig voneinander konfiguriert, reicht ein Fehler in einer der beiden Schichten allein in der Regel nicht für einen Zugriff; eine Garantie ist das nicht.

Anzeichen einer Kompromittierung

Die Prüfpunkte folgen den Spuren aus dem VulnCheck-Bericht. Dass sie nicht gefunden werden, beweist keine Sauberkeit: Die Angreifer können Dateinamen und Adressen wechseln, und VulnCheck kennt die Funktion der Schadsoftware nicht.

# Flows mit Befehlsausführung oder eingehenden HTTP-Routen auflisten
jq -r '.[] | select(.type=="exec" or .type=="http in") | [.type, .id, (.command // .url // "")] | @tsv' ~/.node-red/flows.json

# Ohne jq
grep -n -E '"type": ?"(exec|http in)"' ~/.node-red/flows.json

# Spuren aus dem VulnCheck-Bericht auf dem Host
ls -la /dev/shm/.b /tmp/.s /tmp/.kworker 2>/dev/null
ps -eo pid,user,args | grep -E '/dev/shm|\.kworker|\.sys_update' | grep -v grep
sudo ss -tnp | grep -E '85\.215\.73\.250|45\.194\.90\.57'

Bei Docker liegt die Datei im Volume; der Inhalt lässt sich mit docker exec mynodered cat /data/flows.json | jq ... auswerten. Die Pfade gelten für die Standardeinstellungen; flowFile und userDir in der settings.js sowie Node-RED-Projekte können sie verschieben. Ein exec-Node ist nicht von sich aus verdächtig, viele Flows nutzen ihn legitim. Auffällig sind exec-Nodes ohne bekannten Zweck, mit kodierten Befehlen oder hinter einem HTTP-In-Endpunkt.

Wenn Spuren vorliegen oder ein Missbrauch nicht auszuschließen ist:

1. Instanz vom Netz trennen, Flows-Datei, Logs und Prozessliste sichern, bevor etwas verändert wird.
2. Alle auf dem Host lesbaren Zugangsdaten als kompromittiert behandeln und rotieren: Zugänge aus Flows (MQTT, Datenbanken, APIs), SSH-Schlüssel, Cloud-Token. Das ist unsere Einschätzung; die Quellen nennen keine Liste.
3. Host oder Container aus einem sauberen Zustand neu aufsetzen und die Flows vor der Wiederverwendung Node für Node prüfen. Ein Update allein entfernt eingeschleuste Flows nicht.
4. adminAuth und die Netzbeschränkung setzen, bevor die Instanz wieder ans Netz geht.
5. Meldepflichten prüfen. Eine Verletzung des Schutzes personenbezogener Daten hat der Verantwortliche nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden der Aufsichtsbehörde zu melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen; ein Auftragsverarbeiter meldet eine Verletzung dem Verantwortlichen unverzüglich. Bei voraussichtlich hohem Risiko benachrichtigt der Verantwortliche nach Art. 34 DSGVO auch die Betroffenen unverzüglich, vorbehaltlich der Ausnahmen in Art. 34 Abs. 3 (EDPB). Einrichtungen im Anwendungsbereich der NIS-2-Richtlinie übermitteln zu erheblichen Sicherheitsvorfällen nach Art. 23 Abs. 4 eine Frühwarnung unverzüglich und spätestens binnen 24 Stunden nach Kenntnis des Vorfalls, eine Vorfallmeldung binnen 72 Stunden nach Kenntnis (Vertrauensdiensteanbieter: 24 Stunden), auf Anforderung einen Zwischenbericht und spätestens einen Monat nach der Vorfallmeldung einen Abschlussbericht; dauert der Vorfall dann noch an, folgen ein Fortschrittsbericht und der Abschlussbericht binnen eines Monats nach Behandlung des Vorfalls. Anwendungsbereich und Einzelheiten richten sich nach dem nationalen Umsetzungsrecht. Welche Pflicht greift, hängt von der Rolle (Verantwortlicher oder Auftragsverarbeiter), davon ab, ob personenbezogene Daten betroffen waren, ob die Einrichtung erfasst ist und wie erheblich der Vorfall ist. Die Bewertung im Einzelfall sollte mit dem Datenschutzbeauftragten oder der Rechtsberatung erfolgen; die Verantwortung bleibt beim jeweils Verpflichteten.

Checkliste: Node-RED absichern

Unser Vorgehen bei WZ-IT

WZ-IT installiert, hostet und betreibt Node-RED mit Monitoring, Backups und Wartung und bindet im Rahmen der IoT-Leistungen SPS- und HMI-Systeme an. Bei einer Meldung wie CVE-2026-58115 läuft die Arbeit in fünf Schritten:

1. Bestand erfassen. Node-RED-Instanzen, Versionen, Ports, Container-Zuordnungen und Geräte wie die IoT2050 aufnehmen, auch solche, die ein anderes Team angelegt hat.
2. Erreichbarkeit prüfen. Mit den Befehlen oben feststellen, ob Admin-API und Editor ohne Anmeldung erreichbar sind, von innen und von außen.
3. Absichern. adminAuth und httpNodeAuth setzen, Bindung und Port-Zuordnung einschränken und den Zugriff über ein Mesh-VPN oder WireGuard legen. Bei IoT2050-Geräten richtet sich das Vorgehen nach der Siemens-Advisory.
4. Spuren prüfen. Flows und Host auf die Indikatoren durchsehen; bei Verdacht Zugangsdaten kontrolliert rotieren und die Instanz sauber neu aufsetzen.
5. Dauerhaft überwachen. Instanzen in das CVE-Monitoring aufnehmen, das neben der NVD auch Hersteller-Advisories auswertet. Eine breitere Prüfung von Konfiguration und Zugängen eines Servers leistet das Server-Audit.

Support, Beratung und Implementierung durch WZ-IT.

Weiterführende Guides

• Node-RED MQTT-Dashboard für Sensordaten, wie Node-RED Messwerte aufnimmt und darstellt.
• n8n Alternative: n8n, Activepieces und Node-RED im Vergleich, Lizenz, Betrieb und Sicherheitsmeldungen der drei Werkzeuge.
• ThingsBoard, Grafana & ChirpStack im IoT-Stack, wo Node-RED im IoT-Betrieb sitzt.
• CVE-Monitoring für Self-Hosted Software, wie Schwachstellen strukturiert verfolgt werden.
• VPN ablösen: Zero Trust und Mesh-VPN, Zugang zu internen Diensten ohne öffentliche Ports.
• LiteLLM-Sicherheitslücke: Versionen prüfen und Gateway absichern, ein weiterer Fall, in dem eine Verwaltungsoberfläche abgesichert werden muss.
• IoT-Leistungen von WZ-IT und Node-RED-Betrieb, die Hubs zu diesem Thema.
• SSHole (CVE-2026-123158): OpenSSH bei Alpine prüfen - weiterer aktueller Sicherheitsfall (Stand November 2026)
• Kernel-TCP-Lücke CVE-2026-98432: Proxmox, Debian, Ubuntu patchen - weiterer aktueller Sicherheitsfall (Stand November 2026)
• APT-Lücke CVE-2026-109518 in Debian und Ubuntu - weiterer aktueller Sicherheitsfall (Stand November 2026)
• CWPdoor: Hintertür im Control Web Panel prüfen - weiterer aktueller Sicherheitsfall (Stand November 2026)

Node-RED-Instanzen prüfen lassen? Wir stellen fest, welche Instanzen ohne Anmeldung erreichbar sind, setzen adminAuth und den Zugang über VPN um und nehmen Node-RED in das CVE-Monitoring auf. Termin vereinbaren

Quellen

• Siemens ProductCERT, SSA-834709 (CVE-2026-58115)
• NVD, CVE-2026-58115
• CISA, ICSA-26-237-03 Siemens SIMATIC IoT2050 Advanced
• CISA, Known Exploited Vulnerabilities Catalog
• VulnCheck, Exploitation Targeting Node-RED, a Tool Embedded in ICS Products
• The Register, Node-RED flaw exploited (2. November 2026)
• Node-RED Docs, Securing Node-RED
• Node-RED Docs, Runtime-Konfiguration
• Node-RED Docs, Admin API: GET /auth/login
• Node-RED Docs, Admin API: GET /flows
• Node-RED Docs, Admin API: POST /flows
• Node-RED Docs, Docker
• Node-RED Docs, Raspberry Pi
• node-red-docker, README
• Node-RED, settings.js (Vorlage)
• Node-RED, Security Advisories
• Node-RED, Changelog
• Node-RED, Release 4.1.17
• Node-RED, Quellcode editor-api comms.js
• Node-RED, Quellcode editor-api auth/index.js
• Docker Docs, Port publishing and mapping
• Docker Docs, Packet filtering and firewalls
• CERT@VDE, VDE-2025-045 Pilz IndustrialPI
• NVD, CVE-2025-41656
• NVD, CVE-2026-25938
• FUXA, Security Advisory GHSA-v4p5-w6r3-2x4f
• Cisco Talos, TALOS-2026-2419 (FUXA)
• NVD, CVE-2026-42922
• FIRST, CVSS v3.1 Specification Document
• EDPB, Data breaches
• EUR-Lex, Richtlinie (EU) 2022/2555 (NIS 2)
• Siemens, Operational Guidelines for Industrial Security