Une faille critique n8n menace 200 000 instances

Une faille de type Remote Code Execution a été révélée dans n8n, la plateforme d’automatisation de workflows qui a levé plus de 55 millions d’euros en Série B. Cette vulnérabilité, baptisée CVE‑2025‑68613, permet à un utilisateur authentifié de prendre le contrôle complet du serveur hôte. À l’heure où 75 % des 200 000 utilisateurs actifs exploitent l’IA intégrée, la menace dépasse la simple panne d’une fonction : elle touche désormais la souveraineté des données de milliers d’entreprises.

À retenir

• « CVE‑2025‑68613 » : RCE avec un score CVSS 10/10.
• Vulnérabilité dans l’évaluation des expressions, exploitable via un workflow simple.
• Impact direct sur 200 000 utilisateurs, dont 3 000 entreprises.
• Patch de sécurité disponible à partir de la version 1.120.4.
• Mesures temporaires : restreindre la création de workflows et isoler les environnements.

La sécurité des plateformes d’automatisation de workflows, de plus en plus imbriquées avec les modèles de langage et les bases vectorielles, vient de franchir un nouveau seuil de risque avec la découverte de CVE‑2025‑68613. Alors que le marché des outils low‑code et no‑code se généralise dans les équipes métiers, les risques liés à l’exécution de code arbitraire dans des environnements partagés ou auto‑hébergés deviennent très concrets. Cette faille, qui permet à un acteur malveillant de s’échapper du bac à sable applicatif, relance le débat sur la fiabilité des solutions open‑source dans les infrastructures critiques.

La faille et son vecteur d’attaque

La vulnérabilité, identifiée sous la référence CVE‑2025‑68613, cible le mécanisme d’évaluation des expressions dans n8n. Un simple champ d’expression, lorsqu’il contient une syntaxe spécialement construite, peut être interprété avec les droits du processus serveur. Les versions affectées couvrent la plage v0.211.0 à v1.120.3, ce qui inclut une large partie des déploiements en production.

Injection d’expression et évasion du sandbox

Un utilisateur authentifié, même sans privilèges élevés, peut soumettre une expression du type {{ new Process('id').run() }}, et déclencher ainsi l’exécution de commandes arbitraires. Le manque d’isolement dans l’environnement d’exécution permet ensuite d’accéder à /etc/passwd ou d’exfiltrer des variables d’environnement. Les conséquences sont immédiates : lecture de fichiers sensibles, ouverture d’un reverse shell ou exécution de scripts personnalisés à partir du serveur compromis.

Conséquences pour les environnements auto‑hébergés

Les instances auto‑hébergées, qui concentrent souvent des données confidentielles et des clés d’API, apparaissent comme les premières cibles. Une attaque réussie peut compromettre les API credentials stockés dans la plateforme, exposer des bases vectorielles sensibles ou permettre l’accès à des modèles de langage soumis à la réglementation RGPD. Selon le Centre pour la Cybersécurité Belgique (CCB), la vitesse potentielle de propagation est renforcée par la prolifération de nœuds Git insuffisamment sécurisés, déjà signalés dans CVE‑2025‑62726, ce qui élargit encore la surface d’attaque.

Réponse et remédiation : patch, isolation et bonnes pratiques

Mise à jour immédiate

Les développeurs de n8n recommandent une mise à jour sans délai vers la version 1.120.4 ou supérieure, dans laquelle le bac à sable d’exécution a été renforcé. Cette version introduit un renforcement de l’évaluation des expressions, en limitant les fonctions exposées et en contrôlant plus strictement les accès au système. Pour les déploiements en production, cette montée de version doit être planifiée comme une mise à jour prioritaire, au même titre qu’un correctif critique de système d’exploitation.

Mesures temporaires pour les organisations à retardement

En attendant le déploiement du patch, limiter le droit de création ou de modification de workflows aux seuls utilisateurs de confiance est vivement conseillé. Des mesures d’isolation supplémentaires, telles que l’exécution de n8n dans un conteneur avec des privilèges restreints, permettent de réduire le risque de compromission totale de l’infrastructure. Les administrateurs peuvent également segmenter le réseau, isoler les serveurs d’automatisation et surveiller de près les journaux d’exécution à la recherche de commandes suspectes.

Gestion des autres vecteurs de risque

Les équipes doivent en parallèle désactiver le nœud Git lorsqu’il n’est pas indispensable, afin de réduire l’exposition à CVE‑2025‑65964, ou bloquer l’accès aux dépôts non vérifiés. La désactivation de certains nœuds, comme Git Node, peut être réalisée via le tableau de bord d’administration et doit s’accompagner d’un inventaire des intégrations actives. Pour les systèmes qui utilisent encore des orphan nodes, une vérification manuelle des flux et de leurs dépendances s’impose, afin d’identifier d’éventuels points d’entrée négligés.

Une leçon sur la souveraineté des données et la démocratisation de l’automatisation

La crise de sécurité actuelle met en lumière la tension grandissante entre la démocratisation de l’automatisation et la protection des données. Alors que n8n se présente comme un outil accessible aux équipes non techniques, la vulnérabilité rappelle que chaque fonction « facile à utiliser » peut se transformer en vecteur d’attaque majeur si elle est mal isolée. Pour les entreprises qui misent sur l’open‑source, le prix de cette flexibilité réside désormais dans la capacité à appliquer rapidement les correctifs et à maintenir des contrôles d’accès stricts autour des workflows sensibles.

Les entreprises européennes, soumises à la RGPD, doivent désormais évaluer si l’hébergement dans un environnement local, dans un cloud souverain ou chez un fournisseur international répond réellement aux exigences de souveraineté des données. La mise au jour d’une faille aussi critique que CVE‑2025‑68613 contraint les décideurs à reconsidérer la confiance accordée aux workflows automatisés, en particulier lorsqu’ils orchestrent des modèles d’IA traitant des informations sensibles ou stratégiques.

En résumé, la faille RCE de n8n rappelle l’importance d’une vigilance constante et d’une gestion proactive des vulnérabilités, aussi bien dans les solutions open‑source que dans les plateformes commerciales d’automatisation. Le patch est disponible ; la prochaine étape pour les entreprises consiste à le déployer sans délai, tout en renforçant leurs pratiques d’isolation des services et de contrôle d’accès, afin de limiter l’impact des prochaines failles inévitables.