Une interface d’automatisation exposée peut permettre à des attaquants d’exécuter leurs propres commandes sans se connecter.
VulnCheck a indiqué le 2 nov. que ses systèmes de surveillance avaient détecté l’exploitation de CVE-2026-58115, une vulnérabilité liée à l’absence d’authentification dans Node-RED. Siemens avait précédemment signalé cette faille dans certaines installations SIMATIC IoT2050 Advanced, où elle peut permettre l’exécution de code à distance avec les privilèges maximaux.
Pour les administrateurs, la réponse doit couvrir à la fois les contrôles d’accès et le comportement de l’application : fermer le point d’entrée ne permet pas de déterminer si un workflow non autorisé est déjà présent.
Transformer les flux d’automatisation en exécution de commandes
Node-RED relie les fonctions des applications au moyen de workflows appelés flux. Selon l’enquête de VulnCheck, un attaquant a soumis un flux malveillant à son système canari le 30 oct., associant un déclencheur automatique à un nœud capable d’exécuter des commandes shell.
La requête contenait des instructions pour télécharger et exécuter une charge utile Linux. D’autres requêtes observées ont créé des webshells au sein des flux, permettant d’envoyer ultérieurement des commandes via des requêtes HTTP. Ces portes dérobées pouvaient survivre à un redémarrage.
Les chercheurs ont recensé 16 événements ciblant la faille depuis une même adresse IP entre le 30 oct. et le 1er nov. Ils n’ont pas récupéré les charges utiles téléchargées, ce qui laisse leurs capacités à confirmer. Les résultats documentent les requêtes d’exploitation reçues par les systèmes de surveillance de VulnCheck. Ils n’établissent pas que des clients industriels ont été compromis ni que les charges utiles téléchargées se sont exécutées avec succès.
Le contexte industriel donne une importance particulière à l’accès à ces outils. Une vulnérabilité SCADA d’Iconics illustre comment des faiblesses dans les logiciels auxiliaires peuvent menacer la disponibilité des systèmes opérationnels.
Quelles installations Siemens nécessitent une attention particulière
L’avis de sécurité de Siemens, publié le 11 août, identifie les appareils SIMATIC IoT2050 Advanced portant le numéro de produit 6ES7647-0BA00-1YA2, exécutant Industrial OS avec Node-RED installé.
Les versions concernées sont antérieures à V4.3.4.1. Siemens recommande d’effectuer la mise à jour vers V4.3.4.1 ou une version ultérieure et cite la désinstallation de Node-RED ou le renforcement de sa configuration parmi les mesures d’atténuation.
La vulnérabilité obtient un score CVSS maximal de 10,0. Les installations concernées n’appliquent pas d’authentification sur l’interface HTTP de Node-RED, exposant des fonctions de programmation capables d’exécuter des commandes système. Le numéro de version indiqué dans les mesures correctives de Siemens fait référence à la version du produit concerné ; il ne doit pas être considéré comme une cible de mise à niveau universelle de Node-RED.
Protéger séparément l’éditeur et les points de terminaison des flux
Le guide de sécurité de Node-RED documente adminAuth pour protéger l’éditeur et l’API d’administration. Les administrateurs peuvent configurer les utilisateurs authentifiés et leurs autorisations, notamment restreindre les personnes autorisées à modifier les flux.
Les points de terminaison HTTP créés par les flux nécessitent une protection distincte. Node-RED documente httpNodeAuth pour l’authentification HTTP Basic sur les routes exposées par les nœuds d’entrée HTTP, tandis que HTTPS chiffre les connexions. Les administrateurs doivent vérifier l’authentification à la fois sur l’interface d’administration et sur les points de terminaison applicatifs.
Mettez en place des contrôles d’accès réseau et une segmentation afin que les interfaces de gestion ne soient accessibles que depuis des systèmes approuvés, et examinez les règles de pare-feu pour détecter toute exposition involontaire.
Avant de clore la réponse, déterminez ce qui a changé
Commencez par identifier le responsable de chaque déploiement et ce qu’il prend en charge. Consignez le modèle de l’appareil, la version installée, les chemins d’accès ainsi que l’équipe applicative ou opérationnelle responsable. Les intervenants disposeront ainsi d’un périmètre concret pour les mises à jour et les vérifications de configuration.
Comparez ensuite les flux déployés à une référence approuvée. Examinez les ajouts ou modifications inexpliqués, en particulier les workflows qui lancent des commandes ou introduisent des points de terminaison HTTP. Une automatisation légitime peut utiliser ces fonctionnalités ; leur seule présence ne constitue donc pas une preuve de compromission. Il faut établir leur responsable et leur comportement prévu.
Si des modifications suspectes sont découvertes, utilisez le processus de réponse aux incidents pour coordonner le confinement, la collecte des éléments de preuve, l’enquête et la restauration. Préservez les configurations et journaux pertinents, et associez le personnel opérationnel lorsque des changements pourraient interrompre une dépendance de production.
Avant de rétablir l’accès normal, vérifiez que la mise à jour requise est installée, que l’authentification est appliquée et que les workflows déployés correspondent au comportement autorisé. Si une exécution de commandes non autorisée est suspectée, examinez l’hôte sous-jacent pour rechercher d’autres mécanismes de persistance ou une exposition des identifiants, et déterminez s’il est nécessaire de le reconstruire. Documentez les éléments justifiant la restauration et désignez un responsable pour les constatations non résolues.