CVE-2025-68613 : Vulnérabilité critique n8n (CVSS 9.9) et risque d'exécution de code arbitraire
Lysandre Beauchêne
Une faille de sécurité critique affectant la plateforme d’automatisation de workflows n8n a été récemment divulguée, suscitant une vive inquiétude dans la communauté de la cybersécurité. Avec un score CVSS de 9.9 sur 10, cette vulnérabilité, identifiée comme CVE-2025-68613, expose des milliers d’instances à un risque majeur d’exécution de code arbitraire. Si elle est exploitée, cette faille permettrait à un attaquant authentifié de prendre le contrôle total d’un serveur n8n, compromettant ainsi l’intégrité des données et la sécurité des systèmes environnants.
L’automatisation des workflows est devenue un pilier essentiel pour de nombreuses entreprises, réduisant les tâches manuelles et améliorant l’efficacité opérationnelle. Cependant, cette dépendance accrue envers des outils comme n8n introduit également de nouvelles surfaces d’attaque. La récente découverte de cette vulnérabilité met en lumière la nécessité impérative d’une gestion rigoureuse des mises à jour de sécurité. Dans cet article, nous allons analyser en profondeur cette menace, ses implications techniques et les mesures correctives que vous devez mettre en place immédiatement pour protéger vos infrastructures.
Comprendre la vulnérabilité CVE-2025-68613
La faille réside dans le mécanisme d’évaluation des expressions (expressions) au sein des workflows n8n. Selon les mainteneurs du package, le problème survient lorsque des expressions fournies par des utilisateurs authentifiés durant la configuration d’un workflow sont évaluées dans un contexte d’exécution qui n’est pas suffisamment isolé du runtime sous-jacent.
En termes simples, cela signifie que la séparation entre le code de l’utilisateur et le système d’exécution de n8n est défaillante. Un utilisateur authentifié, qui aurait normalement le droit de créer ou de modifier des workflows, peut injecter du code malveillant. Lorsque ce workflow est exécuté, le code n’est pas “sandboxé” correctement et s’exécute avec les mêmes privilèges que le processus n8n lui-même.
Contexte technique et mécanisme d’attaque
Dans une architecture sécurisée, les parties non fiables du code (celles écrites par les utilisateurs) doivent être isolées du reste du système. C’est le principe de moindre privilège et d’isolation des processus. CVE-2025-68613 vient briser ce principe.
L’attaquant exploite cette faiblesse en soumettant une expression spécialement conçue. Cette expression, au lieu d’être traitée comme une simple donnée de configuration, est interprétée comme du code exécutable. Comme elle s’exécute avec les droits du processus n8n, l’attaquant gagne une capacité équivalente à celle du service lui-même. Cela mène potentiellement à une compromission complète de l’instance, incluant :
- L’accès non autorisé aux données sensibles stockées dans les variables d’environnement ou les bases de données connectées.
- La modification ou la suppression des workflows existants.
- L’exécution d’opérations au niveau du système d’exploitation (shell, fichiers, etc.).
Portée et gravité du risque
Le score CVSS de 9.9/10 classe cette vulnérabilité dans la catégorie “Critique”. Ce score élevé reflète la facilité d’exploitation (elle nécessite seulement un compte utilisateur authentifié) et l’impact sévère (perte totale de confidentialité, d’intégrité et de disponibilité).
De plus, la nature même de n8n — qui est souvent connecté à de multiples services externes (API, bases de données, services cloud) — amplifie l’impact. Une fois le serveur compromis, l’attaquant peut potentiellement pivoter vers d’autres systèmes internes, utilisant n8n comme point d’entrée dans le réseau d’entreprise.
Portée de l’attaque et instances impactées
Cette vulnérabilité ne touche pas une version ancienne et négligée, mais affecte une large gamme de déploiements actuels.
Versions affectées
Selon les informations divulguées, CVE-2025-68613 affecte toutes les versions comprises entre 0.211.0 (incluse) et 1.120.4 (exclue). Cela représente une fenêtre de temps significative durant laquelle de nombreuses installations n8n ont pu être déployées sans être conscientes du risque.
Les versions corrigées sont les suivantes :
- 1.120.4
- 1.121.1
- 1.122.0 (et les versions ultérieures)
Il est impératif de vérifier immédiatement la version en production sur vos serveurs.
Échelle de l’exposition mondiale
Pour mesurer l’ampleur de cette menace, l’analyse des données de Censys, une plateforme de gestion de la surface d’attaque, est éloquente. En date du 22 décembre 2025, Censys a identifié 103 476 instances n8n potentiellement vulnérables accessibles sur Internet.
Ces chiffres révèlent une exposition massive. Bien que la majorité des instances soient localisées aux États-Unis, en Allemagne, au Brésil et à Singapour, la France figure également parmi les pays comportant un nombre significatif de déploiements. Cette répartition géographique souligne que le risque est global et concerne directement l’écosystème numérique français.
“Sous certaines conditions, les expressions fournies par des utilisateurs authentifiés lors de la configuration des workflows peuvent être évaluées dans un contexte d’exécution qui n’est pas suffisamment isolé du runtime sous-jacent.” — Mainteneurs de n8n.
Facteurs aggravants : l’automatisation et la connectivité
Le danger spécifique de n8n réside dans sa fonction d’orchestrateur. Contrairement à un script isolé, n8n est souvent le ciment numérique qui lie vos applications. Si un attaquant prend le contrôle de n8n, il ne compromet pas seulement une application, mais l’ensemble du flux de données que vous avez automatisé. Cela inclut potentiellement les clés API, les secrets de base de données et les accès aux services cloud.
Procéder aux mises à jour et stratégies de mitigation
Face à une vulnérabilité de cette criticité, l’action prioritaire est la mise à jour. Cependant, dans les environnements d’entreprise où les mises à jour ne sont pas instantanées, des stratégies de mitigation immédiates doivent être déployées.
Étapes de mise à jour (Patch)
La correction est disponible dans les versions récentes. Voici la procédure recommandée pour mettre à jour votre instance n8n :
- Sauvegarder votre instance : Avant toute modification, assurez-vous de sauvegarder votre base de données et vos fichiers de configuration.
- Identifier la version actuelle : Vérifiez la version via l’interface de n8n ou la commande
npm list n8n. - Mettre à jour le package : Utilisez votre gestionnaire de paquets préféré. Pour une installation npm classique, la commande ressemble à :Si vous utilisez Docker, tirez la dernière image stable :
npm install -g n8n@latestdocker pull n8nio/n8n:latest - Redémarrer le service : Assurez-vous que le service redémarre avec la nouvelle version.
Mesures de mitigation si la mise à jour est impossible
Si vous ne pouvez pas appliquer le patch immédiatement pour des raisons opérationnelles, l’ANSSI (Agence nationale de la sécurité des systèmes d’information) et les éditeurs de logiciels recommandent généralement d’appliquer une stratégie de défense en profondeur. Voici les actions à prioriser :
- Restreindre les droits utilisateurs : Limitez strictement la capacité de créer et d’éditer des workflows. Seuls les administrateurs de confiance devraient avoir ce privilège. Créez des rôles avec le principe de moindre privilège.
- Durcissement de l’environnement : Exécutez n8n avec des droits système restreints. Ne jamais lancer le service en tant que
rootou utilisateur administrateur. Utilisez des mécanismes commesystemdou des conteneurs pour isoler le processus. - Isolation réseau : Si possible, placez n8n dans un réseau segmenté (VLAN). Restreignez l’accès à son interface web aux seules adresses IP autorisées (VPN d’entreprise, bureaux spécifiques).
Tableau comparatif des actions de sécurité
| Priorité | Action | Description | Impact sur la sécurité |
|---|---|---|---|
| Critique | Mise à jour (Patch) | Installer la version 1.120.4, 1.121.1 ou 1.122.0+ | Élimine la vulnérabilité |
| Haute | Restriction des droits | Limiter la création/modification de workflows aux admins | Réduit la surface d’attaque interne |
| Moyenne | Durcissement OS | Exécuter avec des droits restreints (non-root) | Limite l’impact en cas de compromission |
| Moyenne | Isolation réseau | Filtrer les accès IP et réseaux | Empêche l’accès externe non autorisé |
Analyse de risque et contexte de sécurité 2025
L’année 2025 a été marquée par une augmentation des attaques ciblant les outils de développement et d’automatisation. Les ransomwares et les groupes d’espionnage cherchent de plus en plus à exploiter les chaînes d’approvisionnement logicielles et les outils internes.
Le paysage des menaces automatisées
Les outils comme n8n, Zapier ou Make sont devenus des cibles de choix. Pourquoi ? Parce qu’ils détiennent les “clés du royaume” : accès API, secrets, et capacité d’exécution de commandes. Une attaque réussie sur n8n n’est pas une simple intrusion ; c’est souvent la clé pour déclencher des attaques plus larges, comme l’exfiltration de données ou l’installation de malwares persistants.
L’importance de la chaîne de confiance
Cette faille rappelle une leçon fondamentale : la sécurité doit être intégrée à chaque étape du cycle de vie du logiciel. Dans la pratique, nous observons que de nombreuses entreprises déploient des outils d’automatisation sans passerelles de sécurité adéquates. L’outil est considéré comme “interne” et donc sûr, ce qui est une erreur fatale.
“La sécurité n’est pas un produit, mais un processus.” — Adage de la sécurité informatique.
Ce proverbe prend tout son sens ici. Avoir un outil sécurisé aujourd’hui ne garantit pas sa sécurité demain. La vigilance constante et la surveillance des éditeurs sont indispensables.
Conclusion : Vers une automatisation plus résiliente
La découverte de CVE-2025-68613 est un signal d’alarme pour tous les responsables de systèmes utilisant n8n. Avec un score de 9.9/10 et plus de 100 000 instances potentiellement exposées, le risque est réel et imminent.
La réponse à cette menace doit être immédiate et structurée. Priorisez l’application du patch sur vos instances de production. Si cela n’est pas faisable dans l’immédiat, adoptez une posture défensive stricte en restreignant les accès et en durcissant votre environnement d’exécution.
À l’approche de la fin de l’année 2025, cette alerte nous rappelle que la sécurité des infrastructures automatisées est une responsabilité continue. Nous vous invitons à auditer vos workflows, à vérifier vos versions logicielles et à renforcer vos politiques d’accès. La robustesse de vos systèmes dépendra de votre capacité à réagir vite et bien face à ces vulnérabilités critiques.