Mon instance Metabase n'est pas exposée sur Internet, puis-je attendre ?

Le risque est plus faible mais pas nul : la faille ne demande aucune authentification et reste exploitable depuis le réseau interne. Le contournement officiel — bloquer l'accès public à /api/session/reset_password — prend une dizaine de minutes.

Qui contacter en cas de compromission dans les Hauts-de-France ?

Le CSIRT Hauts-de-France, service gratuit de réponse à incident pour les PME, ETI, collectivités et associations de la région : 0806 700 111, du lundi au vendredi de 9 h à 12 h 30 et de 14 h à 17 h 30, ou csirt-hdf.fr. Le signalement au CERT-FR reste possible en parallèle.

Metabase : les versions citées par le CERT-FR sont sous le plancher éditeur

Q: Je suis sur Metabase Cloud, suis-je concerné par CVE-2026-72898 ?

Metabase Cloud a été corrigé avant la divulgation publique du 6 août 2026. L'éditeur indique que moins de 3 % de ses clients Cloud ont été compromis pendant la fenêtre antérieure au correctif. L'alerte CERTFR-2026-ALE-010 du 10 septembre 2026 vise les instances auto-hébergées.

Q: J'ai mis à jour Metabase dès le 6 août 2026, suis-je protégé ?

Sur cette CVE, oui à partir de x.58.24 ou l'équivalent. Mais un second avis est paru le 11 août, l'éditeur a relevé son plancher au 14 août (0.58.31, 0.59.28, 0.60.24, 0.61.18, 0.62.16, 0.63.13), et les branches 59 à 62 sont en fin de vie depuis le 1er septembre 2026. Il faut viser 0.58.31 (LTS) ou 0.63.13.

Q: Faut-il changer les mots de passe de toutes les bases connectées à Metabase ?

Oui. C'est la consigne de l'éditeur et du CERT-FR. Metabase stocke les identifiants de chaque base qu'il interroge ; un attaquant devenu administrateur a pu les lire. La mise à jour ferme la porte d'entrée mais ne révoque pas les identifiants déjà exfiltrés.

Le 10 septembre 2026, le CERT-FR a publié sa dixième alerte de l'année — un format qu'il réserve, selon sa propre définition, aux documents « destinés à prévenir d'un danger immédiat ». Objet : Metabase, l'outil de tableaux de bord que des milliers de PME, de startups et de collectivités installent elles-mêmes sur leur serveur parce qu'il est gratuit. La phrase qui compte tient en dix mots : « Le CERT-FR a connaissance de nombreuses compromissions de Metabase vulnérables. » La faille, CVE-2026-72898 (fiche NVD), est notée 10 sur 10. Elle permet à un inconnu, sans compte et sans mot de passe, de devenir administrateur d'une instance Metabase — et donc de récupérer les identifiants de toutes les bases de données que cette instance interroge. L'éditeur l'a rendue publique le 6 août, dans un billet de sécurité doublé d'un avis GitHub. L'alerte française est arrivée 35 jours plus tard. Nous avons fait ce que fait un administrateur système qui découvre l'alerte : ouvrir les documents publics qu'elle cite et comparer les numéros de version. Le résultat n'est pas celui que nous attendions. Trois listes de versions différentes circulent pour une seule et même faille, et celle que publie le CERT-FR le 10 septembre est trois correctifs en dessous du plancher que l'éditeur lui-même appelle « minimum safe release » depuis le 14 août. Plus gênant encore : quatre des six branches nommées dans l'alerte étaient en fin de vie depuis le 1^er septembre, neuf jours avant sa publication. Une PME qui tourne sur l'une de ces quatre branches et qui applique l'alerte à la lettre installe une version qui ne recevra plus jamais de mise à jour.

L'essentiel en six lignes

CVE-2026-72898, CVSS 10.0 : injection SQL sans authentification sur /api/session/reset_password, prise de contrôle administrateur.
Divulgée le 6 août 2026 par l'éditeur. Alerte CERT-FR le 10 septembre — J+35. Aujourd'hui, J+40.
L'alerte cite les versions x.58.28 / x.59.25 / x.60.21 / x.61.15 / x.62.13 / x.63.10.
L'éditeur, lui, fixe son plancher à 0.58.31 / 0.59.28 / 0.60.24 / 0.61.18 / 0.62.16 / 0.63.13 depuis le 14 août. Écart : 3 correctifs sur chacune des six branches.
Metabase 59, 60, 61 et 62 sont en fin de vie depuis le 1^er septembre 2026. Seules 58 (LTS) et 63 reçoivent encore des correctifs.
Si vous êtes touché dans les Hauts-de-France : CSIRT Hauts-de-France, gratuit, 0806 700 111.

