CVE-2025-68613 : Vulnérabilité critique dans n8n (CVSS 9.9) et risque d'exécution de code arbitraire
Théophane Villedieu
Une faille de sécurité critique a été révélée dans la plateforme d’automatisation de workflows n8n, exposant des milliers d’instances à un risque majeur. Avec un score CVSS de 9,9/10, CVE-2025-68613 permet à des utilisateurs authentifiés d’exécuter du code arbitraire, compromettant potentiellement l’intégrité des données et des systèmes.
Comprendre la vulnérabilité CVE-2025-68613
La faille identifiée dans n8n est une vulnérabilité d’évaluation d’expressions qui affecte le cœur du moteur d’automatisation. Selon les mainteneurs du package npm, le problème survient car les expressions fournies par des utilisateurs authentifiés lors de 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 pratique, cela signifie que la séparation entre le code utilisateur et le système d’exécution est insuffisante.
Cette vulnérabilité est particulièrement dangereuse car elle ne nécessite pas d’accès administrateur complet. Un attaquant avec des droits de création ou d’édition de workflows peut exploiter ce défaut pour élever ses privilèges. Le score CVSS de 9,9 sur 10 reflète la gravité exceptionnelle de cette faille : elle est facile à exploiter (Low Attack Complexity) et a un impact majeur sur la confidentialité, l’intégrité et la disponibilité des systèmes.
Contexte technique de l’attaque
L’exploitation repose sur l’injection d’expressions malveillantes dans les workflows. Concrètement, un utilisateur authentifié peut insérer du code qui sera interprété par le moteur n8n dans un contexte privilégié. Ce code s’exécute alors avec les droits du processus n8n lui-même, qui a souvent un accès étendu aux ressources système et aux données sensibles.
Les conséquences d’une exploitation réussie sont multiples : compromission complète de l’instance n8n, accès non autorisé aux données sensibles stockées dans les workflows (clés API, secrets, informations clients), modification des workflows pour exfiltrer des données ou déployer des payloads malveillants, et exécution d’opérations système via les intégrations n8n (bases de données, APIs externes, systèmes de fichiers).
Portée de l’impact et versions affectées
Les versions impactées sont étendues. Toutes les versions supérieures ou égales à 0.211.0 et inférieures à 1.120.4 sont vulnérables. Cette plage de versions couvre une période de développement significative, ce qui explique le grand nombre d’instances potentiellement exposées.
Données chiffrées sur l’exposition
Selon les données de la plateforme de gestion de la surface d’attaque Censys, 103 476 instances potentiellement vulnérables ont été identifiées au 22 décembre 2025. Ces chiffres illustrent l’ampleur du déploiement de n8n dans l’écosystème technique.
Répartition géographique des instances vulnérables :
- États-Unis : Majorité des déploiements
- Allemagne : Forte présence d’instances
- France : Important déploiement professionnel
- Brésil : Croissance rapide des utilisations
- Singapour : Hub technologique régional
Le package n8n affiche environ 57 000 téléchargements hebdomadaires sur npm, confirmant son adoption massive dans les environnements d’entreprise et par les développeurs indépendants.
Procédure de mitigation et correctifs
La solution recommandée est la mise à jour immédiate. Les mainteneurs ont publié des versions corrigées :
- Version 1.120.4 (correctif de sécurité)
- Version 1.121.1 (correction de bugs)
- Version 1.122.0 (dernière version stable)
Si la mise à jour immédiate n’est pas possible
En pratique, si vous ne pouvez pas patcher immédiatement, plusieurs mesures de mitigation doivent être déployées :
- Restreindre les permissions de création et d’édition de workflows aux utilisateurs de confiance uniquement. Limiter l’accès à l’interface d’administration.
- Déployer n8n dans un environnement durci avec des privilèges système restreints. Le processus n8n ne doit pas s’exécuter avec des droits root ou administrateur.
- Isoler le réseau : Limiter les accès réseau sortants et entrants pour n8n, en particulier vers les systèmes critiques ou les APIs sensibles.
- Surveiller les logs : Mettre en place une surveillance active des logs d’accès et des événements de création/modification de workflows.
Analyse des risques pour les entreprises françaises
Pour les organisations françaises, cette vulnérabilité présente des risques spécifiques liés à la conformité réglementaire. n8n est souvent utilisé pour automatiser des processus métiers critiques, incluant le traitement de données personnelles au sens du RGPD.
Scénarios d’attaque réalistes :
- Un employé malveillant ou un compte compromis peut exfiltrer les données clients stockées dans les workflows.
- Modification des automatisations pour détourner des transactions financières ou des communications.
- Utilisation de l’instance n8n comme point d’entrée pour déployer des ransomwares ou des cryptominers.
Conséquences sur la conformité
Si des données personnelles sont exposées via cette faille, cela constitue une violation du RGPD qui pourrait entraîner des sanctions financières significatives. L’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) recommande d’ailleurs de maintenir un inventaire précis des logiciels vulnérables et de patcher dans des délais courts pour les vulnérabilités critiques.
Étapes actionnables pour les administrateurs
Voici une procédure détaillée pour sécuriser vos instances n8n :
1. Identifier et inventorier
# Vérifier la version actuelle de n8n
npm list n8n
# Rechercher les instances n8n dans votre infrastructure
grep -r "n8n" /etc/ /var/www/ 2>/dev/null
# Scanner les ports ouverts (typiquement 5678)
nmap -p 5678 --open your-subnet-range
2. Appliquer le correctif
# Mettre à jour vers la version sécurisée (exemple)
npm install n8n@1.120.4
# Ou pour Docker
docker pull n8nio/n8n:1.120.4
3. Configurer les permissions
Dans les paramètres de votre instance n8n :
- Activer l’authentification à deux facteurs (2FA) pour tous les utilisateurs
- Configurer le RBAC (Role-Based Access Control) si disponible
- Limiter l’accès à l’interface d’administration à des VLANs ou IPs spécifiques
4. Durcir la configuration système
Exemple de configuration systemd pour restreindre les privilèges :
[Service]
User=n8n
Group=n8n
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/n8n
5. Mettre en place la surveillance
Points de surveillance clés :
- Toute création ou modification de workflow par des comptes non autorisés
- Accès aux endpoints API sensibles depuis n8n
- Tentatives d’exécution de commandes système depuis les workflows
FAQ : Questions fréquentes sur CVE-2025-68613
Q : Mon instance n8n est-elle vulnérable ?
A : Si vous utilisez une version entre 0.211.0 et 1.120.3 (exclue), votre instance est vulnérable. Vérifiez avec npm list n8n.
Q : L’attaque nécessite-t-elle un compte administrateur ? A : Non, un compte avec des droits de création/édition de workflows suffit.
Q : Les instances cloud de n8n sont-elles affectées ? A : Les instances auto-hébergées sont concernées. Les solutions SaaS officielles ont généralement été patchées par le fournisseur.
Q : Peut-on détecter une exploitation ? A : Oui, via l’analyse des logs d’exécution de workflows et des appels système suspects.
Conclusion et recommandations immédiates
CVE-2025-68613 représente une menace sérieuse pour les organisations utilisant n8n. La vulnérabilité est active et exploitée potentiellement, d’autant que les informations sur la faille sont publiques.
Action immédiate requise :
- Vérifier votre version de n8n
- Planifier la mise à jour vers 1.120.4 ou supérieure
- En attendant, restreindre drastiquement les permissions d’accès
- Surveiller activement les logs
Pour les entreprises françaises, cette faille souligne l’importance de maintenir un inventaire logiciel à jour et de réagir rapidement aux alertes de sécurité. La mise en place d’une politique de patching formalisée, conforme aux recommandations de l’ANSSI, est essentielle pour prévenir ce type de risque.
Ne sous-estimez pas cette vulnérabilité. Son score CVSS de 9,9/10 et le nombre d’instances exposées en font une priorité de sécurité majeure pour la fin d’année 2025.