Une vulnérabilité notée 10 sur 10 liée à Node-RED, l’outil de programmation visuelle qui relie les automates industriels au reste du système d’information, est exploitée depuis le 30 octobre. Le problème vient moins d’un bug que d’une configuration par défaut sans mot de passe, sur des équipements que la DSI ne connaît souvent même pas. On vous explique le mécanisme, les risques et les gestes à faire.

Node-RED, le couteau suisse discret de l’industrie connectée

Pour comprendre l’alerte, il faut d’abord comprendre l’outil. Node-RED est un environnement de programmation visuelle open source, bâti sur Node.js. Son principe : relier par glisser-déposer des blocs graphiques prédéfinis, appelés « nœuds », pour composer des « flux ». Un automaticien peut ainsi piloter un automate programmable et le connecter à une base de données ou à des services cloud sans écrire la moindre ligne de code.

Node-RED se loge à la frontière entre l’informatique de gestion (IT) et l’informatique opérationnelle (OT), celle qui commande les machines, les lignes de production et les capteurs. C’est justement ce qui le rend critique : la cible n’est plus un équipement isolé en bout de chaîne, mais un point de passage entre deux mondes.

Revers de la médaille : ces déploiements sont le plus souvent réalisés par des profils non informaticiens, en marge des projets IT. Résultat, ces passerelles échappent fréquemment aux inventaires de la DSI comme au périmètre de surveillance du RSSI.

Une faille de conception plus qu’un bug

Le cœur du problème tient en une phrase : dans sa configuration d’origine, Node-RED ouvre l’accès à son API d’administration sans aucun mot de passe. C’est à l’intégrateur d’activer l’authentification. Autrement dit, la vulnérabilité n’est ni un bug ni un comportement anormal du logiciel : c’est le réglage par défaut lui-même.

Concrètement, quiconque peut joindre l’interface d’administration d’une instance non protégée peut y créer ou modifier des flux, donc faire exécuter ce qu’il veut à la machine. D’où une note de gravité de 10 sur 10 sur l’échelle CVSS, le score maximal, « aussi rare que dramatique » selon le média.

Siemens en première ligne, tout l’écosystème OT en question

Le cas documenté concerne Siemens, qui intègre Node-RED dans ses produits d’automatisation et d’edge computing. Sa passerelle industrielle SIMATIC IoT2050 Advanced embarquait une interface Node-RED qui n’exigeait aucune authentification. La vulnérabilité associée, référencée CVE-2026-58115, a été corrigée par Siemens en août, via une mise à jour de son Industrial OS.

Mais Siemens n’est pas seul. Schneider Electric, ABB, Bosch Rexroth, Rockwell Automation, WAGO ou Phoenix Contact utilisent eux aussi Node-RED ou permettent de le déployer sur leurs équipements. À ce stade, on ignore si leurs produits présentent la même faiblesse, et dans quelle proportion. Pour les équipes sécurité, c’est précisément cette incertitude qui pose problème : impossible de se rassurer en se disant « nous n’avons pas de Siemens ».

Anatomie d’une attaque sans sophistication

La société américaine VulnCheck, spécialisée dans le renseignement sur les vulnérabilités, a capté la première exploitation sur ses leurres (honeypots) le 30 octobre. Et la méthode, souligne le média, « n’a rien de sophistiqué ».

Une simple requête HTTP suffit à déployer sur la cible un flux composé de deux nœuds natifs de Node-RED : le premier se déclenche automatiquement, le second exécute une commande système. Ce flux télécharge alors un programme malveillant pour Linux, dont VulnCheck n’a pas encore identifié la finalité. D’autres attaques observées depuis se contentent d’installer une porte dérobée de type webshell. Une logique de prépositionnement : l’attaquant s’installe maintenant pour agir plus tard, au moment qui l’arrange.

Le profil de l’attaquant est éclairant. Selon VulnCheck, il a visé Node-RED seize fois en trois jours et a tenté d’exploiter sept autres vulnérabilités, dont une faille d’Apache Solr vieille de sept ans. Nous sommes donc face à un acteur opportuniste qui balaie Internet à la recherche de tout ce qui est ouvert. Une passerelle IIoT exposée devient ainsi une cible comme une autre, au même titre qu’un serveur web oublié. Avec un enjeu supplémentaire : Node-RED concentre souvent les identifiants de tous les systèmes qu’il interconnecte.

Corriger ne suffit pas

L’analyste Frank Dickson, de Dickson Research, résume l’enjeu : « Le correctif ferme la porte, il n’expulse pas ceux qui sont déjà entrés. » Une instance compromise avant la mise à jour peut conserver un flux malveillant ou un webshell. Les recommandations vont donc bien au-delà du simple patch :

• Inventorier toutes les installations Node-RED, y compris celles intégrées aux passerelles des fournisseurs OT.
• Vérifier l’exposition : aucune instance ne doit être directement accessible depuis Internet.
• Activer l’authentification sur l’interface d’administration.
• Installer les correctifs publiés par les constructeurs.
• Auditer les flux pour repérer des nœuds d’exécution qui n’ont rien à y faire.
• Chasser les webshells éventuellement déposés.
• Renouveler les identifiants stockés dans les flux.

Pour un administrateur, le premier réflexe est souvent le plus difficile : savoir où tourne Node-RED. Sans inventaire, les sept étapes précédentes restent théoriques.

Qui est responsable de la passerelle ?

Au-delà de la technique, l’affaire soulève une question de gouvernance. Dans l’OT, les responsabilités sont diluées entre le constructeur, l’intégrateur, le mainteneur et le client final. Les contrôleurs sont de plus en plus connectés, parfois directement à Internet pour la maintenance à distance, souvent avec des mots de passe faibles et sans les bonnes pratiques de l’IT. Quand une passerelle a été installée en marge des projets informatiques, qui doit la mettre à jour et la surveiller : le métier, l’intégrateur, le mainteneur ou la DSI ? Tant que la réponse reste floue, ces équipements resteront des portes dérobées en puissance.

L’angle mort se referme par la gouvernance

La faille Node-RED ne révèle pas une technique d’attaque nouvelle. Elle met en lumière une réalité bien connue des RSSI : la convergence IT/OT avance plus vite que les pratiques de sécurité. Un outil pensé pour la simplicité, livré ouvert par défaut, déployé hors du radar de la DSI, et des attaquants qui n’ont même pas besoin d’outils sophistiqués pour en profiter. Pour les DSI et les équipes cyber, le chantier prioritaire n’est donc pas seulement d’appliquer un correctif : c’est d’intégrer enfin les passerelles industrielles dans l’inventaire, la supervision et la chaîne de responsabilité du système d’information.
Les attaques visant les angles morts de la convergence IT/OT se multiplient, « sans même avoir besoin d’IA ».