Ce que dit l'alerte du 10 septembre — et la phrase qu'il ne faut pas lire trop vite

Le CERT-FR publie trois choses : des avis (plus de 1 170 depuis janvier), des bulletins d'actualité hebdomadaires, et des alertes. Les premières sont un flux ; les dernières sont un signal. Au 15 septembre 2026, le compteur des alertes de l'année affiche dix entrées. Metabase est la dixième. Le document tient en une page. Il classe le risque en une ligne — « Injection SQL (SQLi) » — puis il lâche la phrase qui justifie le changement de format :

Le 06 août 2026, Metabase a publié un avis de sécurité concernant une vulnérabilité critique permettant à un attaquant non authentifié de provoquer une injection SQL (SQLi) dans la base de donnée [sic] de l'application Metabase. Cette injection SQL permet d'obtenir les droits administrateur de l'instance. Le CERT-FR a connaissance de nombreuses compromissions de Metabase vulnérables.

« A connaissance de nombreuses compromissions » : ce n'est pas une projection, c'est un constat d'incidents traités. Le CERT-FR ne dit ni combien, ni où, ni dans quels secteurs. Nous n'avons pas sollicité l'agence pour obtenir ces chiffres et nous ne les inventons pas. Mais le passage du registre de l'avis à celui de l'alerte, cinq semaines après le correctif, dit quelque chose de simple : le parc français ne s'est pas mis à jour. L'alerte décrit aussi, et c'est sa partie la plus utile, la signature de l'attaque dans les journaux : un POST /api/session/reset_password qui répond 400, immédiatement suivi d'un GET /api/user/current qui répond 200. Une erreur, puis un succès. Deux lignes que n'importe quel administrateur peut chercher ce matin. Nous y revenons — il y a un piège d'orthographe.

Analyse technique indépendante de CVE-2026-72898 publiée sur la chaîne The ZeroDay Brief — décorticage de la chaîne d'exploitation et de la prise de contrôle administrateur. Cette vidéo n'émane ni de l'éditeur ni de l'ANSSI ; nous la citons comme document de vulgarisation technique, pas comme source d'autorité.

Trois listes de versions pour une seule faille : notre tableau comparatif

C'est ici que l'affaire devient un problème d'administrateur plutôt qu'un problème de sécurité. Nous avons relevé, le 15 septembre 2026, les numéros de version publiés par chacune des sources officielles ou de référence. Les voici côte à côte.

Source (relevée le 15/09/2026)	0.58	0.59	0.60	0.61	0.62	0.63
Avis GitHub de l'éditeur (GHSA-vwf4-m7j8-wcjf), publié le 06/08, « Patched versions » tel qu'affiché aujourd'hui	.24	.21	.17	.11	.9	.5
Dataminr, 12/08, citant explicitement le même avis GitHub	.28	.25	.21	.15	.13	.10
CERT-FR, alerte du 10/09 — « versions antérieures à »	.28	.25	.21	.15	.13	.10
Éditeur, « minimum safe release » — billet du 12/08, mis à jour le 14/08	.31	.28	.24	.18	.16	.13

Relevé Synapse du 15 septembre 2026. Sources ligne à ligne : avis GitHub de l'éditeur, note d'intelligence Dataminr du 12 août, alerte CERTFR-2026-ALE-010, billet « Security-focused Metabase Release Announcement » daté du 12 août et portant la mention « Updated 2026-08-14 ». Les versions Enterprise correspondantes portent le préfixe 1. au lieu de 0.

Trois observations, dans l'ordre où elles sautent aux yeux. Un. L'écart entre la ligne CERT-FR et la ligne « minimum safe release » de l'éditeur est de trois correctifs exactement, sur les six branches sans exception : 31−28, 28−25, 24−21, 18−15, 16−13, 13−10. Une régularité aussi propre suggère moins une erreur de saisie que deux instantanés successifs d'un même train de publication. Deux. Le jeu de versions publié par le CERT-FR le 10 septembre est identique à celui que Dataminr attribuait à l'avis GitHub le 12 août. Or cet avis, tel que nous l'avons lu aujourd'hui, affiche des numéros plus bas (.24 / .21 / .17 / .11 / .9 / .5). Autrement dit, la page de l'éditeur ne dit plus en septembre ce qu'elle disait en août. Nous ne pouvons pas le prouver au-delà de cette divergence de citation — GitHub n'expose pas l'historique de révision d'un avis sur la page publique — et nous le signalons donc comme une divergence, pas comme une modification établie. Trois. La borne basse (.24 sur la branche 58) est corroborée de façon indépendante et technique : les chercheurs de Wiz ont reconstitué la faille en comparant les archives Java v0.58.22 et v0.58.24, et ont trouvé le correctif dans la seconde. Le correctif de cette CVE-là a donc bien atterri en .24. Ce qui vient après — .28, puis .31 — relève d'un second avis (GHSA-r495-55cx-fjh7, publié le 11 août) et d'un durcissement plus large.

