n8n Ni8mare CVE-2026-21858 : RCE non-auth CVSS 10.0

Les faits

La plateforme d''orchestration low-code n8n, l''une des stars de l''écosystème automation et agents IA depuis 2024, fait face à sa pire faille depuis sa création. La CVE-2026-21858, surnommée Ni8mare par l''équipe d''Horizon3.ai qui en a publié l''analyse complète le 9 mai 2026, atteint un score CVSS de 10.0, plafond absolu de l''échelle. Elle permet à un attaquant non authentifié d''exécuter du code arbitraire sur toute instance n8n auto-hébergée dont les Form Webhooks sont accessibles, ce qui couvre la quasi-totalité des déploiements grand public puisque ce mécanisme est activé par défaut.

Le vecteur d''origine est une confusion de Content-Type dans le routeur HTTP qui sert les Form Webhooks. Plutôt que de filtrer strictement le type multipart/form-data attendu pour ces endpoints, le parseur accepte un payload application/json contenant une section files dont les valeurs sont interprétées comme des chemins absolus sur le système de fichiers du serveur n8n. L''attaquant peut ainsi pointer vers des fichiers internes à l''instance — typiquement /home/node/.n8n/config et /home/node/.n8n/database.sqlite — et déclencher leur lecture par le moteur n8n.

L''escalade vers RCE se fait par chaînage. Le fichier /home/node/.n8n/config contient la clé secrète d''authentification utilisée par n8n pour signer les cookies de session. Le fichier database.sqlite contient l''ensemble des comptes utilisateurs de l''instance, incluant les administrateurs. Avec la clé secrète exfiltrée et la connaissance d''un identifiant administrateur, l''attaquant peut forger des cookies n8n-auth valides et obtenir un accès console équivalent à un superutilisateur de la plateforme. Le pivot RCE final passe par la création d''un workflow contenant un node Execute Command, fonctionnalité native de n8n qui exécute des commandes système avec les privilèges du processus n8n. Le tout sans aucune authentification initiale.

L''astuce technique relevée par Horizon3.ai concerne la phase de divulgation : si la fuite des fichiers de configuration ne suffit pas par elle-même à un attaquant, l''incorporation des contenus dans le contexte d''un node LLM-powered chatbot configuré sur l''instance permet de poser des questions au modèle pour extraire les secrets via le canal de chat. Cette mécanique transforme un node IA légitime en oracle d''exfiltration et illustre une nouvelle classe d''amplification : les paths de fichiers compromis deviennent du contexte LLM, le LLM répond, et la confidentialité s''évapore.

Toutes les versions de n8n antérieures à 1.121.0 sont vulnérables. Le correctif est intégré à n8n 1.121.0, publié le 9 mai par l''équipe officielle après divulgation coordonnée avec Horizon3.ai. Les versions 1.121.x ultérieures embarquent également la correction. Les déploiements n8n Cloud, opérés par n8n GmbH, ont été patchés côté infrastructure dans les heures qui ont suivi la publication et ne sont pas concernés. Le risque pèse exclusivement sur les déploiements auto-hébergés, en particulier ceux exposés directement sur Internet sans reverse proxy filtrant ni WAF.

L''ACSC australien a publié un avis de criticité maximale le 10 mai recommandant le patch immédiat ou le retrait de l''instance d''Internet en attendant. CISA n''a pas encore versé la CVE au catalogue KEV mais surveille activement la situation, selon une note publiée par CSO Online. Plusieurs équipes de réponse à incident ont déjà documenté des exploitations sauvages, notamment via des scans massifs sur les ports 5678 et 80 à la recherche de la signature d''un endpoint Form Webhook actif. La fenêtre entre publication du correctif et industrialisation d''un PoC public a été particulièrement courte : Aikido Security a relayé un PoC fonctionnel le 11 mai au matin.

L''enjeu sectoriel est important parce que n8n s''est imposé en deux ans comme une brique pivot des architectures agents IA chez les startups et les équipes data internes. Beaucoup d''organisations exécutent des workflows n8n avec des credentials directement câblés vers Salesforce, HubSpot, Stripe, des bases de données de production, des API internes critiques. Une compromission Ni8mare ouvre donc un accès indirect à l''ensemble de cet écosystème de credentials orchestrés, au-delà du simple RCE sur l''hôte.

Impact et exposition

Toute instance n8n auto-hébergée en version inférieure à 1.121.0 et accessible depuis Internet est exposée. Le risque est maximal pour les déploiements pré-production ou de démonstration souvent oubliés derrière un domaine public. Les déploiements internes, accessibles uniquement via VPN ou réseau privé, restent vulnérables si un attaquant atteint le segment réseau, mais le périmètre d''exploitation initiale est plus restreint. Les déploiements n8n Cloud ne sont pas concernés. Le compteur Shadowserver ne propose pas encore de chiffres consolidés mais Horizon3.ai estime à plusieurs dizaines de milliers le nombre d''instances exposées sur Internet en mai 2026.

Recommandations

• Mettre à jour vers n8n 1.121.0 ou version ultérieure dans les heures qui suivent, sans attendre la fenêtre de maintenance habituelle.
• Si le patch immédiat est impossible, retirer l''instance d''Internet ou bloquer les requêtes vers /webhook* avec un Content-Type différent de multipart/form-data au niveau du reverse proxy.
• Inspecter les logs n8n et les logs du reverse proxy pour la période 9 mai au présent à la recherche de requêtes POST sur /webhook avec Content-Type application/json contenant la chaîne files.
• Faire tourner systématiquement tous les credentials stockés dans n8n Credentials Manager si l''instance était exposée à Internet, considérer toute clé API tierce comme potentiellement compromise.
• Régénérer la clé secrète n8n et invalider toutes les sessions actives via redémarrage de l''instance après patch.