Faille n8n: multiples vulnérabilités critiques à corriger sur les instances self-hosted

Dans le cadre de notre veille sécurité, nous signalons une série de vulnérabilités touchant n8n, la plateforme d’automatisation de workflows open source.

Le rapport du 4 mai 2026 fait remonter 12 CVE sur n8n, avec des impacts variés: exécution de code, pollution de prototype, injection SQL, fuite de credentials, XSS, open redirect, déni de service et contournement d’autorisation.

Le point important n’est pas seulement le nombre de CVE. C’est la nature de n8n: une instance d’automatisation concentre souvent des accès API, des webhooks, des connecteurs bases de données, des secrets, des workflows métier et parfois des nodes capables d’exécuter du code.

Une faille n8n doit donc être traitée comme un sujet d’exploitation, pas comme une simple mise à jour applicative.

Faille n8n: les versions à corriger en priorité

Pour la majorité des vulnérabilités listées dans l’alerte, les versions corrigées annoncées sont:

• n8n 1.123.32 ou version ultérieure;
• n8n 2.17.4 ou version ultérieure;
• n8n 2.18.1 ou version ultérieure.

Une exception importante concerne CVE-2026-42226, corrigée dans:

• n8n 1.123.33 ou version ultérieure;
• n8n 2.17.5 ou version ultérieure;
• n8n 2.18.0 ou version ultérieure.

En pratique, si vous exploitez une instance self-hosted, le bon réflexe est simple: viser la version corrigée la plus récente de votre branche, puis tester les workflows critiques après mise à jour.

Pourquoi cette faille n8n est plus qu’une alerte de version

n8n n’est pas un outil isolé. Il sert justement à relier des systèmes entre eux.

Une instance peut avoir accès à:

• des bases SQL;
• des API SaaS;
• des systèmes internes;
• des webhooks exposés;
• des credentials réutilisables;
• des runners capables d’exécuter du code;
• des workflows qui déclenchent des actions métier.

Une vulnérabilité sur n8n peut donc devenir un point de pivot vers les systèmes connectés. C’est particulièrement vrai quand les workflows manipulent des secrets, reçoivent des entrées externes ou utilisent des nodes d’exécution de code.

La bonne question n’est pas seulement “quelle version de n8n est installée ?”.
La vraie question est: qu’est-ce que cette instance peut atteindre si elle est abusée ?

Les familles de risques derrière cette faille n8n

Les 12 CVE ne racontent pas toutes la même histoire. Elles se regroupent en plusieurs familles de risque.

CVE	Risque principal	Lecture opérationnelle
CVE-2026-42237	Injection SQL	Snowflake et ancien node MySQL v1 peuvent construire des requêtes avec des identifiants contrôlés par l'utilisateur.
CVE-2026-42236	Déni de service	Le endpoint d'enregistrement MCP OAuth peut être abusé sans authentification pour épuiser la mémoire.
CVE-2026-42235	XSS stockée	Un nom de client MCP OAuth piégé peut conduire à l'exécution de JavaScript dans une session n8n authentifiée.
CVE-2026-42234	Sandbox escape	Un utilisateur autorisé à modifier des workflows avec Python Code Node peut viser une exécution de code sur le task runner.
CVE-2026-42233	Injection SQL Oracle	Le champ Limit du node Oracle Database peut devenir dangereux s'il reçoit une entrée externe via expression.
CVE-2026-42232	Prototype pollution vers RCE	Le XML Node peut permettre une pollution globale menant à une exécution de code en chaîne avec d'autres nodes.
CVE-2026-42231	Prototype pollution via XML webhook	Un payload XML forgé peut polluer le prototype JavaScript et mener à une RCE en chaîne, notamment avec des opérations Git.
CVE-2026-42230	Open redirect	Un redirect_uri arbitraire enregistré via MCP OAuth peut être utilisé dans un scénario de phishing.
CVE-2026-42229	Injection SQL SeaTable	Des paramètres contrôlés par l'utilisateur peuvent modifier la requête construite par le node SeaTable.
CVE-2026-42228	WebSocket Chat Trigger	Un attaquant pouvant identifier un execution ID valide peut interagir avec une exécution en attente.
CVE-2026-42227	Contournement d'autorisation	Une clé API variable:list peut lire des variables d'un projet hors périmètre dans certains déploiements team/enterprise.
CVE-2026-42226	Fuite de credentials	Les endpoints dynamic-node-parameters peuvent utiliser un credential étranger dans un chemin contrôlé par l'attaquant.