La mise en balance qui s'impose

Rien de tout cela ne fait du CERT-FR un service en défaut. Le champ « Systèmes affectés » d'une alerte décrit le périmètre d'une vulnérabilité ; la liste « minimum safe release » de l'éditeur décrit le plancher d'un produit après une campagne de durcissement. Les deux documents ne répondent pas à la même question et peuvent légitimement diverger. Mais l'administrateur d'une PME, lui, ne lit qu'un seul document — et c'est en général celui qui est en français, sur un site en gouv.fr. C'est cette asymétrie-là qui est le problème, pas l'arithmétique.

Quatre des six branches citées par l'alerte sont mortes depuis le 1^er septembre

Le deuxième constat est plus brutal, et il ne souffre aucune interprétation : il est écrit sur la page de support des versions de l'éditeur, qui grise les branches arrivées en fin de vie.

Branche citée par l'alerte du 10/09	Sortie	Fin de vie	État au 15/09/2026
Metabase 58 (LTS)	17 décembre 2025	17 février 2027	Maintenue — 155 jours de vie restante
Metabase 59	12 février 2026	1^er septembre 2026	Fin de vie depuis 14 jours
Metabase 60	26 mars 2026	1^er septembre 2026	Fin de vie depuis 14 jours
Metabase 61	30 avril 2026	1^er septembre 2026	Fin de vie depuis 14 jours
Metabase 62	1^er juin 2026	1^er septembre 2026	Fin de vie depuis 14 jours
Metabase 63	7 juillet 2026	1^er novembre 2026	Maintenue — 47 jours de vie restante

Dates relevées le 15 septembre 2026 sur la page « Version support » de l'éditeur. Cette page annonce un suivi de 14 mois pour les versions LTS — la branche 58 le respecte au jour près — et « habituellement 2 mois » pour les autres. Les dates observées sont en réalité plus généreuses que cette règle : de 3 mois pour la branche 62 à près de 7 pour la branche 59. Elle est donc à lire comme un plancher, pas comme un calendrier.

Récapitulons la chronologie, parce qu'elle est peu banale. La faille est divulguée le 6 août. Vingt-six jours plus tard, le 1^er septembre, quatre des six branches concernées cessent d'être maintenues. Neuf jours après cela, le 10 septembre, le CERT-FR publie une alerte qui les nomme toutes les six et renvoie, pour chacune, à un numéro de correctif. La conséquence pratique est désagréable à écrire mais simple : une entreprise qui tourne aujourd'hui en 0.61 et qui applique scrupuleusement l'alerte du CERT-FR se retrouve en 0.61.15 — une version qui corrige cette faille-ci, qui reste en dessous du plancher de l'éditeur, et qui ne recevra plus jamais le moindre correctif de sécurité. Elle aura fait exactement ce qu'on lui a demandé, et elle sera à découvert dès la prochaine vulnérabilité.

La seule bonne cible : 0.58.31 ou 0.63.13

Il n'y a que deux destinations défendables au 15 septembre 2026, et elles se déduisent du croisement des deux tableaux ci-dessus :

Les deux seules versions à viser

0.58.31 (ou 1.58.31 en Enterprise) — la branche LTS. Maintenue jusqu'au 17 février 2027. C'est le choix de la tranquillité : 155 jours avant la prochaine échéance, contre 47 sur la branche courante.
0.63.13 (ou 1.63.13) — la branche courante. Maintenue jusqu'au 1^er novembre 2026, soit 47 jours. C'est le choix de ceux qui ont besoin des fonctionnalités récentes et qui assument de remonter de version majeure d'ici moins de sept semaines.
Toute autre destination — 59, 60, 61, 62, quel que soit le numéro de correctif — est une impasse. Ces branches ne reçoivent plus rien depuis le 1^er septembre.

L'éditeur donne lui-même l'exemple dans son billet du 12 août, mis à jour le 14 (notre traduction) : « si vous utilisez 0.58.6, vous devriez passer en 0.58.31 ou plus récent ». La formule « ou plus récent » est importante : la maison a annoncé, dans le même texte, qu'elle suspendait ses livraisons de fonctionnalités au profit de versions mineures hebdomadaires centrées sur la sécurité et l'observabilité. Le plancher du 14 août n'est donc pas un sommet — c'est un plancher.

