RCE Node-RED sur Siemens IoT2050, exploitée en conditions réelles (CVE-2026-58115)

TL;DR

• Les passerelles industrielles SIMATIC IoT2050 Advanced exécutent Node-RED sans authentification sur son interface HTTP : quiconque peut joindre l’équipement déploie des flux qui exécutent des commandes shell. Siemens a divulgué la faille le 11 août 2026 et la note CVSS v3.1 et v4.0 10,0.
• Tout SIMATIC IoT2050 Advanced (référence 6ES7647-0BA00-1YA2) antérieur à l’image V4.3.4.1 est touché. VulnCheck ajoute que toute instance Node-RED sans adminAuth accepte le même déploiement en une requête.
• L’exploitation a lieu en conditions réelles : les canaris de VulnCheck ont enregistré des exploits complets à partir du 30 octobre 2026. Le CVE ne figure pas au catalogue KEV de la CISA au 3 novembre 2026 (flux vérifié) ; VulnCheck l’a ajouté à son propre catalogue.
• Mettez à jour chaque IoT2050 vers V4.3.4.1 ou plus récent. Pour chaque déploiement Node-RED, vérifiez que l’interface n’est pas joignable depuis l’extérieur et activez adminAuth. « Comment corriger ? » détaille le durcissement.

Suis-je concerné ?

Vous êtes exposé lorsque toutes ces conditions sont réunies :

• L’équipement est un SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) sous Industrial OS avec Node-RED installé, antérieur à l’image V4.3.4.1. Siemens ne liste aucun autre modèle touché.
• L’interface Node-RED est joignable par l’attaquant. Node-RED écoute sur toutes les interfaces IPv4 sur le port 1880 par défaut, d’après sa documentation de configuration.
• Aucune authentification n’est imposée sur cette interface. Sur l’IoT2050, Siemens indique que les équipements touchés n’imposent pas d’authentification sur l’interface HTTP de Node-RED.

La même attaque par déploiement fonctionne contre toute instance Node-RED non sécurisée, pas seulement les équipements Siemens. Node-RED est largement déployé : le paquet node-red enregistre 92 432 téléchargements npm hebdomadaires, et son image Docker officielle totalise 327 470 066 téléchargements. Les deux chiffres ont été vérifiés le 3 novembre 2026.

Vérifiez ce que vous exécutez sur chaque hôte et sur la passerelle :

# Node-RED on any host: which interface and port it listens on
ss -tlnp | grep ':1880 '

# Node-RED on any host: is editor authentication configured?
grep -n "adminAuth" ~/.node-red/settings.js

Une ligne adminAuth restée en commentaire, commençant par //, signifie que l’éditeur et l’API Admin acceptent les requêtes sans identifiant. Depuis l’extérieur de votre réseau, essayez d’ouvrir l’URL de l’éditeur de chaque déploiement, http://<host>:1880.

Un éditeur qui se charge sans invite de connexion est exposé. Pour l’IoT2050, comparez la version d’image Industrial OS déployée avec V4.3.4.1 ; l’entrée de mise à jour est 109741799 sur le portail Siemens Industry Online Support.

Comment corriger ?

Mettez à jour la passerelle, puis durcissez chaque autre déploiement Node-RED :

1. Mettez à jour chaque SIMATIC IoT2050 Advanced touché vers V4.3.4.1 ou plus récent, depuis l’entrée support Siemens 109741799. Siemens a publié l’image corrigée et recommande la mise à jour.
2. Sur chaque autre déploiement Node-RED, activez l’authentification de l’éditeur et de l’API Admin en décommentant et remplissant la propriété adminAuth du fichier de configuration, puis redémarrez Node-RED :

// ~/.node-red/settings.js, adapted from the Node-RED securing guide
adminAuth: {
    type: "credentials",
    users: [ {
        username: "admin",
        password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
        permissions: "*"
    } ]
}

Remplacez le hash d’exemple, que le guide utilise pour le mot de passe password, par un hash généré avec node-red admin hash-pw.

1. Activez l’accès HTTPS, puis protégez les HTTP Nodes et le tableau de bord Node-RED avec une authentification basique ou un fournisseur OAuth/OpenID. Siemens recommande ces trois mêmes étapes, ou la désinstallation pure et simple de Node-RED.

Aucune version de Node-RED ne corrige cela seule, donc mettre à jour le paquet npm ne change rien. Si l’éditeur n’est pas nécessaire sur un hôte, désactivez entièrement les points de terminaison admin en définissant httpAdminRoot: false dans le fichier de configuration.