Cette diversité impose une réponse méthodique. Certaines failles touchent l’exposition Internet. D’autres dépendent d’un utilisateur authentifié, de permissions workflow, d’un node précis ou d’une fonctionnalité activée.

Faille n8n et RCE: les nodes XML et Python doivent être regardés de près

Les vulnérabilités les plus sensibles sont celles qui peuvent conduire à une exécution de code.

Deux zones méritent une attention immédiate:

• les workflows utilisant le XML Node ou des webhooks XML;
• les workflows utilisant le Python Code Node avec le Python Task Runner activé.

Les avis GitHub de n8n indiquent que, si la mise à jour n’est pas possible immédiatement, les administrateurs peuvent temporairement limiter les droits de création et modification de workflows à des utilisateurs pleinement fiables. Pour les vulnérabilités XML, la désactivation du node n8n-nodes-base.xml via NODES_EXCLUDE est également citée comme mitigation temporaire. Pour le Python Task Runner, la désactivation du node code ou du runner Python peut réduire l’exposition.

Ce ne sont pas des remédiations complètes. Ce sont des mesures de réduction du risque en attendant le patch.

Faille n8n et credentials: le risque n’est pas théorique

CVE-2026-42226 est particulièrement importante dans les environnements collaboratifs.

Le scénario décrit concerne un utilisateur authentifié ayant accès à un workflow partagé. En fournissant une référence de credential qui ne lui appartient pas, il peut amener le backend à utiliser ce credential dans un chemin d’exécution où la destination est contrôlée par l’attaquant.

Dit plus simplement: si l’instance est vulnérable, un credential réutilisable peut être exposé par abus d’autorisation.

Après correction, il faut donc se poser une question supplémentaire: les credentials sensibles ont-ils été utilisés dans un contexte où ils auraient pu être exfiltrés ? Si le doute est sérieux, la rotation des secrets concernés doit être envisagée.

Faille n8n et bases de données: attention aux expressions et entrées externes

Plusieurs CVE concernent des injections SQL dans des nodes de base de données ou assimilés:

• Snowflake;
• ancien MySQL v1;
• Oracle Database;
• SeaTable.

Le risque augmente lorsque des entrées externes, par exemple issues d’un webhook, sont injectées via expressions dans des champs qui finissent dans une requête.

Sur une instance n8n, il faut donc auditer les workflows qui:

• acceptent des entrées utilisateurs;
• construisent dynamiquement des noms de tables, colonnes, clés ou limites;
• disposent de credentials base de données avec des droits larges;
• exposent des webhooks sur Internet.

Le patch est indispensable, mais le durcissement des workflows reste une bonne hygiène: valider les entrées, limiter les droits SQL, éviter les credentials sur-privilégiés et séparer les workflows selon leur niveau de criticité.

Mesures immédiates face à une faille n8n

Si vous exploitez n8n en self-hosted, nous recommandons une approche en 7 étapes.

1. Identifier la version installée
   Vérifier la version réelle de n8n, y compris dans les images Docker, tags, déploiements Kubernetes ou environnements de staging.

2. Mettre à jour vers une version corrigée
   Prioriser les versions corrigées de votre branche, avec une attention particulière à CVE-2026-42226 qui nécessite une version plus récente sur certaines branches.

3. Restreindre l’accès à l’instance
   Si n8n est exposé publiquement, limiter l’accès réseau, placer l’interface derrière un VPN, un SSO, un filtrage IP ou une protection d’accès adaptée.

4. Limiter les permissions workflow
   Réserver la création et modification de workflows aux utilisateurs réellement de confiance, surtout sur les instances multi-utilisateurs.