« A tour of Metabase: self-hosting » — webinaire de l'éditeur sur l'auto-hébergement. C'est très exactement la population concernée par cette alerte : les instances installées et maintenues par l'entreprise elle-même, par opposition à Metabase Cloud, corrigé par l'éditeur avant même la divulgation publique.

Comment la faille fonctionne : quatre couches, une clé oubliée

L'éditeur a publié le 27 août un compte rendu d'incident d'une franchise rare, qui permet de raconter la chaîne sans approximation. Elle repose sur l'empilement de quatre comportements individuellement défendables.

Les annotations de type de l'API n'étaient pas « fermées ». Le point d'entrée de réinitialisation de mot de passe attendait deux champs, token et password. La validation vérifiait que ces deux-là étaient présents et bien typés — mais n'interdisait pas les champs supplémentaires.
Un remaniement du système d'authentification, le 11 novembre 2025 (la modification est publique), a changé le passage de paramètres : au lieu de ne transmettre que token et password, la fonction s'est mise à transmettre le corps entier de la requête.
Plus loin dans la chaîne d'authentification, si un identifiant d'utilisateur était présent, l'enregistrement correspondant était cherché en base par la couche d'accès aux données — avec, comme identifiant, la valeur venue directement du corps de la requête.
Cette couche génère ses requêtes avec une bibliothèque qui accepte une clé spéciale raw : quand elle la rencontre, elle insère la chaîne telle quelle dans le SQL, sans paramétrage ni échappement.

Il suffisait alors d'envoyer un corps de requête contenant, à côté du jeton et du mot de passe, un troisième champ du genre {"user_id": {"raw": "1);INSERT INTO ...; --"}}. L'attaque réellement observée, décrite par l'éditeur, a consisté à insérer une ligne dans la table des sessions avec l'identifiant utilisateur 1 — le premier compte créé sur toute instance Metabase, systématiquement administrateur — puis à se servir de cette session pour parcourir les données et créer une clé API permettant le téléchargement de tables entières. La vulnérabilité a vécu 265 jours sans être remarquée, entre le remaniement du 11 novembre 2025 et le premier signalement client du 3 août 2026. Aucune des quatre couches n'était fautive seule. C'est leur assemblage qui l'était.

Le vrai périmètre du sinistre : ce n'est pas Metabase, ce sont vos bases

Un outil de tableaux de bord n'a aucune donnée propre à voler. Ce qu'il détient, en revanche, ce sont les identifiants de connexion de chacune des bases qu'il interroge : la base de production, l'entrepôt de données, l'export de facturation, la base RH. Devenir administrateur d'un Metabase, ce n'est pas voler des graphiques — c'est récupérer le trousseau de clés. C'est pourquoi la remédiation de l'éditeur ne s'arrête pas à la mise à jour et impose de changer les mots de passe de toutes les bases connectées. C'est l'étape que tout le monde saute, et c'est la seule qui referme vraiment la porte.

Les deux lignes à chercher dans vos journaux — et le piège d'orthographe

La partie opérationnelle de l'alerte tient en deux requêtes consécutives. Mais en croisant les documents, nous avons relevé deux orthographes concurrentes du même point d'entrée d'API — auxquelles s'ajoute, pour brouiller les pistes, l'adresse web du formulaire, qui ne s'écrit comme aucune des deux. La divergence n'est pas cosmétique : elle décide si votre grep renvoie quelque chose ou rien.

Document	Chaîne écrite
Alerte CERT-FR du 10/09	`/api/session/reset_password`
Avis GitHub de l'éditeur du 06/08	`/api/session/reset_password`
Commande de vérification publiée par Wiz le 10/08	`/api/session/reset_password`
Note Dataminr du 12/08	`/api/session/reset_password`
Compte rendu d'incident de l'éditeur du 27/08, bloc « signature »	`/api/session/password-reset`
Compte rendu d'incident, corps du texte	`/reset-password` (l'adresse web, pas l'API)

Relevé Synapse du 15 septembre 2026, cinq documents et six mentions. Quatre sources sur cinq convergent sur reset_password ; le bloc « signature » du compte rendu de l'éditeur est le seul à écrire password-reset. La dernière ligne, /reset-password, désigne l'adresse web du formulaire et non le point d'entrée d'API : elle n'apparaîtra pas dans les mêmes journaux. Nous n'avons pas sollicité l'éditeur pour trancher, et présentons donc les deux graphies d'API.

La recommandation de prudence est de chercher les deux. Une commande qui ne présume de rien, à passer sur les journaux d'accès du serveur web ou du répartiteur de charge placé devant Metabase :

grep -E '(reset_password|password-reset)' access.log | grep ' 400 '

