Des tokens n8n exposés publiquement dans des commits GitHub représentent un risque qui dépasse largement le simple “mot de passe trouvé”. Selon une analyse de GitGuardian, ces identifiants peuvent fournir un accès authentifié à des instances n8n, permettant de consulter des workflows, d’exploiter des connexions stockées et, dans certains cas, d’obtenir des secrets en clair.
Concrètement, l’étude ne repose pas sur une faille logicielle exploitée via une CVE. Elle s’appuie sur des comportements attendus de l’API REST et sur des appels HTTP standards. Résultat : même dans un contexte correctement patché, des identifiants valides divulgués peuvent servir de porte d’entrée.
Ce que l’étude a retrouvé dans GitHub
Les chercheurs ont scruté des commits publics afin d’y repérer des tokens d’API n8n exposés. L’ensemble de la recherche a identifié 4 576 identifiants uniques associés à 1 255 noms d’hôte, à partir d’un corpus de commits incluant des informations de contexte (comme l’instance cible).
Ensuite, ils ont vérifié l’impact réel : sur 896 instances joignables au moment des tests, 321 acceptaient au moins un token divulgué. Dit autrement, 36% des instances atteignables dans l’échantillon répondaient positivement à des requêtes d’authentification fondées sur des secrets exposés, soit environ 26% de l’ensemble des hôtes recensés dans les commits.
L’analyse ne s’arrête pas à l’API REST : elle inclut aussi des clés liées à l’API Model Context Protocol (MCP), conçues pour permettre à des assistants IA d’appeler des workflows via MCP. Sur 372 tokens MCP identifiés, seuls 7 restaient valides lors de la validation, mais ils constituent une surface d’exposition supplémentaire.
Pourquoi n8n attire l’attention
n8n est une plateforme d’automatisation de workflows à code faible/open source, utilisée pour connecter des systèmes entre eux. Les organisations l’exploitent pour orchestrer des intégrations : bases de données, dépôts de code, environnements cloud, services d’intelligence artificielle, outils de support client et bien d’autres briques internes.
Le point clé, c’est que n8n agit comme un “intermédiaire” entre plusieurs systèmes. Un utilisateur configure des nœuds qui déclenchent des traitements (via planification ou webhooks) et qui accèdent à des services externes en s’appuyant sur des identifiants stockés : API keys, tokens, mots de passe de base de données, etc.
En théorie, ces secrets sont chiffrés au repos avec une clé de chiffrement (par exemple N8N_ENCRYPTION_KEY). Mais au moment de l’exécution d’un workflow, la plateforme doit les déchiffrer et les utiliser. Ainsi, si un attaquant obtient des droits suffisants via un token n8n exposé, il peut potentiellement faire exécuter à n8n des actions au nom de ce compte.
Des tokens qui restent valides plus longtemps que prévu
Les chercheurs expliquent qu’une clé d’API n8n correspond à un jeton signé de type JSON Web Token, avec une audience indiquée comme public-api. Un élément important ressort : de nombreuses clés trouvées ne semblaient pas porter de date d’expiration explicite.
Un changement de politique a été introduit dans une version récente : un délai d’expiration par défaut de 30 jours à partir de la version 1.78.0 (février 2025). Mais dans la période couverte par l’étude, beaucoup de tokens présents dans les commits avaient été générés sans champ d’expiration.
Autre nuance : même si un token est “valable” selon son contenu, il ne suffit pas qu’il soit signé. L’accès dépend aussi du fait que la clé existe encore dans la base de données de l’instance. Tant que l’instance la reconnaît, le secret reste exploitable.
Comment valider rapidement un token divulgué
Pour tester un token candidat, il n’est pas nécessaire de modifier le workflow ni de réaliser de brute force. Un simple appel en lecture permet de déterminer si l’instance accepte le secret.
Le principe observé consiste à transmettre le token dans l’en-tête X-N8N-API-KEY, puis à interroger l’endpoint qui retourne les workflows accessibles à l’utilisateur authentifié. Une réponse 200 indique que le token est accepté ; un 401 signale qu’il est invalide ou absent ; un 404 peut indiquer que l’API publique est désactivée.
Cette approche souligne un point de défense : les identifiants divulgués ne doivent pas être évalués uniquement par “chance de fonctionnement”. Leur acceptation par l’instance est le facteur déterminant.
L’avantage de l’association “hostname + token”
Un token n8n exposé n’est utile à un attaquant que s’il sait à quelle instance il correspond. Or, dans les commits publics analysés, les chercheurs ont souvent trouvé le nom d’hôte (ou l’URL de l’instance) collé au token.
Ils citent notamment des exemples où une variable d’environnement ou un fichier de configuration contient à la fois l’adresse d’exécution et la clé API. Dans ces cas, la validation peut être effectuée sans phase supplémentaire de “découverte” d’infrastructure.
Ils mentionnent aussi des schémas associés à des fichiers de permissions utilisés par des environnements de type “Claude Code”, où l’utilisateur peut inclure une commande curl contenant l’URL et le secret dans un fichier susceptible d’être versionné. Selon les patterns observés, ces paramètres apparaissent parfois sous plusieurs noms de variables, ce qui augmente le risque de publication accidentelle.
Qu’est-ce qu’un token authentifié peut révéler
Un token d’API n8n donne accès à ce que le créateur du token était autorisé à faire. Dans l’analyse, beaucoup de tokens semblaient liés à des profils ayant des privilèges élevés (propriétaires ou administrateurs), ce qui élargit considérablement le périmètre.
En fonction des rôles, l’API publique peut renvoyer des informations telles que :
- utilisateurs : noms, adresses e-mail, dates de création, invitations en attente (certaines données étant réservées aux propriétaires) ;
- workflows : définitions complètes, y compris la configuration des nœuds et du code dans des nœuds “Code” (avec, parfois, des secrets présents dans des paramètres) ;
- credentials : noms, types et informations de partage, sans révéler forcément les valeurs brutes (endpoint restreint) ;
- exécutions : historique des runs, et potentiellement les entrées/sorties si des paramètres permettent d’inclure les données ;
- data tables : lignes accessibles à l’utilisateur authentifié ;
- variables : noms et contenus, souvent réservés aux propriétaires/administrateurs.
Les définitions de workflows sont particulièrement sensibles : elles peuvent contenir des requêtes, des paramètres, et parfois des valeurs en clair si l’intégration a été câblée directement dans le nœud plutôt que via un coffre de credentials.
L’audit n8n : une cartographie des chemins d’attaque
Une autre fonction mentionnée est l’endpoint d’audit, qui permet à un utilisateur authentifié d’obtenir un rapport de sécurité sur l’instance. Dans le scénario des chercheurs, la réponse peut aider à prioriser des actions.
Le rapport peut identifier notamment :
- des expositions de type injection SQL dans des workflows ;
- des nœuds disposant d’accès au système de fichiers ;
- des webhooks non protégés ;
- la version en cours afin de la comparer à des vulnérabilités connues ;
- des credentials inutilisés ;
- des nœuds “community-installed” à risque ;
- des paramètres de sécurité activés ou désactivés ;
- des listes d’autorisation/blocage pour certains nœuds ;
- des informations de télémétrie.
Pour un administrateur légitime, cela sert à accélérer un examen. Pour un attaquant disposant d’un token n8n exposé, c’est une feuille de route concrète.
Quatre techniques démontrées sur une instance de test
Les chercheurs indiquent ne pas avoir mené ces actions contre des systèmes tiers exposés. En revanche, ils ont reproduit les scénarios dans un environnement n8n préparé pour la recherche. Le workflow de test comportait plusieurs points volontaires : un formulaire enregistrant des soumissions dans une table de données, un nœud OpenAI utilisant un credential stocké, et un nœud HTTP Request publiant une sortie vers GitHub en utilisant un token intégré dans les paramètres du nœud.
Technique 1 : énumérer l’instance
Le départ est “passif” : l’attaquant interroge des endpoints de lecture, comme la liste des utilisateurs et des workflows. L’objectif est de repérer les configurations accessibles, puis d’identifier des secrets potentiellement présents dans la structure des workflows.
Dans la démonstration, le workflow cible contenait des paramètres d’un nœud HTTP Request avec un token en clair. Le simple fait d’être authentifié suffisait à récupérer cette information.
Technique 2 : utiliser un credential OpenAI stocké
La seconde étape consiste à repérer les objets credential via l’endpoint approprié. L’utilisateur voit alors le nom et l’identifiant du credential, sans forcément récupérer directement la valeur.
Ensuite, les chercheurs ont créé un workflow déclenché par planification, utilisant le credential stocké. Après un court délai, ils ont récupéré les exécutions et, grâce à la restitution des entrées/sorties, la réponse OpenAI est apparue en clair. Le credential a donc servi de base à des actions arbitraires sans que sa valeur soit dévoilée.
Technique 3 : lire une table de données
La troisième étape réutilise le même principe : créer/activer un workflow qui lit toutes les lignes d’une table de données accessible par les permissions. Puis, quelques secondes plus tard, récupérer l’exécution et extraire les lignes exposées.
Dans l’environnement contrôlé, des champs sensibles (comme noms, e-mails et informations de soumission) ont été exfiltrés via les résultats d’exécution, puis le workflow a été supprimé.
Technique 4 : exfiltrer une valeur de credential en clair
La dernière technique franchit un cap. Au lieu d’exécuter un workflow “pour utiliser” un credential, elle vise à récupérer la valeur brute.
Le scénario décrit : un listener HTTP externe est démarré, puis un workflow planifié est configuré avec un nœud HTTP Request qui s’authentifie en utilisant le credential OpenAI stocké. Quand le workflow s’exécute, la plateforme envoie la valeur du credential sous forme de token Bearer dans l’en-tête Authorization vers l’infrastructure de l’attaquant. La valeur est capturée peu après l’activation.
Après la démonstration, le workflow malveillant est supprimé. Les chercheurs notent que cela peut aussi retirer les traces associées côté interface, compliquant la tâche d’investigation.
Ce qui ressort des cas réels
La démonstration n’était pas purement théorique. Lors de l’étude, plusieurs instances réelles présentaient des schémas analogues.
Par exemple, un workflow automatisait une sauvegarde de ses propres définitions vers un dépôt GitHub public. Dans ce processus, une clé SSH de déploiement était intégrée directement dans un nœud. Comme les versions précédentes apparaissaient aussi dans l’historique Git, la clé restait valide et rejouable pendant la fenêtre de publication.
Divulgation responsable : des réponses inégales
Le risque n’est pas “résolu” par la seule découverte. Le secret reste dangereux jusqu’à ce qu’il soit révoqué et que les effets en aval soient traités.
Les chercheurs ont tenté une divulgation responsable auprès de plusieurs organisations. Les réponses observées varient : un acteur disposait d’un bug bounty, a reconnu le rapport, payé une récompense (1 200 dollars) et a révoqué rapidement le credential. Dans d’autres cas, il n’y a eu que peu ou pas de réponse.
Ils indiquent aussi avoir contacté n8n pendant l’étude. La plateforme a reconnu les signalements et indiqué être au courant, puis les tickets ont été fermés. Au moment de la publication, GitGuardian ne confirmait pas indépendamment que l’ensemble des correctifs était déjà disponible.
Plan d’action pour réduire l’exposition
Retenez l’idée centrale : les tokens n8n exposés ne sont pas un incident isolé. Selon les droits du compte à l’origine du token, ils peuvent permettre de consulter des workflows, d’exposer des secrets intégrés dans des paramètres, de lire des données via les exécutions et même d’exploiter des credentials stockés en faisant agir n8n comme intermédiaire.
Révoquer le token est une première étape indispensable, mais souvent insuffisante. Il faut ensuite :
- identifier quels workflows et quelles données étaient accessibles ;
- vérifier si des secrets ou des credentials connectés ont pu être utilisés en aval ;
- réaliser une revue de l’instance pour repérer des changements non autorisés ;
- faire tourner (rotation) les credentials liés lorsque l’exposition ne peut pas être éliminée avec certitude.
Enfin, gardez en tête l’effet “concentrateur” de n8n : parce que la plateforme relie des systèmes multiples, un seul identifiant peut ouvrir un chemin vers des bases de données, des services cloud, des APIs IA, des plateformes de support et des données clients. La surface de risque se définit donc autant par l’écosystème connecté que par n8n lui-même.
Conclusion
Cette recherche montre que des tokens n8n exposés dans des commits GitHub constituent une voie d’accès authentifiée exploitable sans CVE ni outillage spécialisé. À partir d’un simple appel REST, un attaquant peut cartographier l’instance, utiliser des credentials stockés, extraire des données depuis les exécutions et, dans certaines configurations, obtenir des valeurs de secrets.
Pour les équipes sécurité et DevOps, le message est clair : surveiller les fuites de secrets, révoquer immédiatement les clés exposées et évaluer le périmètre d’accès en aval sont essentiels pour éviter qu’un incident de divulgation ne se transforme en compromission plus large.
Source: https://thehackernews.com/2026/08/leaked-n8n-api-tokens-exposed-live.html
