CVE-2026-58115 : Node-RED exploitée en conditions réelles, un bot Linux déployé via l'API admin

CVE-2026-58115 : l'API admin de Node-RED accessible sans authentification

Node-RED est un outil d'automatisation open source basé sur Node.js, très répandu en self-hosting sur VPS Linux, serveurs dédiés et appliances IoT. Il permet de créer visuellement des flux (flows) qui enchaînent des noeuds : lecture de capteurs, appels HTTP, exécution de commandes système. Tout hébergeur proposant des VPS voit des instances Node-RED tourner dans des environnements variés : domotique, supervision réseau, automatisation de workflows. Le 27 octobre 2026, VulnCheck a publié des artefacts de détection pour CVE-2026-58115, une vulnérabilité critique (CVSS 10.0) qui expose l'intégralité de l'API admin de Node-RED sans aucune authentification (source : VulnCheck). Trois jours plus tard, le 30 octobre 2026, les premières exploitations en conditions réelles ont été observées.

Par défaut, Node-RED ne demande ni login ni mot de passe pour accéder à l'éditeur de flows et à l'API admin. Tant que la propriété adminAuth n'est pas activée dans le fichier settings.js, n'importe quel visiteur peut déployer un flow contenant un noeud exec et exécuter des commandes système arbitraires sur le serveur. C'est exactement ce que les attaquants exploitent depuis le 30 octobre.

Exploitation active depuis le 30 octobre 2026

Entre le 30 octobre et le 1er novembre 2026, VulnCheck a documenté 16 tentatives d'exploitation provenant d'une même adresse IP source (4.201.105.116, AS8075, géolocalisation Brésil). Cette adresse IP a ciblé au moins 8 CVE différentes sur la même période, signe d'un scan opportuniste à grande échelle, pas d'une attaque ciblée. Les connexions TCP entrantes sur le port 1880 laissent peu de traces dans les logs : Node-RED ne journalise pas les requêtes sur l'API admin par défaut.

Trois variantes de payload ont été observées :

• Variante 1 : téléchargement direct du binaire bot-linux-amd64 et exécution immédiate.
• Variante 2 : récupération d'un script shell intermédiaire (wget.sh) qui télécharge ensuite le binaire.
• Variante 3 : déploiement d'un webshell persistant via un endpoint HTTP acceptant des paramètres en query string pour exécuter des commandes à distance.

Le binaire porte le nom bot-linux-amd64, ce qui indique un ciblage des serveurs Linux sur architecture x86-64 : exactement le profil d'un VPS Linux ou d'un serveur dédié auto-hébergé.

La chaîne d'attaque : du flow injecté au bot Linux

L'exploitation repose sur deux types de noeuds natifs de Node-RED, disponibles dans toute installation par défaut :

• Inject : déclenche un message à intervalle régulier ou au démarrage du flow.
• Exec : exécute une commande système sur le serveur hôte.

L'attaquant envoie une requête POST sur l'endpoint /flows de l'API admin pour déployer un flow qui câble un noeud Inject à un noeud Exec. Le flow s'exécute automatiquement au déploiement. La commande injectée utilise un encodage base64 en trois couches :

echo "Y3VybCAtbyAvZGV2L3NobS8..." | base64 -d | sh

Une fois décodée, la commande télécharge le binaire avec curl ou wget (fallback), le place dans /dev/shm/.b (un répertoire en RAM qui ne laisse aucune trace sur disque), le rend exécutable et le lance en arrière-plan avec setsid et nohup pour qu'il survive à la fermeture du processus parent. Le processus se renomme pour imiter un processus noyau légitime.

Vérifier si votre instance Node-RED est exposée

Connectez-vous en SSH à votre serveur depuis un terminal et vérifiez en ligne de commande si Node-RED écoute sur une adresse publique. Identifiez d'abord le port utilisé (lister les ports en écoute avec ss) :

ss -tlnp | grep node-red

Si Node-RED écoute sur 0.0.0.0:1880 (toutes les interfaces réseau), il est potentiellement accessible depuis internet. Testez ensuite si l'API /flows répond sans authentification, depuis un poste externe ou avec curl directement :

curl -s -o /dev/null -w "%{http_code}" http://VOTRE-IP:1880/flows

Un code HTTP 200 signifie que l'API admin est ouverte sans aucun mot de passe. Vérifiez aussi les règles de votre firewall (pare-feu) pour confirmer que le port 1880 n'est pas exposé (configurer nftables ou UFW sur Ubuntu) :

sudo ufw status | grep 1880