Puis, pour chaque adresse IP qui ressort, vérifier si la même IP a enchaîné dans la seconde sur un GET /api/user/current répondant 200. C'est l'enchaînement échec puis succès qui fait la signature : un mot de passe refusé suivi immédiatement d'une session valide n'a aucune explication légitime. Un dernier détail, moins connu et dérangeant : selon Wiz, le point d'entrée /api/session/properties révèle publiquement la version de l'instance. Autrement dit, depuis le 6 août, n'importe qui peut dresser l'inventaire des Metabase vulnérables sans exploiter quoi que ce soit — il suffit de lire un numéro de version. C'est ce qui explique les chiffres de la section suivante.

11 000 instances recensées, 4 309 probablement vulnérables : l'échelle réelle

Deux mesures indépendantes, prises à quelques jours d'intervalle, permettent de cadrer le problème.

Dataminr, balayage du 8 août : environ 11 000 hôtes identifiés comme des instances Metabase auto-hébergées, dont 4 309 tournant probablement une version vulnérable. Et surtout : plus de 97 % des hôtes identifiés sur une branche affectée apparaissaient non corrigés — quarante-huit heures après la divulgation.
Wiz, 10 août : 13 % des environnements cloud observés hébergent une instance Metabase auto-installée, et environ un quart de ces instances est pleinement accessible depuis Internet. En données publiques ouvertes à tous, le moteur d'inventaire Shodan référençait alors environ 2 500 instances Metabase — un décompte plus étroit que celui de Dataminr parce qu'il ne recense que ce qui est indexé, pas ce qui existe.
Secteurs concernés d'après le relevé Dataminr : administrations, santé, énergie, finance, télécommunications, aviation et grandes organisations publiques. L'analyste précise que le partage d'adresses IP dans le cloud masque la propriété réelle et que l'exposition est « presque certainement sous-estimée ».
Côté hébergé : l'éditeur indique que « moins de 3 % » de ses clients Cloud ont été compromis avant le correctif. Metabase Cloud a été corrigé avant la divulgation publique — c'est l'auto-hébergement qui porte le risque.

Les victimes qui se sont déclarées publiquement entre le 7 et le 10 août dessinent bien le profil : Framework et Tally le 7 août, n8n le 8, Kilo Code (Anaconda) le 9, Checkly le 10. Des éditeurs de logiciels, des entreprises technologiques, exactement le genre d'organisation qui sait ce qu'est un correctif. Checkly a publié le détail le plus parlant : l'attaquant a interrogé son entrepôt de données pendant environ 26 minutes le 3 août. n8n a chiffré l'impact à 136 enregistrements contenant des noms et des adresses e-mail. Vingt-six minutes. C'est la durée qui sépare, dans cette affaire, une instance ouverte d'un incident à notifier.

Une revendication à manier avec des pincettes

Une entrée « Metabase » est apparue sur le site d'extorsion associé à la marque ShinyHunters. Dataminr la décrit comme une coquille vide, sans périmètre annoncé, accompagnée de 7 Go de données seulement, en net décalage avec les autres entrées du site, et la classe explicitement comme non confirmée. Nous la mentionnons pour cette raison seule : parce qu'elle circule. Elle ne constitue pas une attribution.

Pourquoi une PME des Hauts-de-France est précisément la cible visée

Metabase se distribue sous deux formes : un service hébergé, payant, corrigé par l'éditeur ; et une version libre que l'on télécharge et que l'on installe soi-même, gratuite. La faille n'a fait de victimes durables que dans la seconde. Et la seconde est, par construction, le choix des organisations qui comptent leurs dépenses. La région comptait, selon un relevé EuraTechnologies portant sur l'année 2021, 17 522 entreprises du numérique dont 95 % de PME, ce qui la plaçait au sixième rang national. L'Insee dénombrait de son côté quelque 29 000 actifs exerçant un métier numérique dans les Hauts-de-France, avec une concentration massive sur l'axe Lille-Roubaix-Tourcoing : six emplois numériques sur dix. Ces deux relevés ont plusieurs années ; nous les citons pour l'ordre de grandeur et la structure du tissu, pas pour un décompte au présent. Et il faut y ajouter toutes les organisations qui ne sont pas « du numérique » mais qui ont un tableau de bord : une clinique, une communauté de communes, un logisticien de la plaine de la Scarpe, un négociant agricole.

Un ordre de grandeur, et pourquoi nous nous arrêtons là

La tentation serait d'appliquer les 13 % de Wiz aux 17 522 entreprises du numérique régionales et d'annoncer un nombre. Nous ne le ferons pas, et il vaut la peine de dire pourquoi : la base de Wiz, ce sont les environnements cloud de ses clients — de grandes organisations déjà équipées — pas l'ensemble des entreprises d'un secteur. Transposer ce taux à un tissu composé à 95 % de PME produirait un chiffre faux avec une apparence de précision.

