n8n frappé par deux failles critiques : anatomie d'un séisme sécuritaire

En janvier 2026, la plateforme d’automatisation n8n révèle trois vulnérabilités critiques notées jusqu’à 10.0 au CVSS, exposant potentiellement plus de 100 000 serveurs à des attaques d’exécution de code à distance. Ces failles, dont la redoutable “N8scape” permettant de s’échapper du sandbox Python, illustrent un problème structurel des plateformes no-code : les mécanismes de protection par liste de blocage sont fondamentalement insuffisants face à des attaquants déterminés. Pour les organisations utilisant n8n – dont 25% des entreprises Fortune 500 – l’urgence est absolue : une instance compromise offre aux attaquants un accès direct aux credentials, tokens OAuth et clés API de l’ensemble de l’écosystème connecté.

n8n, le couteau suisse de l’automatisation devenu cible de choix

Avant d’analyser ces vulnérabilités, il est essentiel de comprendre pourquoi n8n représente une cible si attractive pour les attaquants. Fondée en 2019 à Berlin par Jan Oberhauser, ancien Pipeline TD dans l’industrie VFX ayant travaillé sur des productions comme Maleficent et Happy Feet Two, n8n s’est imposée comme l’alternative open-source aux géants Zapier et Make. La plateforme permet de créer des workflows d’automatisation via une interface visuelle par nœuds, tout en offrant la flexibilité d’exécuter du code JavaScript ou Python personnalisé.

La croissance de n8n a été fulgurante. En octobre 2025, l’entreprise a levé 180 millions de dollars lors d’une Series C dirigée par Accel, portant sa valorisation à 2,5 milliards de dollars. Le projet cumule aujourd’hui près de 169 000 étoiles GitHub – le plaçant dans le top 50 mondial – et dépasse les 100 millions de téléchargements Docker. Selon n8n, 25% des entreprises du Fortune 500 utilisent désormais la plateforme.

Cette popularité explique l’ampleur du risque. n8n fonctionne comme un hub central d’automatisation stockant des credentials sensibles : tokens OAuth, clés API, identifiants de bases de données, accès cloud. Comme le résume Dor Attias des Cyera Research Labs : « Compromettre une instance n8n ne signifie pas perdre un seul système – cela revient à remettre aux attaquants les clés de tout votre écosystème. »

CVE-2026-21877 : quand le nœud Git devient une porte dérobée

La première vulnérabilité majeure, CVE-2026-21877, a obtenu le score CVSS maximal de 10.0. Découverte par le chercheur français Théo Lelasseux, elle affecte les versions 0.123.0 à 1.121.3 de n8n et permet à un utilisateur authentifié d’obtenir une exécution de code à distance complète.

Le vecteur d’attaque exploite le Git Node, un composant permettant aux workflows d’interagir avec des dépôts Git. Une faille d’écriture arbitraire de fichiers (CWE-434) permet à l’attaquant de déposer du code malveillant qui sera ensuite exécuté par le service n8n. Les conditions d’exploitation sont particulièrement préoccupantes : une complexité d’attaque faible, aucune interaction utilisateur requise, et des privilèges minimaux suffisants. Le vecteur CVSS complet (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) indique un impact dépassant le composant vulnérable lui-même, avec des conséquences maximales sur la confidentialité, l’intégrité et la disponibilité.

Cinq preuves de concept publiques sont déjà disponibles sur GitHub, rendant l’exploitation accessible même à des attaquants peu sophistiqués. Le correctif a été publié dans la version 1.121.3 de novembre 2025, mais la divulgation publique début janvier 2026 a créé une fenêtre de vulnérabilité critique pour les instances self-hosted non mises à jour.

N8scape (CVE-2025-68668) : l’évasion du sandbox Python à 9,9

La seconde vulnérabilité, baptisée “N8scape” par ses découvreurs Vladimir Tokarev et Ofek Itach de Cyera Research Labs, est peut-être plus significative du point de vue architectural. Avec un score CVSS de 9,9, elle permet de s’échapper du sandbox Pyodide utilisé pour exécuter du code Python dans le Code Node de n8n.