Si le port est ouvert et l'API répond 200, votre instance est vulnérable. Vérifiez immédiatement les flows déployés pour repérer des noeuds exec ou http in que vous n'avez pas créés :

curl -s http://localhost:1880/flows | python3 -m json.tool | grep -i "exec\|http in"

Recherchez aussi la présence du binaire malveillant dans /dev/shm et dans les processus actifs :

ls -la /dev/shm/.b 2>/dev/null
ps aux | grep bot-linux

Activer l'authentification dans settings.js

La remédiation principale consiste à activer adminAuth dans le fichier settings.js de Node-RED. Ce fichier se trouve dans le répertoire utilisateur de Node-RED (par défaut ~/.node-red/settings.js, ou /data/settings.js sous Docker). Sur Debian ou Ubuntu, si Node-RED a été installé via le package npm global, les configurations se trouvent dans le répertoire /home/nodered/.node-red/.

Commencez par générer un hash bcrypt de votre mot de passe (disponible depuis Node-RED 1.1.0) :

node-red admin hash-pw

Éditez settings.js et ajoutez ou décommentez le bloc adminAuth :

adminAuth: {
    type: "credentials",
    users: [{
        username: "admin",
        password: "$2b$08$VOTRE_HASH_BCRYPT_ICI",
        permissions: "*"
    }]
}

Redémarrez Node-RED pour appliquer la configuration :

sudo systemctl restart nodered
# ou sous Docker :
docker restart node-red

Après redémarrage, l'éditeur et l'API admin exigent un login. Vérifiez que l'accès est bien protégé en retentant la requête curl sur /flows : elle doit maintenant retourner un code HTTP 401 (Unauthorized).

Si vos flows exposent des endpoints HTTP via des noeuds http in, ajoutez aussi httpNodeAuth pour protéger ces routes par un mot de passe séparé :

httpNodeAuth: {
    user: "user",
    pass: "$2b$08$VOTRE_HASH_ICI"
}

Indicateurs de compromission (IoC)

Les indicateurs suivants ont été publiés par VulnCheck le 1er novembre 2026. Si vous retrouvez l'une de ces adresses IP ou l'un de ces fichiers sur votre serveur, considérez l'instance comme compromise :

Si votre instance a été compromise, isolez le serveur du réseau, arrêtez Node-RED, supprimez le binaire et auditez les processus actifs. Consultez les logs d'audit avec auditd pour retracer les actions effectuées par l'attaquant. Restaurez depuis une sauvegarde saine si nécessaire.

Bonnes pratiques pour sécuriser Node-RED sur un VPS

Au-delà de l'activation de adminAuth, plusieurs mesures réduisent la surface d'attaque de Node-RED sur votre serveur :

• Ne pas exposer le port 1880 sur internet : fermez le port dans votre pare-feu et accédez à Node-RED uniquement via un reverse proxy Nginx avec authentification TLS ou par tunnel SSH. Si vous utilisez n8n comme alternative, les mêmes principes s'appliquent (installer n8n sur VPS Linux).
• Exécuter Node-RED sous un utilisateur dédié : ne lancez jamais Node-RED en tant que root. Créez un utilisateur système dédié sans droits sudo. Le noeud exec exécute les commandes avec les permissions de l'utilisateur qui fait tourner Node-RED : un utilisateur restreint limite les dégâts en cas de compromission.
• Conteneuriser avec Docker : exécuter Node-RED dans un conteneur Docker Compose isole le processus du système hôte. Mappez uniquement les volumes nécessaires et ne montez jamais la socket Docker.
• Protéger l'accès par un nom de domaine et TLS : n'exposez jamais le port 1880 directement sur internet. Configurez un enregistrement DNS pointant vers votre serveur, puis un virtual host Nginx qui assure la terminaison TLS et filtre les connexions TCP entrantes. Cette configuration élimine l'accès en clair à l'API admin.
• Mettre à jour régulièrement : activez les mises à jour automatiques de sécurité pour les paquets système. Pour Node-RED, surveillez les releases sur le dépôt Git officiel et mettez à jour le package avec npm update -g node-red. Consultez le log des changements de chaque version avant de redémarrer en production.
• Sécuriser l'accès SSH : durcissez la configuration SSH de votre serveur, désactivez le login par mot de passe et utilisez l'authentification par clé publique.
• Surveiller les processus : un processus inconnu dans /dev/shm ou un binaire dont le nom imite un thread noyau est un signal d'alerte. Vérifiez régulièrement les processus actifs avec ps aux et les connexions réseau sortantes avec ss -tnp.