La recommandation générale de Siemens est de protéger l’accès réseau aux équipements par des mécanismes appropriés : gardez le port 1880 hors des réseaux non fiables après la mise à jour.

Quelle est la cause racine ?

L’éditeur et l’API Admin de Node-RED servent une interface HTTP qui exécute des commandes par conception, et les équipements touchés n’y imposent aucune authentification.

Node-RED est un outil de programmation par flux bâti sur Node.js : un opérateur câble des nœuds dans un éditeur navigateur, et le serveur exécute ce que les flux décrivent. Deux types de nœuds intégrés rendent l’interface directement dangereuse.

Un nœud inject déclenche un message selon une planification ou une fois au démarrage, et un nœud exec exécute une commande système sur l’hôte.

L’API Admin expose ce pouvoir sur HTTP. Son point de terminaison POST /flows « définit la configuration de flux active » et requiert la permission flows.write, documentée avec l’en-tête Authorization: Bearer [token] seulement « si l’authentification est activée ».

Le guide de sécurisation énonce la valeur par défaut sans détour : « By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes. »

Sur l’IoT2050, l’avis de Siemens décrit la conséquence : les équipements touchés n’imposent pas d’authentification sur l’interface HTTP de Node-RED. Cela donne un accès sans authentification aux nœuds de programmation qui exécutent des commandes système. L’enregistrement CVE le classe en CWE-306, Missing Authentication for Critical Function.

Node-RED livre cet état par défaut parce que l’outil suppose un réseau de confiance, comme l’indique sa documentation. Sur une passerelle industrielle à interface joignable, cette hypothèse tombe.

Comment la faille est-elle exploitée ?

La preuve de concept publique est le trafic d’exploit lui-même, décodé et publié par VulnCheck le 2 novembre 2026 :

1. L’attaquant envoie une seule requête POST /flows à l’interface Node-RED. La requête captée par VulnCheck le 30 octobre 2026 provenait de curl/8.5.0.
2. Le corps transporte un flux de trois nœuds : un onglet vide, un nœud inject et un nœud exec. Le nœud inject se déclenche une fois après une seconde. C’est l’encodage de premier niveau, cité depuis l’analyse :

{"flows":[
  {"id":"t","type":"tab"},
  {"id":"inj","type":"inject","z":"t","once":true,"onceDelay":"1","wires":[["e"]]},
  {"id":"e","type":"exec","z":"t","command":"echo <base64> | base64 -d | sh","addpay":false,"wires":[[],[],[]]}
]}

1. L’interface répond HTTP/1.1 200 OK avec un nouveau hash de révision du flux, ce qui fait enregistrer l’événement comme un exploit réussi.
2. Une seconde après le déploiement, le nœud inject se déclenche. Le nœud exec exécute alors le dropper décodé. D’après le décodage de VulnCheck, il récupère un binaire via wget avec curl en repli, l’enregistre sous /dev/shm/.b, le rend exécutable, puis le lance détaché avec setsid ou nohup.

Le binaire n’a jamais été récupéré, donc VulnCheck ne fait aucune hypothèse sur ce qu’il fait. Des requêtes ultérieures de la même source variaient la charge : un script intermédiaire wget.sh, enregistré et lancé sous /tmp/.s, un implant enregistré sous /tmp/.kworker, et des flux qui ne déploient aucun téléchargeur.

Comment se déroule l’attaque ?

Une seule requête HTTP vers l’interface sans authentification déploie un flux qui exécute la commande de l’attaquant en une seconde.

Que peut faire un attaquant ?

L’impact démontré est l’exécution de commandes arbitraires sur l’hôte qui exécute Node-RED.

• Siemens évalue qu’un attaquant distant sans authentification peut créer des flux malveillants et « exécuter du code arbitraire sur le serveur sous-jacent avec des privilèges maximaux » via l’interface HTTP.
• VulnCheck a observé deux formes post-exploitation : des bots enregistrés dans /dev/shm en mémoire, et des webshells persistants. Les flux webshell exposent un point de terminaison HTTP, par exemple /cmd, câblé en passant par un nœud function vers un nœud exec avec addpay activé. L’attaquant passe ensuite ses commandes dans un paramètre de requête.
• Les conditions sont minimales : joignabilité réseau de l’interface, pas d’adminAuth, et aucune interaction utilisateur. VulnCheck décrit le déploiement comme une seule requête HTTP.