Ce que l'on peut dire sans se tromper tient en une phrase : des organisations de la région utilisent Metabase, le plus souvent en auto-hébergement, et au 8 août plus de 97 % des hôtes identifiés dans le monde sur une branche affectée apparaissaient non corrigés. Aucun organisme ne publie de décompte régional, et nous n'avons balayé aucun système tiers pour en établir un. Le nombre, nous ne l'avons pas.

Le scénario régional le plus probable n'est d'ailleurs pas l'attaque ciblée : c'est le balayage. Depuis que la version d'une instance se lit publiquement et que des démonstrateurs d'exploitation circulent en source ouverte — depuis le 10 août à midi UTC, selon Wiz —, l'inventaire des cibles est une opération triviale. Nous décrivions le même mécanisme le mois dernier à propos d'une préproduction laissée accessible chez un éditeur de santé, et en juillet à propos d'une faille critique de WordPress : dans les deux cas, ce qui a fait la différence n'était pas la sophistication de l'attaquant, mais le délai de mise à jour du défenseur.

L'éditeur pense que l'attaquant s'est fait aider par un modèle de langage

Le passage le plus inhabituel du compte rendu du 27 août est celui-ci. Interrogé sur ce qu'il compte faire pour éviter une récidive, l'éditeur écrit (notre traduction) que « compte tenu de la complexité de cette attaque, de la connaissance requise de notre base de code et du comportement de deux dépendances imbriquées, nous pensons que cette attaque a nécessité des capacités de modèle de langage significatives ». Il ne s'arrête pas à l'intuition. Il produit un indice matériel : les premières requêtes portaient des identifiants de navigateur explicites — l'éditeur cite metabase-postgres-admin-session-lab-verifier/1 et metabase-read-only-sqli-verifier/1 — avant de basculer sur une rotation de 25 variantes imitant Chrome, Edge et Firefox. Des chaînes d'outil de recherche laissées en place, puis effacées. Deux réserves de méthode s'imposent. D'une part, un identifiant de navigateur se forge en une ligne de code : il constitue un indice, pas une preuve. D'autre part, c'est la victime qui qualifie son agresseur, ce qui n'est jamais la position la plus neutre. Mais la conséquence tirée par l'éditeur, elle, est vérifiable dans ses actes : plutôt que de corriger la seule faille, il a engagé un durcissement sur une dizaine d'axes — fermeture par défaut de la validation des schémas sur tous les points d'entrée, interdiction de l'émission de SQL brut sans échappement, unification des contrôles de permissions — et fait relire son code par des équipes extérieures, qu'il nomme : le cabinet Ophion Security et l'équipe offensive du laboratoire d'IA américain Anthropic. Si l'hypothèse de l'éditeur est exacte, le détail ne manque pas d'ironie : les mêmes technologies serviraient des deux côtés de la table. Le fil de discussion du forum communautaire de l'éditeur garde trace des questions posées à la suite de ce compte rendu.

Compte tenu de l'augmentation extrêmement rapide des capacités des modèles de langage en analyse de code, et de leur aptitude à enchaîner des chaînes d'attaque profondes, nous durcissons Metabase couche par couche plutôt que de nous arrêter à la correction de cette seule vulnérabilité.

Pour une PME, la traduction opérationnelle est brutale et n'a rien de spéculatif : la fenêtre entre la publication d'un correctif et son exploitation de masse se referme. Dans cette affaire, quatre jours ont séparé la divulgation de la mise en ligne de démonstrateurs publics. Le calendrier de correction « on verra au prochain comité » ne tient plus contre ce rythme.

Si vous êtes touché : le CSIRT Hauts-de-France, gratuit, au 0806 700 111

L'alerte du CERT-FR demande, en cas de compromission, de signaler l'événement « en mettant en copie vos éventuels CSIRT métier ». La formule est obscure pour une entreprise de vingt personnes. Traduction : il existe, dans la région, un centre de réponse aux incidents financé sur fonds publics, gratuit, et dont c'est exactement le métier.

Le CSIRT Hauts-de-France en pratique

Pour qui : PME, ETI, collectivités territoriales et associations implantées dans la région. Les grands groupes et les opérateurs d'importance vitale relèvent directement du CERT-FR.
Combien : gratuit. C'est un service de réponse à incident de premier niveau, issu d'un programme du plan France Relance de 2021.
Téléphone : 0806 700 111, du lundi au vendredi, 9 h – 12 h 30 et 14 h – 17 h 30. En dehors de ces horaires, un formulaire est disponible en ligne.
En ligne : csirt-hdf.fr — le centre est aussi joignable via urgencecyber.com.
Ce qu'il fait : préqualification de l'incident, assistance de premier niveau, mise en relation avec des prestataires qualifiés de proximité, et suivi jusqu'au rétablissement.