Pour comprendre N8scape, il faut saisir l’architecture de sécurité de n8n. La plateforme utilise Pyodide, un port de CPython compilé en WebAssembly, pour permettre aux utilisateurs d’exécuter du code Python dans leurs workflows. Pour sécuriser cette exécution, n8n implémente une liste de blocage (blocklist) interceptant certaines fonctions considérées dangereuses comme os.system ou l’accès au bridge JavaScript via sys.modules['js'].

Le problème fondamental ? Cette approche par blocklist suppose que le défenseur peut énumérer exhaustivement toutes les capacités dangereuses. Or, comme l’ont démontré les chercheurs de Cyera, n8n bloque les wrappers de haut niveau mais pas les capacités sous-jacentes.

Premier bypass via ctypes (FFI) :

from ctypes import CDLL
CDLL(None).system(b'id')

Ce code de deux lignes contourne la protection en utilisant l’interface Foreign Function Interface de Python pour invoquer directement la fonction system() de la libc, sans jamais toucher au wrapper os.system bloqué.

Second bypass via eval_code() :

import _pyodide._base
_pyodide._base.eval_code("import os; os.system('id')")

Cette technique exploite une fonction interne de Pyodide permettant d’exécuter du code dans un contexte où les patches de sécurité de n8n ne sont pas appliqués.

Les chercheurs sont formels : « Il s’agit d’un problème structurel découlant d’un sandbox basé sur une liste de blocage qui suppose implicitement que le défenseur peut énumérer chaque capacité dangereuse et chaque chemin pour l’atteindre. » La version 2.0.0 de n8n résout ce problème en abandonnant Pyodide au profit de task runners isolés exécutant Python de manière native dans des processus séparés.

Ni8mare : la troisième faille qui permet l’attaque sans authentification

Les recherches ont également mis en lumière une troisième vulnérabilité connexe, CVE-2026-21858, surnommée “Ni8mare”. Avec un score CVSS de 10.0, cette faille découverte par Dor Attias de Cyera est la plus dangereuse des trois car elle ne nécessite aucune authentification.

Ni8mare exploite une confusion de Content-Type dans le traitement des formulaires. Un attaquant peut accéder à des fichiers arbitraires sur le serveur et ultimement obtenir une exécution de code à distance. Selon les données Shadowserver du 12 janvier 2026, sur 105 753 instances initialement non patchées, 59 558 restaient encore vulnérables cinq jours après la divulgation.

Les agences gouvernementales ont réagi rapidement. Le Centre canadien pour la cybersécurité (CCCS) a émis les alertes AV26-004 et AL26-001, tandis que la Cyber Security Agency de Singapour a publié l’alerte AL-2026-002. Le message est unanime : mise à jour immédiate requise.

La chronologie d’une divulgation coordonnée

La gestion de ces vulnérabilités par n8n illustre les tensions inhérentes au processus de divulgation responsable. Voici la chronologie reconstituée :

• 27 octobre 2025 : Cyera signale N8scape à n8n via GitHub Security
• 9 novembre 2025 : Rapport initial de Ni8mare à n8n
• 18 novembre 2025 : Patch pour Ni8mare publié (v1.121.0)
• Novembre 2025 : Patch pour CVE-2026-21877 publié (v1.121.3)
• 24 décembre 2025 : Patch N8scape limitant le comportement vulnérable au mode Pyodide legacy
• 26 décembre 2025 : Publication N8scape sur la NVD
• 6-7 janvier 2026 : Attribution CVE et publication des advisories
• 8 janvier 2026 : Advisory officiel n8n et couverture médiatique massive
• 13 janvier 2026 : Publication du rapport technique complet de Cyera

