n8n : dix vulnérabilités corrigées le 10 septembre 2026
Pourquoi n8n est-il une cible de choix ?
n8n orchestre des flux entre CRM, messagerie, bases de données, paiements et, de plus en plus, modèles d'IA. Une instance détient donc des identifiants à forte valeur pour des dizaines de services et un accès réseau vers l'intérieur de l'entreprise. Une faille « moyenne » sur un tel outil se lit autrement que sur une application isolée.
Quels sont les dix avis publiés le 10 septembre ?
Tous sont classés « medium » dans le registre GitHub et publiés le même jour :
- CVE-2026-86073 (GHSA-cw9w-vv67-hf73) : contournement du consentement OAuth par substitution de ressource via un jeton de rafraîchissement non lié ; versions 2.38.0 uniquement, corrigé en 2.38.1.
- CVE-2026-86084 (GHSA-pf83-w3f9-8m37) : points de terminaison OIDC SSO désactivés qui restent actifs et émettent des sessions valides ; avant 1.123.76.
- CVE-2026-86085 (GHSA-cqr2-h44g-v75v) : divulgation de données personnelles entre projets faute de contrôle de portée sur l'attribution des rôles ; 2.38.0 et 2.38.1, corrigé en 2.38.2.
- CVE-2026-86994 (GHSA-65xw-2v52-jhxc) : divulgation d'identifiants de workflows actifs d'autres utilisateurs ; avant 1.123.76.
- CVE-2026-86074 (GHSA-q5wm-mgqx-fv2f) : la configuration d'identifiants de l'IA intégrée accepte une URL non validée issue d'un contenu récupéré ; 2.38.0 et 2.38.1, corrigé en 2.38.2.
- CVE-2026-86993 (GHSA-pq6c-vh67-xpm3) : les destinations de streaming de journaux déchiffrent des identifiants sans contrôle de propriétaire ; avant 1.123.76.
- CVE-2026-86995 (GHSA-qgpw-8g46-w95v) : la clé de configuration
branch.<name>.remotedu nœud Git contourne la restriction de chemin du bac à sable ; avant 1.123.76. - CVE-2026-86080 (GHSA-5m98-cgcr-xx3q) : le déclencheur GitHub saute le stockage du secret de webhook dans un cas de réutilisation, et la vérification de signature échoue en mode ouvert ; avant 1.123.76.
- CVE-2026-86079 (GHSA-f2cp-m7mv-8jpv) : injection de chemin dans les nœuds Elasticsearch et ElasticSecurity via des identifiants non encodés ; avant 1.123.76.
- CVE-2026-86078 (GHSA-679f-58pq-4v2c) : pollution de prototype menant à un déni de service ; 2.38.0 et 2.38.1, corrigé en 2.38.2.
Les plages exactes de versions sont celles du registre GitHub des avis ; vérifiez la vôtre avant de conclure que vous êtes à l'abri.
Qui est concerné ?
Les instances auto-hébergées sur les versions listées, en priorité celles qui partagent une instance entre plusieurs utilisateurs ou projets (fuites entre projets, identifiants de workflows), celles qui exposent des webhooks ou un SSO, et celles qui exécutent le nœud Git. Une instance mono-utilisateur derrière un VPN a moins à craindre des failles d'isolation, mais pas des failles de configuration.
Comment détecter et tester l'exposition ?
- Relevez la version de chaque instance (interface ou
n8n --version) et comparez-la à 1.123.76, 2.38.1 et 2.38.2. - Vérifiez l'OIDC : si vous l'avez désactivé dans l'interface, testez depuis l'extérieur que les points de terminaison de connexion répondent bien par une erreur.
- Contrôlez les webhooks : un webhook GitHub doit rejeter une requête sans signature valide ; envoyez une requête non signée à un webhook de test et vérifiez le refus.
- Relisez les destinations de journaux : qui peut les créer, et quels identifiants y sont rattachés ?
- Inventoriez les nœuds Git : quels dépôts, quels chemins, quels droits.
Comment corriger ?
Mettez n8n à jour vers 1.123.76 pour la branche 1.x, ou vers 2.38.2 pour la branche 2.x. Après la mise à jour, faites tourner les identifiants stockés sur toute instance partagée ou exposée, vérifiez les sessions SSO actives, et régénérez les secrets de webhook. Appliquez le principe de moindre privilège aux comptes de service que n8n utilise.
Que change l'accès d'un agent IA à n8n ?
n8n héberge souvent des agents : un nœud « AI Agent » appelle un modèle, lit des e-mails ou des tickets, puis déclenche des outils (CRM, messagerie, paiement). Les identifiants de ces outils sont stockés dans l'instance. Une faille qui expose des identifiants (streaming de journaux), contourne un SSO (OIDC) ou accepte un webhook non signé (déclencheur GitHub) donne à l'attaquant le pouvoir de l'agent, pas seulement celui de l'utilisateur d'un compte.
L'avis CVE-2026-86074 est parlant : la configuration d'identifiants de l'IA intégrée accepte une URL issue d'un contenu récupéré. C'est la structure d'une injection de prompt indirecte : un contenu lu devient une instruction qui oriente une requête sortante (OWASP LLM01, et LLM06 pour les droits excessifs). Un webhook sans vérification de signature joue le même rôle : n'importe qui peut déclencher un workflow qui contient un agent et ses outils. Voir la validation de signature des webhooks n8n et l'injection de prompt indirecte.
Les contrôles propres aux agents : un jeu d'identifiants par workflow avec portée minimale, des webhooks signés et rejetés par défaut, aucune URL ou aucun chemin dérivé d'un contenu externe sans liste d'autorisation, et une validation humaine avant les actions d'écriture. Voir aussi la sécurité des agents IA et, pour une autre faille n8n récente, CVE-2026-59208 sur l'échange de jetons JWT.
Pourquoi plusieurs failles moyennes peuvent-elles s'enchaîner ?
Prises isolément, ces failles demandent des conditions : un compte authentifié, un accès au réseau, une configuration précise. Combinées, elles se renforcent : un identifiant lu dans un flux de journaux ouvre l'accès à une API, une session OIDC qui aurait dû être fermée donne un point d'appui, un webhook non vérifié déclenche le workflow qui utilise ces identifiants. C'est pourquoi un audit regarde les chemins entre les composants plutôt qu'un score unique.
Que vérifier côté agent avec les failles n8n de septembre 2026 ?
Un test de red team d'agent envoie un contenu piégé à un workflow n8n (e-mail, ticket, formulaire, appel de webhook) et observe les appels sortants, les identifiants utilisés et les actions déclenchées. Le Red Team Agent Express (1 900 €, 5 jours) rejoue sur votre agent les scénarios n8n : webhook piégé, nœud d'exécution, identifiants enregistrés. La méthode détaille la démarche.
Quelle leçon en tirer ?
Dix avis moyens en une journée décrivent un projet qui corrige vite. Pour un outil qui détient les clés de toute l'entreprise, « moyen » signifie surtout qu'il faut mettre à jour sans attendre et vérifier ce que l'agent peut atteindre.
Pour aller plus loin
Votre produit embarque un agent IA ? CleanIssue teste ce qu’un inconnu peut lui faire faire avec le Red Team Agent Express (5 jours, 1 900 €), ou un red team sur mesure pour plusieurs agents et serveurs MCP. Premier échange : un rendez-vous découverte de 30 minutes, gratuit.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
n8n CVE-2026-59208 : JWT token exchange et identité
CVE-2026-59208 : n8n liait l'identité JWT au seul claim sub. Versions corrigées 2.27.4 et 2.28.1, tests et risque pour les agents IA délégués.
Webhooks n8n : URL exposées, workflows déclenchés par tous
Une URL de webhook n8n dans le JavaScript suffit à déclencher un workflow sans compte, jusqu’à créer des admins. Exploitation, test, authentification.
Zoom CVE-2026-53412 : prise de contrôle de compte (CVSS 9.8)
CVE-2026-53412 permet une prise de contrôle de compte Zoom par le réseau (CVSS 9.8). Versions, correctifs, détection et risques pour un agent IA.
Sources
- GitHub Advisory : n8n OAuth consent bypass (CVE-2026-86073)
- GitHub Advisory : n8n disabled OIDC endpoints remain active (CVE-2026-86084)
- GitHub Advisory : n8n log streaming credentials (CVE-2026-86993)
- GitHub Advisory : n8n Git node sandbox bypass (CVE-2026-86995)
- GitHub Advisory : n8n AI credential setup URL (CVE-2026-86074)
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.