Le dispositif national compte 15 CSIRT territoriaux et un centre de ressources cyber, un par région ou presque, listés sur le site du CERT-FR. Celui des Hauts-de-France est opérationnel depuis son lancement par la Région et relayé par la CCI régionale. Il porte également une mission d'observatoire de la menace sur le territoire — ce qui, dans le cas présent, en fait le seul acteur susceptible de savoir si des entités régionales figurent parmi les « nombreuses compromissions » évoquées par le CERT-FR.

« Les CSIRT régionaux, maillons essentiels de la cybersécurité nationale » — table ronde sur le rôle des centres territoriaux de réponse à incident, le point d'entrée gratuit prévu pour les PME, collectivités et associations, dont celui des Hauts-de-France.

Deux précisions utiles. D'abord, signaler n'est pas se dénoncer : le CSIRT n'est ni un service d'inspection ni une autorité de sanction. Ensuite, si la compromission touche les données personnelles de clients ou de salariés, l'obligation de notification à la CNIL sous 72 heures s'applique indépendamment, et court à partir du moment où vous avez connaissance de la violation. Pour les fabricants de produits numériques, le réflexe des 24 heures institué par le Cyber Resilience Act est entré en vigueur le 11 septembre, quatre jours avant cet article. Les trois compteurs sont distincts et se cumulent.

Neuf réflexes pour les prochaines quarante-huit heures

Recenser. Metabase s'installe en une commande : il y en a souvent plus d'un dans une entreprise, et le second a généralement été monté « pour tester » par une équipe métier. Cherchez les conteneurs nommés metabase et le port 3000, y compris chez vos prestataires.
Lire la version. Elle s'obtient sans identifiants sur /api/session/properties. Si un attaquant peut le faire, vous aussi.
Mettre à jour vers 0.58.31 ou 0.63.13 — pas vers les numéros de l'alerte. Les branches 59 à 62 sont mortes le 1^er septembre ; y appliquer un correctif revient à repeindre une façade condamnée.
Si la mise à jour ne peut pas être faite aujourd'hui, bloquer le point d'entrée. C'est le contournement officiel : interdire l'accès public à /api/session/reset_password au niveau du serveur frontal ou du pare-feu applicatif. Cela prend dix minutes.
Invalider toutes les sessions après la mise à jour, en vidant la table core_session de la base applicative. Une session ouverte avant le correctif reste valide après.
Passer en revue les clés API et supprimer celles que personne ne reconnaît. C'est par là que les données sont sorties dans l'attaque documentée.
Vérifier les comptes administrateurs, en particulier tout compte créé ou promu depuis le 3 août.
Changer les mots de passe de toutes les bases connectées. L'étape la plus lourde, la plus souvent omise, et la seule qui referme réellement la porte : les identifiants étaient stockés dans l'instance compromise.
Relire les journaux — ceux de Metabase et ceux des bases interrogées — depuis le 3 août, pas depuis le jour de votre mise à jour. L'exploitation précède la divulgation publique.

Les fiches réflexes du CERT-FR sur la qualification et l'endiguement d'une compromission système complètent utilement cette liste, et le formulaire de signalement du CERT-FR reste ouvert en parallèle du CSIRT régional.

Ce que nous n'avons pas pu vérifier

Pourquoi le CERT-FR a retenu ce jeu de versions. Deux lectures se défendent — un périmètre volontairement limité à cette CVE, ou une reprise de l'état d'un document depuis modifié. Nous n'avons pas sollicité l'ANSSI, et nous ne tranchons pas.
Si l'avis GitHub de l'éditeur a été modifié entre le 12 août et aujourd'hui. La citation de Dataminr diffère de ce que la page affiche aujourd'hui ; GitHub n'expose pas l'historique de révision d'un avis sur sa page publique. La divergence est établie, la modification ne l'est pas.
Laquelle des deux orthographes du point d'entrée apparaît réellement dans les journaux. Quatre documents sur cinq écrivent reset_password ; le bloc « signature » du compte rendu de l'éditeur écrit password-reset. D'où notre recommandation de chercher les deux.
Si des entités des Hauts-de-France figurent parmi les compromissions connues du CERT-FR. L'alerte n'indique ni nombre, ni secteur, ni géographie.
La réalité de la revendication ShinyHunters, classée « non confirmée » par la seule source qui la documente.
Le nombre d'instances Metabase dans la région. Personne ne le publie. Nous n'avons balayé aucun système tiers et n'avons testé aucune instance appartenant à autrui : tous les relevés de cet article portent sur des documents publics.