n8n a justifié le délai entre le patch (novembre) et la communication publique (janvier) : « Nous voulions nous assurer que les correctifs avaient été déployés et offrir à nos clients l’opportunité de mettre à jour selon leur propre calendrier. Nous voulions également réduire le risque d’attaques généralisées qui se seraient probablement produites si nous n’avions pas de mitigation en place. »

Self-hosted versus Cloud : deux réalités de risque différentes

L’impact de ces vulnérabilités varie significativement selon le mode de déploiement. Pour les utilisateurs n8n Cloud, n8n a déployé automatiquement les correctifs avec un engagement de mise à jour sous 12 heures. Les instances cloud bénéficient également d’une isolation gérée par l’éditeur.

La situation est plus préoccupante pour les déploiements self-hosted, qui représentent une part significative de la base installée. Comme le souligne The Register : « Les patchs ont été discrètement déployés… certaines organisations peuvent encore exécuter des versions vulnérables – particulièrement dans les environnements self-hosted où les advisories upstream ne sont pas toujours lus. »

Les données Censys révèlent 26 512 hôtes n8n exposés mondialement, dont 7 079 aux États-Unis, 4 280 en Allemagne et 2 655 en France. Pour ces instances, le contexte d’exécution du RCE dépend de l’architecture :

• Docker/Kubernetes : l’exécution de code reste confinée au conteneur, offrant une isolation partielle
• VM/Bare metal : l’attaquant obtient les privilèges du processus n8n sur l’hôte

Cependant, comme le rappellent les chercheurs de Cyera, l’isolation conteneur ne protège pas les credentials : « Les secrets sont DANS le conteneur. L’échappement du sandbox était la ligne d’arrivée, pas le point de départ. »

Le problème structurel des sandboxes no-code

Au-delà du cas n8n, ces vulnérabilités révèlent un problème systémique affectant l’ensemble de l’écosystème no-code/low-code. Selon Gartner, 70% des nouvelles applications utiliseront ces technologies d’ici 2025, et 80% des utilisateurs seront des “citizen developers” non-IT d’ici 2026.

L’OWASP a formalisé ces risques dans son Low-Code/No-Code Top 10, identifiant notamment les failles d’usurpation d’identité de compte (LCNC-SEC-01), les abus d’autorisation (LCNC-SEC-02) et les défauts de configuration de sécurité (LCNC-SEC-05). Le cas n8n illustre parfaitement le risque LCNC-SEC-07 concernant les composants vulnérables.

Les plateformes concurrentes ne sont pas épargnées. Microsoft Power Automate a connu plusieurs CVEs critiques, dont CVE-2025-21187 (RCE) et CVE-2024-43479 (exécution arbitraire via tokens Entra ID usurpés). Une étude Vectra révèle que 71% des comptes surveillés ont détecté une activité suspecte impliquant Power Automate. Même Zapier, malgré son modèle SaaS, présente des risques identifiés : design flaws dans Storage by Zapier, 2FA non obligatoire, et une surface d’attaque massive via ses 8 000+ intégrations.

Le pattern récurrent est clair : les plateformes d’automatisation sont des cibles de choix car elles stockent des credentials longue durée, disposent de permissions élevées sur de multiples systèmes, et permettent une persistance invisible via des workflows malveillants.

Recommandations de remédiation et bonnes pratiques

Face à ces vulnérabilités, les actions à entreprendre varient selon l’urgence et la possibilité de mise à jour.

Actions immédiates prioritaires :

Pour les instances non patchées, la mise à jour vers n8n 2.0.0 (ou minimum 1.121.3) constitue la priorité absolue. Si une mise à jour immédiate est impossible, plusieurs mitigations temporaires peuvent être déployées via variables d’environnement :

• Désactiver Python : N8N_PYTHON_ENABLED=false
• Désactiver le Code Node : NODES_EXCLUDE='["n8n-nodes-base.code"]'
• Activer les task runners isolés : N8N_RUNNERS_ENABLED=true et N8N_NATIVE_PYTHON_RUNNER=true

