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

Les faits

Les chercheurs en sécurité ont relancé le 1er mai 2026 un appel pressant aux défenseurs concernant Ni8mare, identifiée sous l'ID CVE-2026-21858 et dotée d'un score CVSS maximal de 10.0. La vulnérabilité, découverte par le chercheur Dor Attias et reportée à n8n le 9 novembre 2025, concerne la plateforme d'automatisation low-code spécialisée dans les workflows IA. Bien que la divulgation initiale et le patch datent respectivement de janvier 2026 et novembre 2025 (version 1.121.0), la publication d'un PoC fonctionnel sur GitHub par le chercheur Chocapikk a relancé l'inquiétude des CERT, et les chercheurs de Cyera, Horizon3.ai, Rapid7 et Arctic Wolf alertent désormais en urgence sur la fenêtre d'exposition encore largement ouverte.

D'un point de vue technique, Ni8mare exploite une confusion de Content-Type dans le gestionnaire de webhooks de n8n. Le flux vulnérable se trouve dans la fonction formWebhook(), qui traite les soumissions de formulaires entrants. Selon l'analyse publiée par Cyera Research Labs et confirmée par Horizon3.ai, cette fonction accède à req.body.files sans vérifier au préalable que le Content-Type de la requête est bien multipart/form-data. Lorsqu'un attaquant transmet une requête avec un Content-Type différent — par exemple application/json — le middleware Express délègue le parsing au body parser standard, ce qui permet à l'attaquant de fournir directement l'objet req.body.files via le corps JSON de la requête.

Cette primitive d'override permet à l'attaquant de manipuler entièrement la structure attendue par le code de gestion de fichiers. Le résultat immédiat est une lecture de fichiers arbitraire sur le serveur, avec les privilèges du processus n8n — généralement un compte applicatif disposant des accès aux secrets de tous les workflows configurés (clés API OpenAI, tokens AWS, identifiants Slack, accès bases de données). Mais la chaîne d'exploitation publiée ne s'arrête pas là : en lisant les fichiers de configuration et la base de données SQLite locale, l'attaquant peut récupérer la clé secrète JWT et forger un token administrateur, puis exploiter une seconde vulnérabilité (CVE-2025-68613, expression injection) pour atteindre une exécution de code complète avec sandbox bypass.

L'enchaînement complet — confusion de Content-Type, lecture de fichiers, forgeage JWT admin, expression injection — donne à un attaquant non authentifié distant un contrôle total de l'instance n8n. Le PoC GitHub publié par Chocapikk industrialise toute la chaîne en un script unique. Les chercheurs de Horizon3.ai, dans leur analyse intitulée « The Ni8mare Test », confirment que l'exploit fonctionne de manière fiable sur les déploiements par défaut, tant en self-hosted (Docker, Kubernetes, bare-metal) qu'en cloud lorsque l'instance est exposée sans authentification au niveau réseau.

L'estimation du nombre d'instances exposées est particulièrement alarmante. Cyera Research Labs a recensé environ 100 000 serveurs n8n accessibles sur Internet, dont une part très significative tourne encore sur des versions antérieures à 1.121.0. CyberScoop souligne que de nombreuses installations sont des déploiements « shadow IT » montés par des équipes data ou marketing pour automatiser des intégrations IA, sans gouvernance sécurité et sans rotation des secrets. Le risque est d'autant plus critique que les workflows n8n agrègent typiquement des secrets de très haut privilège : clés OpenAI permettant l'usurpation d'identité de l'organisation auprès du fournisseur LLM, tokens d'écriture sur des dépôts GitHub, identifiants de bases de données client, accès Slack ou Microsoft Teams.

Le timing de la divulgation reste objet de débat dans la communauté. Le patch a été publié dès le 18 novembre 2025, soit neuf jours après le report initial du chercheur — une réactivité saluée. Mais la publication de l'advisory officielle n'a eu lieu que le 7 janvier 2026, et la diffusion massive du PoC GitHub n'est intervenue qu'après plusieurs semaines, créant une fenêtre durant laquelle les patches étaient disponibles mais peu déployés faute de pression médiatique. Désormais, avec l'exploit public et les annonces coordonnées de plusieurs éditeurs de sécurité fin avril 2026, la pression sur les opérateurs est maximale.

