Une faille de la plateforme n8n permettait à n’importe quel utilisateur authentifié de compromettre entièrement le serveur sous-jacent, exposant les identifiants, les secrets et les workflows pilotés par l’IA dans les environnements d’entreprise.
La vulnérabilité affiche un score CVSS de 10,0 et permet aux attaquants de s’échapper du bac à sable JavaScript de n8n pour exécuter des commandes arbitraires, transformant de fait une logique de workflow ordinaire en contrôle total du système.
« Ces plateformes sont devenues les joyaux de la couronne sans que personne ne s’en rende compte. Chaque workflow sensible, chaque prompt d’IA, chaque identifiant — tout transite par la couche d’orchestration », ont déclaré les chercheurs de Pillar dans un e-mail adressé à eSecurityPlanet.
Ils ont ajouté : « Le risque réel ne réside pas dans un système donné, mais dans ce qui les relie. Et à l’avenir, les agents d’IA construiront et modifieront bientôt ces workflows de manière autonome. La compromission par un agent de la couche d’orchestration d’un autre agent — c’est cette chaîne d’attaque pour laquelle nous devrions concevoir des défenses dès maintenant, et non après les faits. »
La faille d’échappement du bac à sable de n8n
n8n est largement utilisé pour automatiser les processus métier essentiels et est devenu de plus en plus la couche d’orchestration des workflows pilotés par l’IA dans les entreprises.
Les organisations s’appuient sur cet outil pour connecter les systèmes internes, les services cloud et les grands modèles de langage au sein de pipelines d’automatisation de bout en bout.
Par conséquent, une compromission unique ne touche pas seulement une intégration ou un workflow : elle peut exposer des identifiants cloud, des bases de données et des pipelines d’IA qui traitent régulièrement des données sensibles d’entreprise et de clients.
Le risque concerne à la fois les déploiements n8n auto-hébergés et n8n Cloud.
Dans les environnements cloud, l’architecture mutualisée et multitenant de n8n augmente considérablement l’ampleur potentielle de l’impact, faisant craindre qu’un seul tenant compromis puisse menacer des services ou des données voisins.
Au cœur du problème se trouve le moteur d’expressions de n8n, qui permet aux utilisateurs d’intégrer directement du JavaScript dans les workflows à l’aide de la ={{ }} syntaxe.
Cette fonctionnalité explique en grande partie la souplesse de la plateforme, en permettant des transformations dynamiques de données et une orchestration avancée de l’IA.
Cependant, elle signifie également que le JavaScript fourni par l’utilisateur est évalué côté serveur.
Pour réduire le risque inhérent, n8n s’appuie sur un bac à sable fondé sur un arbre syntaxique abstrait (AST), conçu pour empêcher l’accès aux objets JavaScript et aux primitives d’exécution dangereux.
Les chercheurs en sécurité de Pillar ont découvert que ce bac à sable pouvait être entièrement contourné.
Tout utilisateur authentifié capable de créer ou de modifier un workflow — sans disposer de privilèges administratifs — pouvait s’échapper du bac à sable et obtenir une exécution de code à distance (RCE) sur le serveur n8n.
Une fois l’exploitation réalisée, les attaquants pouvaient lire les variables d’environnement, accéder au système de fichiers et extraire la N8N_ENCRYPTION_KEY.
Grâce à cette clé, ils pouvaient déchiffrer tous les identifiants stockés, notamment les clés d’accès aux fournisseurs cloud, les jetons OAuth, les mots de passe des bases de données et les identifiants d’API de services d’IA tels qu’OpenAI et Anthropic.
La chaîne de vulnérabilités initiale, suivie sous le numéro CVE-2026-25049, résultait de lacunes dans la logique de désinfection de l’AST de n8n.
Les chercheurs ont combiné plusieurs mécanismes de JavaScript — l’accès aux propriétés via les littéraux de gabarit, le hook V8 Error.prepareStackTrace et la portée des fonctions fléchées — pour atteindre le véritable objet global situé hors du bac à sable.
Bien que n8n ait publié un correctif en décembre 2025, les chercheurs ont identifié un contournement dans les 24 heures à l’aide de Object.defineProperty().
Le désinfecteur se concentrait étroitement sur la syntaxe d’accès aux propriétés et ne tenait pas compte des API JavaScript capables de modifier les propriétés des objets sans accès direct aux membres.
Dans les deux cas, le résultat était le même : une exécution complète de code à distance depuis ce qui semblait être une expression de workflow normale.
Un correctif complet a finalement été publié dans la version 2.4.0 ; il traitait la catégorie plus large de lacunes dans l’analyse de l’AST, plutôt que des techniques de contournement individuelles.
Aucun élément ne faisait état d’une exploitation active dans la nature au moment de la divulgation.
Réduire les risques dans n8n et les workflows d’IA
Compte tenu de l’impact élevé des vulnérabilités de n8n et de leur relative facilité d’exploitation, la remédiation doit aller au-delà de l’application d’un seul correctif.
La mise à jour vers une version corrigée constitue une première étape importante, mais une réduction efficace des risques nécessite également des contrôles qui limitent l’exposition, améliorent la visibilité et permettent une réaction rapide en cas d’incident.
- Appliquez le correctif à n8n version 2.4.0 ou ultérieure immédiatement et faites tourner la N8N_ENCRYPTION_KEY ainsi que tous les identifiants stockés sur la plateforme.
- Réservez la création, la modification des workflows et l’importation de modèles aux utilisateurs de confiance et exigez une vérification ou une approbation pour toute modification des workflows en production.
- Isolez les charges de travail n8n au moyen de contrôles d’exécution stricts, tels que le renforcement des conteneurs, des privilèges minimaux et une séparation d’avec les autres systèmes sensibles.
- Limitez l’accès réseau sortant aux seuls points de terminaison approuvés et surveillez toute modification non autorisée des destinations, notamment des URL de base des fournisseurs d’IA.
- Réduisez l’exposition des identifiants en utilisant des secrets gérés en externe, des jetons à courte durée de vie et un accès à moindres privilèges pour chaque workflow et chaque intégration.
- Surveillez les workflows et le comportement à l’exécution afin de détecter les signes d’abus, notamment les expressions suspectes, l’exécution inattendue de processus et toute activité réseau anormale.
- Testez et mettez à jour les plans de réponse aux incidents afin de garantir que les équipes puissent rapidement contenir la compromission des workflows, renouveler les identifiants et restaurer des états d’automatisation fiables.
Ces contrôles contribuent à contenir l’impact d’une compromission potentielle tout en renforçant la résilience de l’organisation face aux futures attaques visant la couche d’automatisation.
Les risques des plateformes d’orchestration de l’IA
La faille d’échappement du bac à sable de n8n montre comment les plateformes d’automatisation et d’orchestration de l’IA sont devenues des cibles à forte valeur, situées en amont de nombreux contrôles de sécurité traditionnels.
À mesure que ces outils continuent de connecter davantage de systèmes et de gérer de plus en plus la prise de décision pilotée par l’IA, les équipes de sécurité doivent partir du principe que les garde-fous au niveau applicatif peuvent échouer et concevoir des architectures qui limitent l’ampleur de l’impact lorsque cela se produit.
C’est cette évolution du risque qui pousse les organisations à adopter des solutions zero trust afin de mieux limiter l’impact d’une compromission à mesure que les systèmes et les workflows deviennent plus interconnectés.