Retour au blog
n8nOAuthOIDCwebhookauto-hébergementagents IA

n8n : dix vulnérabilités corrigées le 10 septembre 2026

Publié le 2026-09-10 · Mis à jour le 2026-10-295 min de lecture
En bref : Le 10 septembre 2026, n8n a publié dix avis de sécurité de gravité moyenne. Ils sont corrigés dans 1.123.76 (branche 1.x) et dans 2.38.1 ou 2.38.2 (branche 2.x selon l'avis). Ils couvrent un contournement du consentement OAuth (CVE-2026-86073), des points de terminaison OIDC désactivés qui restent actifs (CVE-2026-86084), une fuite de données personnelles entre projets (CVE-2026-86085), l'exposition d'identifiants par le streaming de journaux (CVE-2026-86993) et une évasion de chemin du nœud Git (CVE-2026-86995).

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>.remote du 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 ?

  1. Relevez la version de chaque instance (interface ou n8n --version) et comparez-la à 1.123.76, 2.38.1 et 2.38.2.
  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.
  3. 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.
  4. Relisez les destinations de journaux : qui peut les créer, et quels identifiants y sont rattachés ?
  5. 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.

Sachez ce que votre agent peut faire avant un attaquant.

Rendez-vous découverte de 30 minutes, gratuit : vous décrivez votre agent, je vous dis ce que je testerais et à quel prix. Cinq études de cas sont publiées.

Prendre rendez-vous