Pour CVE-2026-21877 spécifiquement, la désactivation du Git Node et la limitation d’accès aux utilisateurs non approuvés réduisent la surface d’attaque. Pour Ni8mare, la restriction des webhooks et formulaires accessibles publiquement sans authentification est critique.

Architecture sécurisée pour le long terme :

n8n 2.0 adopte une philosophie “secure by default” avec plusieurs changements majeurs : task runners activés par défaut pour isoler l’exécution du code, accès aux variables d’environnement bloqué par défaut (N8N_BLOCK_ENV_ACCESS_IN_NODE=true), et nœuds dangereux comme ExecuteCommand désactivés par défaut.

Au-delà de n8n, toute plateforme d’automatisation self-hosted devrait suivre ces principes : isolation réseau stricte avec VPN pour l’administration, HTTPS via reverse proxy avec TLS 1.2+, MFA obligatoire et RBAC, audit logs avec intégration SIEM, et rotation régulière des secrets via un gestionnaire comme HashiCorp Vault.

Une attention particulière doit être portée à la supply chain. En janvier 2026, 8 packages npm malveillants ciblant n8n ont été détectés, volant des tokens OAuth Google Ads. La désactivation des community nodes non vérifiés (N8N_COMMUNITY_PACKAGES_ENABLED=false) constitue une mesure de prudence additionnelle.

Une perspective nuancée sur le risque réel

Si les scores CVSS maximaux (9,9 à 10,0) suggèrent une gravité extrême, des analyses plus nuancées méritent attention. Horizon3.ai observe que « bien que notées Critiques par les mécanismes de scoring comme CVSS, l’exploitation réussie nécessite une combinaison de prérequis peu probable dans la plupart des déploiements réels. »

Pour Ni8mare notamment, l’exploitation requiert un workflow avec formulaire accessible publiquement sans authentification ET un mécanisme de récupération des fichiers locaux. Sur les ~70 000 instances exposées sur Shodan, seulement 76 présentaient les composants chatbot vulnérables nécessaires.

Cette nuance ne diminue pas l’urgence de patcher – le risque reste élevé pour les configurations vulnérables – mais elle permet aux équipes sécurité de prioriser intelligemment. L’activité post-divulgation est réelle : Amiram Shachar, CEO d’Upwind, rapporte « une augmentation notable du trafic ciblant les instances n8n de nos clients », probablement liée à l’intérêt combiné des attaquants et des chercheurs en sécurité.

Conclusion

Les vulnérabilités CVE-2026-21877, CVE-2025-68668 (N8scape) et CVE-2026-21858 (Ni8mare) constituent un moment charnière pour la sécurité des plateformes d’automatisation. Elles démontrent que les approches de sandboxing par liste de blocage sont structurellement insuffisantes face à des attaquants sophistiqués capables d’identifier des chemins d’exécution alternatifs.

Pour n8n, l’adoption des task runners isolés dans la version 2.0 représente la bonne réponse architecturale : plutôt que de tenter d’énumérer toutes les fonctions dangereuses, isoler l’exécution du code non fiable dans des processus séparés. Ce pattern de défense en profondeur devrait inspirer l’ensemble de l’écosystème no-code/low-code.

L’enjeu dépasse le cas particulier de n8n. Alors que ces plateformes deviennent les hubs centraux de l’automatisation d’entreprise – stockant les credentials de centaines de services connectés – leur sécurité devient un impératif stratégique. Les organisations doivent intégrer ces outils dans leur gouvernance sécurité au même titre que les actifs critiques, avec audits réguliers, monitoring des workflows, et principe du moindre privilège pour les créateurs d’automatisations.

Pour les utilisateurs français de n8n – plus de 2 600 instances identifiées par Censys – l’action immédiate est requise. La mise à jour vers la version 2.0.0 n’est pas optionnelle : elle est le minimum requis pour opérer sereinement une plateforme qui, par nature, détient les clés de votre infrastructure numérique.