5. Auditer les nodes sensibles
   Chercher les usages de XML, Python Code Node, Git, Chat Trigger, MCP OAuth, Snowflake, MySQL v1, Oracle, SeaTable et nodes à credentials dynamiques.

6. Contrôler les credentials
   Identifier les secrets critiques, vérifier les accès récents et prévoir une rotation si l’exposition est plausible.

7. Surveiller après correction
   Observer les logs, les erreurs workflow, les connexions anormales, les appels sortants inattendus et les tentatives sur les endpoints MCP ou webhooks.

Ce que nous faisons dans ce type d’alerte

Chez Forget About IT, ce type de sujet entre directement dans le champ de l’exploitation courante: veille CVE, qualification de l’exposition, priorisation, patch, mitigation temporaire et vérification.

Une alerte comme celle-ci demande de croiser plusieurs informations:

• version réellement déployée;
• mode de déploiement;
• exposition Internet;
• fonctionnalités activées;
• workflows existants;
• permissions utilisateurs;
• secrets accessibles;
• dépendances métier des automatisations.

C’est ce travail de qualification qui évite les deux mauvaises réactions classiques: ignorer une alerte parce qu’elle paraît trop technique, ou patcher dans l’urgence sans mesurer les workflows critiques.

Conclusion

Cette série de failles n8n doit être traitée rapidement, surtout sur les instances self-hosted exposées, multi-utilisateurs ou connectées à des systèmes sensibles.

Le bon réflexe est clair:

• mettre à jour vers une version corrigée;
• réduire l’exposition réseau;
• limiter les permissions de création et modification de workflows;
• auditer les nodes et credentials concernés;
• surveiller les comportements anormaux après correction.

n8n est un outil puissant précisément parce qu’il connecte beaucoup de choses. C’est aussi pour cette raison qu’une vulnérabilité n8n doit être gérée avec sérieux, méthode et traçabilité.

• Découvrir notre offre d’infogérance
• Nous contacter
• Prendre rendez-vous

Sources

• NVD - CVE-2026-42237
• NVD - CVE-2026-42236
• NVD - CVE-2026-42235
• NVD - CVE-2026-42234
• NVD - CVE-2026-42233
• NVD - CVE-2026-42232
• NVD - CVE-2026-42231
• NVD - CVE-2026-42230
• NVD - CVE-2026-42229
• NVD - CVE-2026-42228
• NVD - CVE-2026-42227
• NVD - CVE-2026-42226
• GitHub Advisory - XML Node Prototype Pollution to RCE
• GitHub Advisory - Unauthenticated Denial of Service via MCP Client Registration
• GitHub Advisory - Python Task Runner Sandbox Escape
• Snyk - CVE-2026-42226
• Snyk - CVE-2026-42237

FAQ: faille n8n et CVE de mai 2026

Quelles versions corrigent les failles n8n de mai 2026 ?

Pour la majorité des CVE listées, les correctifs sont disponibles en 1.123.32, 2.17.4 et 2.18.1 ou versions ultérieures. CVE-2026-42226 nécessite 1.123.33, 2.17.5 ou 2.18.0 selon la branche.

Pourquoi une faille n8n est-elle critique sur une instance self-hosted ?

Parce que n8n manipule souvent des credentials, des webhooks, des bases de données, des workflows métier et parfois du code. Une compromission peut donc toucher à la fois l’application, les secrets et les systèmes connectés.

Les instances n8n non exposées publiquement sont-elles concernées ?

Oui, le risque baisse si l’instance n’est pas exposée à Internet, mais plusieurs vulnérabilités impliquent des utilisateurs authentifiés, des permissions workflow ou des credentials partagés. Le correctif reste nécessaire.

Que faire si la mise à jour n8n ne peut pas être appliquée immédiatement ?

Il faut restreindre l’accès réseau, limiter la création et l’édition de workflows aux utilisateurs de confiance, désactiver temporairement les nodes à risque quand c’est possible et planifier le patch au plus vite.

Faut-il faire tourner les workflows après la mise à jour ?

Oui. Après correction, il faut tester les workflows critiques, vérifier les nodes concernés, contrôler les credentials et surveiller les logs pour détecter d’éventuels comportements anormaux.