CVE-2026-21877 : RCE CVSS 10.0 critique dans n8n

Les faits

CVE-2026-21877 est une vulnérabilité d'exécution de code à distance (RCE) affectant n8n, la plateforme d'automatisation de flux de travail open-source largement adoptée en entreprise pour orchestrer des tâches entre outils SaaS, APIs et bases de données. Avec un score CVSS 3.1 de 10.0 — le maximum absolu — et un vecteur AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, cette vulnérabilité représente une menace d'une gravité exceptionnelle. Elle a été découverte et divulguée via le programme de divulgation responsable de n8n, et un correctif a été intégré dans la version 1.121.3. Des chercheurs de CyberScoop, Qualys ThreatPROTECT et Tenable ont émis des avertissements d'urgence sur la nécessité de patcher sans délai, soulignant que des milliers d'instances restent exposées.

La cause racine réside dans une validation insuffisante des entrées dans le nœud Git (Git node) de n8n. Ce nœud permet aux utilisateurs d'intégrer des opérations Git — clonage de dépôts, récupération de branches, exécution de commandes Git — directement dans leurs workflows automatisés. La faille exploite une écriture de fichiers arbitraires (arbitrary file write) : en fournissant un chemin de dépôt Git malicieusement construit, un attaquant authentifié peut écrire des fichiers en dehors du répertoire de travail prévu, en exploitant une traversée de chemin non contrôlée (path traversal) combinée à une injection de commandes dans les arguments Git. Ces fichiers peuvent ensuite être exécutés par le processus n8n, permettant l'exécution de code arbitraire sur le serveur hôte.

L'exploitation nécessite un accès authentifié à l'instance n8n avec des droits suffisants pour créer ou modifier des workflows contenant un nœud Git. Dans les déploiements self-hosted avec authentification basique ou SSO, cela correspond à tout utilisateur ayant un compte actif. Dans les environnements multi-tenant ou d'entreprise où n8n est exposé à plusieurs équipes — développeurs, data engineers, ops — la surface d'attaque interne est significative. Un compte compromis ou un utilisateur malveillant interne peut déclencher l'exploitation sans nécessiter d'escalade de privilèges préalable sur la plateforme n8n elle-même.

L'impact d'une exploitation réussie est total. n8n s'exécute typiquement avec des privilèges système élevés pour interagir avec les APIs, les bases de données et les systèmes internes. Un accès RCE sur le serveur n8n donne donc à l'attaquant une porte d'entrée vers tous les systèmes connectés aux workflows : bases de données (PostgreSQL, MySQL, MongoDB), services cloud (AWS, Azure, GCP), outils de communication (Slack, Microsoft Teams), CRM, ERP et tout service auquel n8n dispose d'un accès via ses intégrations. Les secrets stockés dans n8n — clés API, tokens OAuth, credentials de bases de données — sont directement exposés. Dans de nombreuses organisations, n8n est le nœud central qui relie des dizaines de systèmes critiques.

Le paramètre Scope: Changed (S:C) du vecteur CVSS explique en partie le score de 10.0 : l'exploitation ne se limite pas au composant vulnérable lui-même mais peut s'étendre à des systèmes et services distincts. Cette dimension est particulièrement critique pour n8n, dont le principe même est d'orchestrer des interactions entre systèmes hétérogènes. Un attaquant qui compromet un serveur n8n peut potentiellement exécuter tous les workflows automatisés avec les mêmes privilèges et tokens que le système légitime, rendant la détection de l'activité malveillante plus difficile car elle se confond avec le trafic normal d'automatisation.

Les versions affectées couvrent n8n 0.123.0 jusqu'à 1.121.2 inclus. La version 1.121.3, qui incorpore le correctif, a été publiée fin 2025 selon les informations initiales, mais c'est en mai 2026 que les chercheurs ont rendu l'alerte publique après avoir constaté que de nombreuses instances n'avaient toujours pas été mises à jour. Selon Qualys ThreatPROTECT et Vulert, des milliers d'instances n8n exposées sur Internet ont été identifiées via des scans publics, dont une proportion significative tourne encore sur des versions vulnérables. Les instances hébergées sur n8n Cloud bénéficient de mises à jour automatiques, mais les déploiements self-hosted — qui représentent la majorité des installations en entreprise — requièrent une action manuelle.

La sévérité CVSS 10.0 place CVE-2026-21877 dans la catégorie des vulnérabilités les plus critiques de l'année. Elle rejoint une liste restreinte de failles atteignant le score maximal, caractérisées par une exploitabilité triviale, aucune interaction utilisateur requise, et un impact complet sur la confidentialité, l'intégrité et la disponibilité. Pour les équipes sécurité qui s'appuient sur des priorités CVSS pour trier leurs actions, c'est un signal clair : cette vulnérabilité doit être patchée avant toute autre tâche du backlog sécurité.

Aucun code d'exploitation public (PoC) n'était disponible au moment de la rédaction de cet article. Cependant, étant donné la nature de la faille (path traversal et injection dans un nœud Git) et la documentation technique disponible dans les commits de correction de la version 1.121.3, des chercheurs en sécurité offensive et des acteurs malveillants sont susceptibles de développer un exploit fonctionnel rapidement. La fenêtre de temps avant exploitation in-the-wild est donc courte, et chaque heure sans patch augmente significativement le risque d'incident pour les organisations exposées.

Impact et exposition

n8n est utilisé par des milliers d'entreprises à travers le monde pour automatiser leurs processus métiers. La plateforme se positionne comme une alternative open-source à des services d'automatisation propriétaires, avec la particularité d'être déployable on-premise, ce qui en fait un choix privilégié pour les organisations soucieuses de la souveraineté de leurs données. Cette popularité, combinée au fait que n8n agit comme un concentrateur d'intégrations vers des systèmes critiques, en fait une cible de valeur maximale pour les attaquants. Un seul serveur n8n compromis peut donner accès à l'ensemble du système d'information interconnecté via les workflows.

Les organisations les plus exposées sont celles qui pratiquent l'automatisation intensive : équipes DevOps, data engineering, marketing automation, finance et RH utilisant n8n pour synchroniser des données entre CRM, ERP et outils analytiques. Dans ces contextes, les instances n8n disposent souvent de clés API avec des droits étendus sur de nombreux systèmes. La compromission d'un serveur n8n peut déclencher une réaction en chaîne touchant l'ensemble du périmètre numérique de l'organisation.

Les instances n8n accessibles depuis Internet sans authentification forte (sans MFA, avec des mots de passe faibles ou des comptes partagés) sont les plus exposées. Des scans Shodan et Censys révèlent régulièrement des instances n8n sans authentification ou avec des credentials par défaut. Dans ce scénario, l'exigence d'un compte authentifié devient une barrière minimale facilement franchissable via credential stuffing, phishing ciblé ou exploitation de vulnérabilités d'authentification antérieures dans n8n.

Recommandations immédiates

• Mettre à jour n8n vers la version 1.121.3 ou supérieure — n8n Security Advisory CVE-2026-21877
• Si la mise à jour immédiate n'est pas possible, désactiver le nœud Git dans les paramètres d'administration de n8n
• Restreindre l'accès à l'instance n8n au réseau interne ou via VPN — ne jamais exposer n8n directement sur Internet
• Activer l'authentification multi-facteurs (MFA) sur tous les comptes n8n
• Auditer les logs d'exécution des workflows pour détecter toute utilisation suspecte du nœud Git
• Faire tourner tous les secrets (clés API, tokens) stockés dans n8n à titre de précaution si une exposition a pu avoir lieu