« Une instance n8n compromise ne signifie pas seulement la perte d’un système, cela signifie donner aux attaquants les clés de tout », ont écrit les chercheurs en sécurité à propos de la vulnérabilité de gravité 10.0.
Les chercheurs ont publié des détails sur une vulnérabilité critique qui a été corrigée silencieusement dans n8n, une plate-forme utilisée par de nombreuses entreprises pour créer des agents basés sur LLM et des flux de travail automatisés. Cette faille peut permettre à des attaquants non authentifiés de prendre entièrement le contrôle des déploiements n8n locaux, d’exécuter des commandes sur le système sous-jacent et d’extraire les données sensibles auxquelles les flux de travail d’entreprise ont généralement accès.
« Le rayon d’explosion d’un n8n compromis est énorme », ont noté les chercheurs de la société de sécurité des données Cyera, qui ont découvert la vulnérabilité, dans leur rapport sur la vulnérabilité. « N8n connecte d’innombrables systèmes, votre Google Drive organisationnel, les clés API OpenAI, les données Salesforce, les systèmes IAM, les processeurs de paiement, les bases de données clients, les pipelines CI/CD, et bien plus encore. C’est le système nerveux central de votre infrastructure d’automatisation. »
Les développeurs de n8n ont corrigé ce problème dans la version 1.121.0 publiée le 18 novembre, mais les notes de version ne mentionnaient pas les correctifs de sécurité à l’époque, ce qui semble être une procédure standard car les avis de sécurité de n8n sont intentionnellement publiés avec un retard. Le projet a depuis lors corrigé d’autres vulnérabilités RCE critiques, telles que CVE-2025-68613, CVE-2025-68668 et CVE-2026-21877, les utilisateurs doivent donc s’assurer de toujours mettre à jour vers la dernière version disponible.
La confusion Content-Type conduit à des lectures de fichiers arbitraires
La vulnérabilité, identifiée comme CVE-2026-21858, a un indice de gravité de 10,0 (critique) et permet une attaque en deux parties. Premièrement, cela permet à des attaquants non authentifiés ayant accès aux formulaires Web n8n de divulguer des fichiers internes du serveur n8n. C’est parce que le formWebhook La fonction utilisée par les nœuds du formulaire n8n pour recevoir des données ne valide pas si le Content-Type Le champ de la requête POST soumise par l’utilisateur est défini sur multipart/form-data.
Imaginez un cas d’utilisation très courant dans lequel n8n a été utilisé pour créer une interface de discussion permettant aux utilisateurs de télécharger des fichiers sur le système – par exemple, un portail de support client qui accepte des captures d’écran ou des journaux d’erreurs, un système RH pour soumettre des CV ou une base de connaissances où les employés peuvent télécharger des documents à indexer pour des requêtes ultérieures via un chatbot alimenté par LLM.
Dans le flux normal, lorsque le type de contenu est multipart/form-data et le corps de la requête a un files: définition, n8n analysera la requête avec son parseFormData() fonction, qui utilise la bibliothèque Node.js Formidable pour gérer les téléchargements de fichiers en toute sécurité en stockant le fichier dans un répertoire temporaire avec un chemin aléatoire avant de remplir le req.body.files variable globale avec le nom du fichier et son emplacement.
Cependant, si une requête a un type de contenu différent, par exemple application/jsonn8n analysera le corps de la requête à l’aide d’une autre fonction appelée parseBody()qui se comporte différemment. Cette fonction extrait la section de données de la requête pour remplir le req.body.data variable globale, mais il extrait également toute autre section de la requête pour remplir la variable correspondante req.body.(section name) variables avec leur contenu.
Parce que formWebhook ne valide pas si une demande avec un files la section est en fait multipart/form-datail appellera la mauvaise fonction d’analyse sur son corps, ce qui entraînera la population du req.body.files variable avec des valeurs contrôlées par l’utilisateur telles que les noms de fichiers et les chemins. Il appellera alors une fonction appelée copyBinaryFile() pour copier tous les fichiers du req.body.files variable – qui sont censés être des chemins aléatoires temporaires – vers des emplacements de stockage persistants destinés à être consommés par d’autres nœuds/flux de travail, conduisant à des attaques potentielles par traversée de chemin, dans lesquelles des fichiers légitimes sur le système peuvent être écrasés ou chargés ailleurs dans un flux de travail.
Pour exploiter cette vulnérabilité, un attaquant peut soumettre une requête comme application/json avec un files section qui spécifie les chemins de fichiers connus du système local, y compris les fichiers de configuration n8n contenant des informations d’identification et des jetons sensibles. Si ces fichiers sont ajoutés dans le contexte d’un nœud de chatbot alimenté par LLM, l’attaquant peut alors utiliser l’interface de discussion pour poser des questions sur ces fichiers et divulguer leur contenu.
De la lecture de fichiers arbitraires aux privilèges d’administrateur
La deuxième partie de l’attaque permise par cette vulnérabilité ouvre considérablement le « rayon d’explosion », car la possibilité de lire n’importe quel fichier local a de sérieuses implications en raison de la manière dont n8n suit les sessions authentifiées.
Les cookies de session sont des chaînes stockées dans le navigateur de l’utilisateur pour maintenir son statut d’authentification pendant un certain temps. Les attaquants volent régulièrement les cookies de session des systèmes compromis pour contourner l’authentification et se connecter en tant que victimes sur divers sites Web.
Dans n8n, les cookies de session sont générés en combinant l’identifiant unique d’un utilisateur avec un hachage SHA256 de l’e-mail et du mot de passe de l’utilisateur, puis en signant le résultat avec une clé secrète unique à chaque installation n8n.
Le problème est que toutes les informations nécessaires à la reconstruction des cookies de session se trouvent dans des fichiers locaux. La clé secrète unique est stockée dans /home/node/.n8n/config et tous les enregistrements d’utilisateurs sont stockés dans le /home/node/.n8n/database.sqlite déposer. La fuite du contenu de ces deux fichiers permet aux attaquants de recréer n8n-auth cookies pour tous les utilisateurs, y compris les administrateurs.
Avec les privilèges d’administrateur, les attaquants peuvent créer de nouveaux flux de travail, et n8n propose un nœud appelé Execute Command qui fait exactement ce que son nom l’indique : exécute des commandes sur le système d’exploitation sous-jacent avec les privilèges du service n8n.
« Imaginez une grande entreprise de plus de 10 000 employés avec un serveur n8n que tout le monde utilise », écrivent les chercheurs dans leur rapport. « Une instance n8n compromise ne signifie pas seulement perdre un système, cela signifie donner aux attaquants les clés de tout. Les informations d’identification API, les jetons OAuth, les connexions à la base de données, le stockage dans le cloud, le tout centralisé en un seul endroit. N8n devient un point de défaillance unique et une mine d’or pour les acteurs malveillants. «
