Faille Metabase : comment une injection SQL a piégé l’ANSSI et la Dinum, et qui devait la corriger

La faille Metabase, référencée CVE-2026-72898, est une injection SQL exploitable à distance sans aucun identifiant : elle donne à l’attaquant les droits d’administrateur de l’instance. Corrigée par l’éditeur le 6 août 2026, elle a été exploitée sur des serveurs restés à jour trop tard, dont ceux du laboratoire d’innovation de l’ANSSI et deux instances de la Dinum. Si vous utilisez Metabase, vérifiez votre version aujourd’hui.

En bref

• Score de gravité maximal (CVSS 10,0) ; les versions 58 et suivantes non corrigées sont touchées, les versions antérieures à la 58 ne le sont pas selon l’éditeur.
• Neuf instances au sein des ministères compromises, selon le bilan de l’opération REACTIV du 30 septembre 2026.
• Les clients de Metabase Cloud ont été corrigés par l’éditeur ; les instances auto-hébergées dépendaient de leur administrateur.
• Mettre à jour ne suffit pas : sessions, clés d’API et mots de passe des bases connectées doivent être renouvelés.

Ce qu’est la faille Metabase, en clair

Metabase est un outil de tableaux de bord : on le branche sur des bases de données, et il permet de poser des questions aux données sans écrire de code. Sa version libre est publiée sous licence AGPL, ce qui explique sa large adoption dans les administrations et les jeunes entreprises.

Le problème se situe dans la fonction de réinitialisation du mot de passe. D’après l’avis de sécurité publié par l’éditeur sur GitHub, une requête forgée vers /api/session/reset_password permet d’injecter du SQL arbitraire dans la base interne de Metabase, celle qui stocke les comptes, les sessions et la configuration. Résultat : l’attaquant obtient une session valide, puis un accès administrateur.

Dans son retour d’expérience du 27 août, Metabase décrit une attaque en chaîne qui exploitait l’interaction de quatre couches de son code : une validation des paramètres qui acceptait des champs non prévus, une refonte du système d’authentification (novembre 2025) qui transmettait désormais toute la requête au lieu du seul jeton et du mot de passe, puis une recherche de l’utilisateur par un identifiant fourni par l’attaquant. Aucun de ces défauts n’était dangereux seul ; leur combinaison l’était. L’éditeur relève que les premières requêtes portaient des signatures évoquant l’usage d’un modèle de langage, et dit durcir tout son code face aux progrès de l’analyse de code par IA : c’est son interprétation, pas un fait établi par un tiers.

Pourquoi cette faille est plus grave qu’une fuite ordinaire

Un outil de tableaux de bord est un trousseau de clés. Pour afficher des graphiques, Metabase conserve les identifiants des bases de production auxquelles il est relié. L’avis GitHub liste explicitement l’extraction de ces identifiants et l’accès à toutes les données connectées parmi les conséquences possibles. Prendre la main sur Metabase, c’est potentiellement prendre la main sur tout ce qu’il interroge. C’est ce point, plus que les 118 comptes, qui doit inquiéter un responsable informatique.

Chronologie : six jours d’avance, puis des semaines de retard

La séquence, reconstituée à partir des publications de Metabase et du CERT-FR, montre où se joue la sécurité réelle.

Le détail le plus parlant est le 8 août : France VAE tombe deux jours après la publication du correctif. La faille Metabase n’a pas frappé des victimes sans défense face à une menace inconnue ; elle a frappé des serveurs pour lesquels la réparation existait déjà.

Qui a été touché dans l’État

Le point de situation REACTIV recense neuf instances Metabase compromises au sein des ministères, dans un document qui compte 99 violations de données portées à la connaissance de l’ANSSI depuis le 1er août 2026. Trois cas liés à Metabase sont détaillés dans les services du Premier ministre et au ministère du Travail :

• Le laboratoire d’innovation de l’ANSSI : 118 comptes compromis, dont une trentaine appartenant à des utilisateurs extérieurs à l’agence. Données concernées : statistiques d’usage, identifiants, adresses électroniques et empreintes de mots de passe. L’ANSSI indique avoir mis à jour ses instances, renouvelé les mots de passe et désactivé les comptes inactifs depuis plus de trois mois.
• La Dinum : deux instances, liées à ProConnect et à Nuage-Public. Sont sorties des informations administratives sur des organismes publics, des métadonnées de contributions à des projets libres et des historiques de connexion anonymisés.
• France VAE : accès privilégié obtenu et exfiltration de l’ensemble des données d’utilisateurs.

Le même document attribue aussi à Metabase, de façon établie ou probable, d’autres incidents : l’application Qualicharge (102 000 sessions de recharge de véhicules électriques et une centaine de comptes techniques), la plateforme Zéro Logement Vacant, dont le point d’entrée « serait » une instance Metabase, et Docurba, où les premiers éléments permettent de l’envisager.

Capture de la page 8 du point de situation REACTIV, septembre 2026 (CERTFR-2026-CTI-006, PDF du CERT-FR), le 06/10/2026.

