n8n Enterprise sur alerte: la défaillance du lien d'identité entre émetteurs de confiance pourrait vous permettre de vous connecter comme un autre utilisateur

n8n, la plate-forme d'automatisation de workflow, fin juin, a corrigé une grave défaillance qui vous a permis de vous connecter comme un autre utilisateur sans connaître votre mot de passe lorsque l'instance Enterprise avait activé la fonction d'échange de knock et fait confiance à plus d'un émetteur externe. En termes techniques, la racine du problème était lien d'identité erroné: le système a comparé seulement la revendication JWT entrante "sous" avec les utilisateurs locaux et n'a pas pris en considération le problèmeRFC 7519, et le flux d'échange des jetons que n8n met en œuvre suit RFC 8693.

Dans la pratique, l'échec signifiait qu'un jeton légitime signé par un émetteur A qui comprenait un "sous" égal à celui d'un utilisateur créé par l'émetteur B pouvait être accepté par n8n comme s'il s'agissait de cet autre utilisateur. Le vecteur d'attaque spécifique qui permettrait à un attaquant d'obtenir un jeton valide n'est pas expliqué dans l'avis public; cela laisse une incertitude quant à savoir si un utilisateur normal dans l'un des émetteurs pourrait forcer ou obtenir un « sous- ». Les bases de données sur la vulnérabilité du public reflètent différentes évaluations : l'AIIC a attribué un score élevé dans le CVSS 4.0 alors que le NVD l'a inscrit avec une gravité inférieure dans le CVSS 3.1. La CISA a enregistré l'incidence et, pour l'instant, n'a pas confirmé l'exploitation active sur le terrain.

La portée technique est cependant assez précise: elle n'affecte que les déploiements d'Entreprise qui ont permis l'échange de jetons et cette confiance au moins deux clés de diffusion configuré dans la variable N8N _ TOKEN _ ÉCHANGE _ TRUSTED _ KEYS. Autrement dit, la zone exposée est réduite et correspond généralement à des implémentations OEM ou intégrées où n8n accepte des jetons signés par des partenaires. n8n distribué l'arrangement dans des versions spécifiques du produit; si votre environnement utilise une version antérieure, il devrait être considéré vulnérable jusqu'à ce qu'il soit mis à jour.

Si vous gérez ou dépendez d'une instance n8n Enterprise, les actions prioritaires sont claires et urgentes: d'abord, vérifiez la version que vous exécutez et planifiez la mise à jour le patch le plus récent, y compris la correction. En parallèle, si vous ne pouvez pas vous garer immédiatement, réduisez l'exposition en désactivant la fonction d'échange de jetons ou en limitant la configuration pour ne compter que sur un seul émetteur. Localiser et examiner la variable N8N _ TOKEN _ ÉCHANGE _ TRUSTED _ KEYS, confirmer qui sont les émetteurs de confiance et, le cas échéant, supprimer les entrées inutiles jusqu'à ce que la solution finale puisse être appliquée. Ces mesures d'atténuation sont temporaires et, comme le soulignent les avertissements techniques, ne remplacent pas la mise à jour du logiciel.

D'autres mesures de défense comprennent le renforcement de la télémétrie et des dossiers : permettre et revoir l'authentification et les métiers d'échange de jetons à la recherche de connexion inhabituelle, mettre en place des alertes pour les nouvelles sessions avec des identités externes, activer l'authentification multifactorielle pour les comptes locaux avec des privilèges et réduire les permis inutiles dans les workflows et les identifiants. Si votre déploiement appuie les dossiers de vérification externe ou le SGI, exportez ces événements pour une corrélation plus large et pour faciliter les enquêtes.

Cette vulnérabilité ne vient pas isolément : dans les semaines précédentes, n8n a corrigé une défaillance d'entreprise différente qui a permis de manipuler les identifiants OAuth à travers des paramètres d'identification dynamiques, suggérant que les déploiements avec des fonctionnalités d'aperçu ou des intégrations OEM méritent un examen particulier et continu. Pour suivre les communications et correctifs officiels, il convient de ne pas se fier uniquement aux changements habituels : l'arrangement d'identité spécifique n'apparaît pas toujours dans les notes de changement de colis, et l'information officielle peut résider dans l'avis de sécurité ou la base CVE. Maintenir une surveillance active des sources de fournisseurs et des dépôts publics de vulnérabilité NVD et la documentation des produits en N8n documentation.

Enfin, évaluer la nécessité d'informer les utilisateurs concernés et d'entreprendre une analyse médico-légale s'il existe des preuves d'accès non autorisé. Bien qu'il n'y ait pas de preuve publique d'exploitation massive à l'heure actuelle, le vecteur permet l'accès sans mot de passe dans des conditions spécifiques, et toute exposition de lettres de créance ou de flux de travail inattendus devrait être traitée comme un incident potentiel. La leçon opérationnelle est claire : lorsque vous faites confiance à des jetons externes, le code de lien d'identité doit respecter pleinement le modèle iss + sub et les implémentations qui simplifient cette vérification sont en danger. Examiner la configuration, appliquer des correctifs et améliorer la surveillance sont des étapes essentielles pour atténuer le problème.