Vérifiez d’abord si n8n vous a contacté directement. C’est le signal le plus important. Je vous explique ce qui s’est passé, quelles données ont été exposées, ce que n8n et Metabase ont corrigé, et quoi faire sans paniquer.
Que s’est-il passé exactement ?
L’incident vient d’une vulnérabilité Metabase exploitée pour exécuter des requêtes non autorisées dans l’environnement Metabase interne de n8n.
Dit autrement, quelqu’un a utilisé une faille dans Metabase pour interroger des données auxquelles il n’aurait pas dû accéder. Une requête, c’est simplement une demande envoyée à une base de données pour lire ou extraire certaines informations. Là, le problème ne vient pas d’un workflow n8n compromis, ni d’un accès généralisé à toute la plateforme. Le point d’entrée était Metabase.
Metabase, pour situer, c’est un outil tiers d’analyse et de reporting. Beaucoup d’équipes l’utilisent pour explorer des données internes, créer des tableaux de bord, suivre des métriques. Dans ce cas précis, n8n l’utilisait dans son environnement interne. C’est cette brique-là qui a été touchée.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
| Date de l’activité non autorisée | 3 août 2026 |
| Date à laquelle n8n a été informé | 6 août 2026 |
| Outil concerné | Metabase, un outil tiers d’analyse |
| Nature de l’accès | Exécution de requêtes non autorisées dans un environnement interne |
La faille Metabase exploitée a depuis été corrigée. C’est important, mais ça ne suffit pas à tout résumer. Quand il y a un incident sécurité, le réflexe naturel c’est de chercher le scénario catastrophe. Est-ce que tout n8n a été pris en main ? Est-ce que les workflows clients ont été modifiés ? Est-ce que les instances ont été compromises ? D’après les éléments communiqués, ce n’est pas ce qui est décrit ici.
Le vrai sujet, c’est le périmètre des données consultées via ces requêtes. C’est là qu’il faut regarder froidement. Pas le bruit autour de l’incident, pas les raccourcis du type “n8n hacké”, mais quelles données étaient accessibles depuis ce Metabase interne, lesquelles ont été interrogées, et ce que ça implique concrètement pour les utilisateurs concernés.
Je préfère être clair là-dessus : ce n’est pas anodin, parce qu’un accès non autorisé à des données internes reste un incident sérieux. Mais ce n’est pas non plus la même chose qu’une compromission globale de n8n. La différence compte énormément quand on doit décider quoi faire maintenant.
Quelles données ont été exposées ?
Les données concernées portent sur 136 enregistrements, avec des niveaux de sensibilité très différents. Ce point est important, parce que tout n’a pas la même gravité dans un incident de sécurité. Un nom et une adresse e-mail, ce n’est déjà pas neutre. Un mot de passe, même haché, c’est un autre niveau de risque.
Après l’examen médico-légal du 11 août 2026, n8n a séparé les enregistrements en plusieurs groupes. J’aime bien cette approche, parce qu’elle évite de tout mettre dans le même sac et elle permet de savoir quoi faire concrètement.
- 7 Enregistrements contenant des noms d’utilisateur cloud et des adresses e-mail ont été confirmés comme consultés.
- 5 Enregistrements contenant des noms, des noms d’utilisateur cloud, des adresses e-mail et des mots de passe n8n Cloud hachés en bcrypt ont aussi été confirmés comme consultés. Bcrypt est une méthode de hachage conçue pour rendre un mot de passe difficile à retrouver à partir de sa version stockée. Ce n’est pas du clair, mais ça reste une donnée sensible.
- 62 Enregistrements contenant des noms et des adresses e-mail peuvent avoir été consultés. Là, n8n n’a pas pu confirmer précisément, enregistrement par enregistrement, lesquels ont été vus.
- 62 Autres enregistrements ne contenaient pas d’informations sensibles. D’après n8n, ils ne présentent pas de risque pour les utilisateurs.
N8n indique avoir contacté directement les personnes des trois premiers groupes. Donc si vous n’avez reçu aucun message de leur part, ça veut dire que vos données personnelles n’étaient pas concernées par ces lots-là. C’est le signal le plus simple à retenir.
Il y a aussi un point séparé, un peu gênant mais corrigé depuis. Une anomalie historique avait entraîné le stockage en clair des mots de passe pour un petit nombre de comptes n8n Cloud. Même si ce cas est distinct, n8n a contacté par précaution les 25 titulaires concernés.
| Données concernées | Nombre d’enregistrements | Niveau de confirmation | Action n8n |
| Noms d’utilisateur cloud et adresses e-mail | 7 | Consultation confirmée | Personnes contactées directement |
| Noms, noms d’utilisateur cloud, adresses e-mail et mots de passe hachés bcrypt | 5 | Consultation confirmée | Personnes contactées directement |
| Noms et adresses e-mail | 62 | Consultation possible, sans confirmation individuelle | Personnes contactées directement |
| Données non sensibles | 62 | Aucun risque identifié | Pas de contact nécessaire |
Quelles mesures ont été prises ?
Metabase et n8n ont corrigé, isolé et revu les éléments potentiellement affectés. C’est la réponse claire à retenir ici. On n’est pas sur une annonce floue du type “on surveille la situation”. Les deux parties ont décrit des actions concrètes, avec une logique assez classique de gestion d’incident.
Côté Metabase, la vulnérabilité a été corrigée. Les sessions concernées ont été terminées, ce qui revient à couper les accès encore actifs liés au problème. Les identifiants utilisés ont aussi été révoqués. Dit simplement, on ferme la porte, on force la sortie des sessions qui posent question, puis on rend inutilisables les clés ou identifiants qui ont pu servir.
Côté n8n, plusieurs actions ont été menées dans la même logique :
- Revue des journaux d’audit, c’est-à-dire l’historique des actions enregistrées dans le système.
- Rotation des identifiants potentiellement affectés, donc remplacement des accès qui pouvaient être concernés.
- Correction des utilisateurs impactés par le bug historique identifié.
- Information du délégué à la protection des données, le DPO, et du Commissaire berlinois à la protection des données et à la liberté d’information.
C’est exactement le genre de séquence que je regarde chez mes clients après un incident. Corriger la faille. Couper les accès. Vérifier les logs. Prévenir les personnes concernées. Documenter. Rien de magique, mais c’est là que se joue une grosse partie de la qualité de réponse.
Ce qui m’intéresse dans ce type de situation, ce n’est pas seulement “est-ce que la faille est corrigée ?”. C’est aussi “est-ce que les accès liés ont été neutralisés ?”, “est-ce que les traces ont été relues ?”, “est-ce que les bons interlocuteurs ont été informés ?”. Là, les mesures annoncées vont dans ce sens. Elles restent factuelles, ciblées, et alignées avec une réponse d’incident propre.
Que devez-vous faire maintenant ?
Si vous avez reçu un e-mail direct de n8n, réinitialisez votre mot de passe immédiatement et suivez les instructions reçues. C’est la priorité. Même si vous utilisez un mot de passe unique, même si vous avez l’impression que le risque est limité, ne laissez pas ça traîner.
Dans ce type d’incident, le bon réflexe c’est de réduire la fenêtre de risque. Vous changez le mot de passe, vous vérifiez vos accès, et vous gardez un œil sur les connexions ou comportements inhabituels. Si vous avez activé une authentification renforcée, comme le MFA, c’est-à-dire une validation en plus du mot de passe, gardez-la bien active. Si ce n’est pas encore fait, c’est le bon moment pour s’y mettre.
Si vous n’avez pas été contacté directement par n8n, les éléments communiqués indiquent que vos données personnelles n’étaient pas concernées. Dit autrement, n8n n’a pas identifié votre compte comme faisant partie des comptes à risque dans cette alerte.
Ça ne vous empêche pas de réinitialiser votre mot de passe n8n Cloud par précaution. C’est simple, ça prend peu de temps, et ça évite de rester avec un doute. La procédure est disponible dans l’article d’aide n8n mentionné par l’entreprise, sans besoin de chercher une méthode alternative ou de passer par des manipulations bizarres.
Si vous avez une question spécifique, ou si vous n’êtes pas sûr de votre situation, vous pouvez écrire directement à help@n8n.io. Je préfère toujours passer par le canal officiel dans ces moments-là, surtout quand il s’agit d’accès, de comptes cloud ou de données potentiellement exposées.
Observation honnête : Je conseille souvent de traiter ce genre d’alerte comme une bonne occasion de nettoyer ses accès, même quand on n’est pas directement touché. On supprime les anciens comptes, on change les mots de passe faibles, on vérifie qui a accès à quoi. Chez un client, on avait découvert trois accès inutilisés juste après une alerte comme celle-ci. Rien de dramatique, mais c’est exactement comme ça qu’on réduit le risque réel.
| Situation | Action recommandée |
| E-mail reçu de n8n | Réinitialisez votre mot de passe immédiatement et suivez les consignes reçues. |
| Pas d’e-mail reçu | Vos données personnelles ne semblent pas concernées, mais vous pouvez changer votre mot de passe par précaution. |
| Doute ou question | Contactez n8n à help@n8n.io et évitez les sources non officielles. |
On fait quoi maintenant ?
Le point important, c’est le périmètre. L’incident sécurité Metabase chez n8n a bien exposé certains enregistrements, mais n8n a identifié les groupes concernés, corrigé les accès, prévenu les personnes touchées et documenté les mesures prises. Si vous avez reçu un e-mail, vous agissez tout de suite. Si vous n’avez rien reçu, le risque personnel annoncé est écarté, même si changer votre mot de passe reste une bonne hygiène. Mon conseil est simple : gardez une trace de l’incident, vérifiez vos accès, et profitez-en pour renforcer vos réflexes sécurité. Vous gagnez en clarté et en contrôle.
FAQ
- Que s’est-il passé dans l’incident sécurité Metabase n8n ?
Une vulnérabilité Metabase a été exploitée pour exécuter des requêtes non autorisées dans l’environnement Metabase interne de n8n. L’activité a eu lieu le 3 août 2026 et n8n en a été informé le 6 août 2026. Metabase a depuis corrigé la faille. - Quelles données n8n ont été concernées ?
136 enregistrements ont été examinés. Certains contenaient des noms, adresses e-mail, noms d’utilisateur cloud et, pour 5 enregistrements, des mots de passe n8n Cloud hachés en bcrypt. Une partie des enregistrements ne contenait pas d’informations sensibles. - Dois-je changer mon mot de passe n8n Cloud ?
Si vous avez reçu un e-mail direct de n8n, changez votre mot de passe immédiatement. Si vous n’avez pas été contacté, vos données personnelles n’étaient pas concernées selon n8n, mais vous pouvez quand même réinitialiser votre mot de passe par précaution. - Les mots de passe exposés étaient-ils en clair ?
Pour les 5 enregistrements confirmés, les mots de passe n8n Cloud étaient hachés en bcrypt. n8n mentionne aussi une anomalie historique corrigée qui avait entraîné le stockage en clair de mots de passe pour un petit nombre de comptes. Les 25 titulaires concernés ont été contactés directement par précaution. - Qui contacter en cas de doute sur cet incident ?
n8n indique que les questions peuvent être envoyées à help@n8n.io. En pratique, je conseille aussi de garder l’e-mail reçu, de noter la date de changement de mot de passe et de vérifier les accès actifs sur votre compte.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes sur des sujets où la donnée, les accès, les outils tiers et la sécurité opérationnelle se croisent très vite. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez sécuriser vos automatisations, vos données ou vos workflows n8n, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.




