Tokens API n8n exposés sur GitHub : 321 instances acceptaient des identifiants compromis

L’accès authentifié ouvre la voie aux systèmes connectés

GitGuardian a identifié 4 576 tokens API n8n publiés dans 5 469 commits GitHub, associés à 1 255 noms d’hôte.

Parmi les 896 instances accessibles, 321 acceptaient au moins un token compromis. Cela représente 36 % des instances accessibles et environ 26 % des noms d’hôte détectés.

Il n’est pas nécessaire d’exploiter une vulnérabilité n8n. Un token encore valide et les API REST documentées peuvent suffire à obtenir un accès authentifié.

Workflows, identifiants et intégrations à portée d’attaque

n8n est une plateforme low-code destinée à automatiser les workflows, disponible en mode self-hosted et via n8n.cloud. Ses intégrations peuvent relier des bases de données, des dépôts, des environnements cloud, des services d’IA et des systèmes internes.

Dans un environnement contrôlé, GitGuardian a reproduit quatre techniques d’attaque. Un attaquant peut :

• lire les workflows et les données d’exécution ;
• créer ou modifier des automatisations ;
• utiliser les identifiants stockés dans les workflows ;
• extraire les valeurs correspondantes dans certaines configurations ;
• atteindre les systèmes downstream connectés.

Les identifiants sont chiffrés au repos avec N8N_ENCRYPTION_KEY, mais l’instance doit les déchiffrer pendant l’exécution. La protection de cette clé reste donc essentielle.

372 tokens MCP ont également été trouvés, dont 7 encore valides. Ces tokens peuvent accroître les risques lorsque des assistants d’IA invoquent des workflows ou interagissent avec l’environnement n8n.

Tokens sans expiration et versions obsolètes

Les tokens les plus anciens peuvent ne pas contenir le claim exp et rester ainsi valides indéfiniment. n8n a introduit une expiration par défaut de 30 jours dans la version 1.78.0, publiée en février 2025, mais cette modification n’invalide pas automatiquement les tokens générés auparavant.

Le risque est amplifié par l’exposition des instances : plus de 100 000 d’entre elles étaient visibles via Shodan. En outre, plus de 50 avis de sécurité étaient disponibles depuis janvier 2026 ; au 31 mars 2026, 58 % des instances analysées exécutaient des versions concernées par au moins un avis.

Parmi eux figure CVE-2025-68613, avec un score CVSS de 9,9, ajoutée au catalogue KEV le 11 mars 2026. Elle n’est toutefois pas nécessaire pour exploiter un scénario fondé sur des tokens valides.

Révocation immédiate et vérification des systèmes connectés

Les administrateurs devraient :

1. révoquer et régénérer les tokens n8n et MCP exposés ;
2. rechercher les tokens, noms d’hôte et références à des identifiants dans les dépôts publics et privés ;
3. mettre à jour n8n vers des versions non concernées par les avis de sécurité ;
4. appliquer des durées d’expiration courtes et une rotation automatique ;
5. limiter l’exposition à Internet et filtrer l’accès aux API ;
6. vérifier les workflows, les journaux d’exécution, les comptes et les systèmes downstream ;
7. protéger N8N_ENCRYPTION_KEY et réduire les privilèges des identifiants utilisés par les workflows.

La présence d’un token dans un commit historique doit être considérée comme une compromission, même si le fichier a ensuite été supprimé.