Nous n'avons sollicité ni l'ANSSI, ni l'éditeur, ni le CSIRT Hauts-de-France avant publication. Cet article repose entièrement sur des documents publiés, relevés et horodatés le 15 septembre 2026.

Questions fréquentes

Je suis sur Metabase Cloud. Suis-je concerné ?

Beaucoup moins, mais pas indifférent. L'éditeur a corrigé sa plateforme hébergée avant la divulgation publique du 6 août, et indique que « moins de 3 % » de ses clients Cloud ont été compromis pendant la fenêtre antérieure au correctif. Si vous étiez client Cloud début août, la question pertinente n'est donc pas « dois-je mettre à jour » — c'est fait — mais « ai-je été notifié, et les identifiants de mes bases connectées ont-ils été changés depuis ? ». L'alerte du CERT-FR, elle, vise les instances auto-hébergées.

Mon Metabase n'est pas exposé sur Internet. Puis-je attendre ?

Le risque est nettement plus faible, mais deux nuances comptent. D'abord, « pas exposé » se vérifie depuis l'extérieur, pas depuis le bureau : beaucoup d'instances réputées internes sont en réalité publiées par un reverse proxy ou un tunnel installé pour un besoin ponctuel. Ensuite, la faille ne demande aucune authentification : elle est donc exploitable par quiconque atteint l'instance, y compris depuis le réseau interne — un poste compromis par hameçonnage suffit. Compte tenu du contournement disponible en dix minutes, l'attente ne se justifie pas.

J'ai mis à jour dès le 6 août. Suis-je tranquille ?

Sur cette faille précise, oui, si vous êtes passé au moins en x.58.24 ou l'équivalent sur votre branche. Mais deux choses ont bougé depuis. Un : l'éditeur a publié le 11 août un second avis couvrant d'autres vulnérabilités, puis relevé son plancher au 14 août (0.58.31 / 0.59.28 / 0.60.24 / 0.61.18 / 0.62.16 / 0.63.13). Deux : si vous êtes sur les branches 59 à 62, celles-ci sont en fin de vie depuis le 1^er septembre. Une mise à jour d'août ne suffit plus : il faut viser 58 LTS ou 63. Et si votre point d'entrée de réinitialisation était public, la remédiation complète — sessions, clés API, mots de passe des bases connectées — s'applique même à ceux qui ont corrigé vite.

Faut-il vraiment changer les mots de passe de toutes les bases connectées ?

C'est la consigne de l'éditeur et celle du CERT-FR, et c'est la plus importante de la liste. Metabase stocke les identifiants de connexion de chaque base qu'il interroge. Un attaquant devenu administrateur a pu les lire. Une mise à jour ferme la porte d'entrée, elle ne révoque pas les clés déjà emportées. L'ordre de priorité raisonnable : les bases contenant des données personnelles ou financières d'abord, les entrepôts analytiques ensuite. Prévoyez une fenêtre de maintenance : c'est l'étape qui casse des intégrations si elle est faite à la hâte.

Dois-je déclarer quelque chose si je découvre une compromission ?

Trois obligations distinctes peuvent se déclencher, et elles ne se remplacent pas. Le signalement au CERT-FR, demandé par l'alerte, n'est pas une sanction : c'est ce qui permet la coordination, et il peut passer par le CSIRT Hauts-de-France (0806 700 111, gratuit). La notification à la CNIL sous 72 heures s'impose si des données personnelles sont concernées, à compter de la connaissance de la violation, avec information des personnes en cas de risque élevé. Enfin, si vous mettez vous-même un produit numérique sur le marché de l'Union, le réflexe des 24 heures du Cyber Resilience Act s'applique depuis le 11 septembre 2026. Nous ne sommes pas juristes : sur les deux dernières, faites confirmer votre situation par un conseil.

Méthode

Tous les relevés de versions, de dates de fin de vie et d'orthographes de point d'entrée ont été effectués le 15 septembre 2026 sur les pages publiques citées. Aucun système tiers n'a été balayé ni testé. Les deux identifiants de vidéo intégrés ont été vérifiés par l'interface oEmbed de la plateforme avant publication. Les décomptes de jours sont calculés en jours calendaires depuis les dates portées par les documents eux-mêmes.

Suivi prévu : nous relèverons à nouveau l'état de l'alerte CERTFR-2026-ALE-010 et les numéros de version publiés par le CERT-FR et par l'éditeur à l'approche du 1^er novembre 2026, date de fin de vie de la branche 63.