Il faut lire ces chiffres sans caricature. Des empreintes de mots de passe ne sont pas des mots de passe en clair, et le CERT-FR précise que les données exfiltrées de la Dinum sont déjà publiques. Mais un mot de passe faible se retrouve à partir de son empreinte, et une adresse professionnelle d’agent de l’ANSSI a de la valeur pour un hameçonnage ciblé. Si vous aviez un compte sur l’un de ces services, changez ce mot de passe partout où vous l’aviez réutilisé.

Qui contrôle un logiciel libre auto-hébergé ? La leçon de la faille Metabase

À GadGeek, nous défendons souvent l’auto-hébergement comme un moyen de reprendre la main. Cet épisode oblige à préciser ce que « reprendre la main » veut dire, en séparant les trois dimensions de la souveraineté des données.

Localisation des données. Une instance Metabase installée sur un serveur de l’État garde les données en France. L’offre Metabase Cloud, elle, est hébergée dans l’une de cinq régions, dont Francfort pour l’Europe.

Droit applicable à l’opérateur. L’éditeur, Metabase Inc., est une société de San Francisco, comme l’atteste sa déclaration à la SEC. Une instance cloud, même hébergée à Francfort, est opérée par une entreprise américaine, donc exposée au CLOUD Act. Une instance auto-hébergée n’a pas ce problème : l’éditeur n’y a aucun accès.

Maîtrise technologique. C’est là que le bât blesse. Pendant cette crise, l’éditeur a bloqué le point d’entrée de l’attaque sur l’ensemble de ses instances cloud, puis les a corrigées lui-même dès le 6 août, d’après son récit, qui chiffre à moins de 3 % la part de clients cloud compromis avant le correctif (source : Metabase, 27 août 2026). Les instances auto-hébergées, elles, ne pouvaient être corrigées que par leur administrateur. Neuf instances ministérielles ne l’ont pas été à temps.

La conclusion n’est pas qu’il faut tout confier à un éditeur américain. Elle est que l’auto-hébergement transfère la responsabilité du correctif : on gagne le contrôle juridique et la localisation, on perd le filet de sécurité de l’éditeur. Avoir le code source sous licence AGPL ne protège de rien si personne ne surveille les avis de sécurité. La souveraineté, ici, ne se mesurait pas à l’emplacement du serveur mais au délai entre la publication d’un correctif et son application.

Pour reprendre réellement la main, trois habitudes comptent plus que le choix de l’outil :

1. Ne pas exposer un outil interne sur Internet. Un tableau de bord n’a pas besoin d’être joignable par tous. Le placer derrière un VPN ou un proxy d’authentification aurait rendu l’appel à reset_password impossible depuis l’extérieur. Notre guide PiVPN montre le principe à petite échelle.
2. Tenir un inventaire. C’est la première demande de l’ANSSI aux ministères : savoir où tournent ses instances. On ne corrige pas un serveur oublié.
3. S’abonner aux alertes. Le flux du CERT-FR et les avis GitHub de chaque logiciel exposé suffisent à être prévenu le jour même.

Un cloud souverain géré peut aussi être un compromis : un opérateur européen qui applique les correctifs à votre place, sous droit européen. À condition de vérifier contractuellement ses délais de mise à jour.

Que faire si vous administrez une instance Metabase

Les recommandations de Metabase et du CERT-FR convergent. Classées par urgence :

Quelle version installer

Le premier correctif du 6 août correspond aux versions 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 et 0.63.5. Le CERT-FR recommande des versions plus récentes, qui corrigent aussi les autres vulnérabilités de son avis du 24 août : 0.58.28, 0.59.25, 0.60.21, 0.61.15, 0.62.13 et 0.63.10 au minimum ; l’avis écrit « x.58.28 », le préfixe couvrant l’édition libre (0.) et les versions 1. de l’offre cloud et commerciale, que Metabase déclare touchées à partir de la 1.58. Visez ces dernières.

Capture de l’alerte CERTFR-2026-ALE-010 (cert.ssi.gouv.fr), le 06/10/2026.

Repérer une intrusion et nettoyer

Le CERT-FR donne une signature simple à chercher dans les journaux applicatifs : une requête POST vers /api/session/reset_password qui renvoie une erreur 400, suivie d’une requête GET vers /api/user/current qui renvoie 200. Si vous trouvez cette séquence, ou si l’instance était exposée avant la mise à jour :

1. révoquer toutes les sessions actives, en vidant la table core_session ;
2. supprimer les clés d’API que vous ne reconnaissez pas ;
3. vérifier la liste et les droits des comptes administrateurs ;
4. changer les identifiants de toutes les bases de données connectées, côté base et non seulement dans Metabase ;
5. relire les journaux d’accès de ces bases pour repérer des extractions.

Le quatrième point est celui qu’on oublie. Changer le mot de passe administrateur de Metabase ne sert à rien si l’attaquant a copié les identifiants de votre base de production.

Questions fréquentes

Dernière vérification : 06/10/2026