Aucune victime n’a été confirmée. Les événements de VulnCheck proviennent d’une seule adresse IP source, 4.201.105[.]116, et les charges n’ont pas été récupérées ni analysées : aucune affirmation n’est possible sur les capacités du bot.

Pourquoi le correctif fonctionne-t-il ?

La mise à jour V4.3.4.1 est le remède du fournisseur, et l’avis confirme que la plage touchée s’arrête en dessous. Siemens distribue une image industrielle en code fermé : aucun diff de correctif n’est public à citer.

Le correctif de configuration pour chaque autre déploiement Node-RED ferme exactement l’écart que l’exploit utilise. Définir adminAuth active l’authentification par identifiants sur l’éditeur et l’API Admin.

POST /flows exige alors l’en-tête Authorization: Bearer [token] décrit par la documentation de l’API, et une requête sans authentification est rejetée. Définir httpAdminRoot: false supprime entièrement les points de terminaison. Les étapes de durcissement restantes, HTTPS et authentification basique sur les HTTP Nodes et le tableau de bord, ferment les autres portes qu’un flux peut ouvrir.

Ces étapes réduisent le périmètre plutôt qu’elles ne changent Node-RED lui-même. Le nœud exec garde son pouvoir par conception ; le correctif fait que seuls des opérateurs authentifiés peuvent le câbler et le déployer.

Comment vérifier si j’ai été compromis ?

VulnCheck a publié les indicateurs issus de l’exploitation observée. Une correspondance est une piste à investiguer, pas une preuve de compromission, et une tentative échouée peut ne laisser aucune trace.

# Look for the dropped files on the Node-RED host
ls -la /dev/shm/.b /tmp/.kworker /tmp/.s 2>/dev/null

# Find every exec node and every HTTP endpoint in the deployed flows
grep -nE '"type": ?"exec"' ~/.node-red/flows*.json
grep -nE '"type": ?"http in"' ~/.node-red/flows*.json

Indicateurs réseau à bloquer et chercher dans les journaux de connexions, publiés par VulnCheck :

• 4.201.105[.]116, source de l’exploit dans l’ASN AS8075 de Microsoft. Elle a visé cette faille 16 fois entre le 30 octobre et le 1er novembre 2026.
• 85.215.73[.]250 sur le port 8080, serveur de charge pour bot-linux-amd64 et wget.sh.
• 45.194.90[.]57 sur le port 38472, serveur derrière l’implant .sys_update enregistré sous /tmp/.kworker.

Examinez les flux eux-mêmes pour repérer des nœuds que vous n’avez pas créés : un nœud exec avec une commande inattendue, ou un point de terminaison http in comme /cmd câblé vers un. Dans les journaux d’accès, cherchez des POST /flows de sources inconnues répondus en HTTP 200 avec un hash rev.

La page d’analyse de VulnCheck porte le tableau complet des indicateurs et ses artefacts d’accès initial pour la chasse.

Chronologie

• 2026-08-11 : Siemens publie l’avis SSA-834709 avec CVE-2026-58115, les scores CVSS et la version d’image corrigée V4.3.4.1.
• 2026-08-12 : L’évaluation CISA ADP dans l’enregistrement CVE note SSVC Exploitation « none » à cette date.
• 2026-10-27 : VulnCheck livre des artefacts de détection pour le CVE, dont un PoC d’exploit, un scanner de versions et des règles Suricata, Snort et YARA.
• 2026-10-30 : Les canaris de VulnCheck capturent le premier exploit complet, et VulnCheck ajoute le CVE à son propre catalogue KEV.
• 2026-10-30 au 2026-11-01 : La même adresse IP source envoie 16 événements contre la faille ; des charges intermédiaires et webshell apparaissent le 1er novembre.
• 2026-11-02 : VulnCheck publie l’analyse de l’exploitation.

FAQ

Le projet Node-RED lui-même est-il touché ?

Aucun CVE n’existe pour Node-RED, et aucune version de Node-RED ne corrige cela. Le CVE appartient au produit de Siemens, qui intègre l’outil sans imposer d’authentification sur son interface. La documentation de Node-RED indique que l’éditeur n’est pas sécurisé par défaut et ne convient qu’aux réseaux de confiance.

La faille figure-t-elle au catalogue KEV de la CISA ?

Non. Le flux JSON du catalogue ne comptait aucune entrée pour CVE-2026-58115 au 3 novembre 2026. VulnCheck l’a ajouté à son propre catalogue KEV le 30 octobre 2026, le jour où ses canaris ont capturé le premier exploit.