Au-delà de Ni8mare, n8n a également divulgué CVE-2026-21877, une seconde vulnérabilité de RCE également notée 10.0 CVSS. Bien que cette dernière requière une authentification, elle facilite considérablement la post-exploitation pour tout attaquant disposant ne serait-ce que d'un compte utilisateur de bas privilège — par exemple via du credential stuffing, du phishing, ou un accès récupéré via Ni8mare elle-même. La combinaison des deux vulnérabilités fait de la chaîne d'exploitation n8n l'une des cibles les plus rentables pour les opérateurs de ransomware ciblant les moyennes entreprises actuellement.

Du point de vue de la posture de sécurité, l'incident souligne le risque inhérent aux plateformes d'automatisation IA déployées en self-hosted sans contrôle réseau strict. Comme l'a noté Rapid7 dans sa note ETR « Ni8mare and N8scape flaws among multiple critical vulnerabilities affecting n8n », l'année 2026 a vu la divulgation de plusieurs failles critiques sur n8n, témoignant d'une surface d'attaque encore peu mature dans cette catégorie d'outils. Le succès commercial de n8n auprès des équipes IA et automation amplifie l'impact systémique de chaque nouvelle vulnérabilité.

Impact et exposition

L'exposition de Ni8mare est triple. Premièrement, l'instance n8n elle-même est compromise : un attaquant obtient le contrôle administrateur complet, peut créer des workflows arbitraires, exécuter du code via les nodes Function ou Code, et persister via des comptes utilisateur ou des webhooks backdoor. Deuxièmement, tous les secrets workflows sont exfiltrés : clés LLM (OpenAI, Anthropic, Mistral), tokens cloud (AWS, GCP, Azure), credentials bases de données, secrets Slack/Teams/Email. Troisièmement, l'attaquant peut pivoter vers les systèmes connectés via les automatismes existants pour atteindre l'infrastructure interne.

L'exploitation in-the-wild n'est pas formellement confirmée à ce stade, mais Arctic Wolf et Horizon3.ai signalent une forte activité de scan opportuniste sur les ports HTTP/HTTPS exposant l'interface n8n (souvent sur le port 5678 par défaut) depuis la publication du PoC. Les chercheurs de SOCRadar et Field Effect anticipent une exploitation massive dans les jours qui viennent, en particulier par des groupes ransomware en quête d'accès initiaux à fort privilège.

Les conditions d'exploitation sont idéales pour un attaquant : pas d'authentification, pas d'interaction utilisateur, vecteur réseau standard HTTPS, signature de trafic peu distincte d'un usage légitime. Les WAF génériques (Cloudflare, AWS WAF, ModSecurity) ne disposent pas de signatures spécifiques à Ni8mare au moment de la divulgation, ce qui rend le filtrage périmétrique inefficace pour bloquer l'attaque.

Côté français, la base d'utilisateurs n8n inclut de nombreuses ESN, agences digitales, startups IA et équipes data des grands comptes. Les déploiements sont souvent réalisés sur des VM cloud avec exposition directe du port d'admin sur Internet, sans VPN ni reverse proxy authentifié, ce qui maximise l'exposition. Les opérateurs concernés doivent considérer toute instance non patchée comme déjà compromise et procéder à une rotation complète des secrets.

Recommandations immédiates

• Mettre à jour n8n vers la version 1.121.0 ou supérieure — advisory : n8n Security Advisory CVE-2026-21858 du 7 janvier 2026 (sans lien externe).
• Si la mise à jour est impossible dans l'immédiat, retirer l'instance n8n de l'Internet public en la plaçant derrière un VPN, un reverse proxy authentifié ou un Identity-Aware Proxy.
• Faire tourner immédiatement tous les secrets stockés dans les workflows : clés OpenAI / Anthropic / Mistral, tokens GitHub / GitLab, credentials AWS / GCP / Azure, identifiants Slack / Teams, mots de passe bases de données.
• Inspecter les logs HTTP du serveur n8n à la recherche de requêtes POST vers /webhook/* avec un Content-Type non standard (application/json) et un payload contenant un objet files : indicateur de tentative d'exploitation Ni8mare.
• Auditer la base SQLite ou PostgreSQL de n8n pour repérer la création de workflows ou de comptes administrateurs inattendus depuis novembre 2025.