Quelqu’un a-t-il été compromis ?

Aucune victime n’est signalée. VulnCheck a enregistré des tentatives d’exploitation contre son réseau de canaris depuis une seule adresse IP et n’a pas récupéré les charges. Il ne fait aucune affirmation sur les capacités du bot.

L’évaluation CISA ADP notait Exploitation « none » le 12 août, avant les observations d’octobre.

Les attaques visent-elles les équipements Siemens précisément ?

Le canari émule une instance Node-RED, donc les attaques observées visent tout Node-RED non sécurisé qu’elles trouvent. L’adresse IP source a aussi visé sept autres CVE sur des produits sans rapport, ce que VulnCheck lit comme du scan de masse opportuniste.

VulnCheck note que Node-RED s’intègre dans des produits ICS et OT commerciaux. Elle note aussi que la documentation d’Emerson met en avant l’usage de Node-RED par ce fournisseur, sans valider l’impact.

Que signifie « privilèges maximaux » ici ?

Siemens indique que l’attaquant exécute du code arbitraire « avec des privilèges maximaux » sur le serveur sous-jacent de la passerelle. Sur un hôte Node-RED générique, les commandes tournent sous l’utilisateur du processus Node-RED. Le même mécanisme de déploiement s’applique.

Où Node-RED écoute-t-il par défaut ?

L’éditeur et l’API Admin écoutent sur toutes les interfaces IPv4, 0.0.0.0, sur le port 1880 par défaut, d’après la documentation de configuration de Node-RED. Sur une passerelle à interfaces multiples, chaque réseau qu’elle relie peut l’atteindre tant que le déploiement ne surcharge pas uiHost.

Trouvez les interfaces industrielles exposées avec Ostorlab

La découverte de surface d’attaque d’Ostorlab inventorie les hôtes exposés sur internet de vos plages, pour repérer chaque équipement qui répond sur l’interface Node-RED. Comparez chacun à la version corrigée. Lancez un scan avec Ostorlab pour savoir quels hôtes mettre à jour en premier.

Références

• Avis de sécurité Siemens SSA-834709, publié le 11 août 2026, avec les vecteurs CVSS v3.1 et v4.0 10,0, la liste des produits touchés, le remède V4.3.4.1 et les atténuations : https://cert-portal.siemens.com/productcert/html/ssa-834709.html (vérifié le 3 novembre 2026)
• Enregistrement CVE-2026-58115, CNA Siemens, publié le 11 août 2026, avec le bloc SSVC de CISA ADP : https://www.cve.org/CVERecord?id=CVE-2026-58115 (vérifié le 3 novembre 2026)
• VulnCheck, « Exploitation Targeting Node-RED, a Tool Embedded in ICS Products », publié le 2 novembre 2026, avec l’exploit décodé, le tableau d’indicateurs et les charges de suivi : https://www.vulncheck.com/blog/exploitation-targeting-node-red (vérifié le 3 novembre 2026)
• The Hacker News, « Attackers Exploit Critical Siemens IoT2050 Flaw to Plant Remote Command Backdoors », publié le 3 novembre 2026 : https://thehackernews.com/2026/11/attackers-exploit-critical-siemens.html (vérifié le 3 novembre 2026)
• Guide de sécurisation Node-RED, « Securing Node-RED », l’énoncé « éditeur non sécurisé par défaut » et les étapes adminAuth, HTTPS et HTTP-nœuds : https://nodered.org/docs/user-guide/runtime/securing-node-red (vérifié le 3 novembre 2026)
• API Admin HTTP de Node-RED, POST /flows, l’en-tête Bearer token « si l’authentification est activée » : https://nodered.org/docs/api/admin/methods/post/flows/ (vérifié le 3 novembre 2026)
• Documentation de configuration Node-RED, valeurs par défaut uiHost et uiPort et httpAdminRoot : https://nodered.org/docs/user-guide/runtime/configuration (vérifié le 3 novembre 2026)
• Page du paquet npm node-red, téléchargements hebdomadaires : https://www.npmjs.com/package/node-red (vérifié le 3 novembre 2026)
• Page Docker Hub de nodered/node-red, nombre de téléchargements de l’image : https://hub.docker.com/r/nodered/node-red (vérifié le 3 novembre 2026)
• Flux JSON du catalogue KEV de la CISA, recherché pour CVE-2026-58115 sans correspondance au 3 novembre 2026 : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 3 novembre 2026)