La deadline CISA du 14 août est passée — les 3 raisons pour lesquelles votre Metabase est probablement encore exposé

1. Les faits, sans emballage

Le 11 août 2026, l'agence américaine de cybersécurité a inscrit CVE-2026-72898 à son catalogue des vulnérabilités connues comme activement exploitées. Le produit concerné est Metabase, l'outil d'informatique décisionnelle en source ouverte que beaucoup d'équipes utilisent pour construire des tableaux de bord sur leurs bases de production.

La description officielle est courte et méchante : Metabase contient une vulnérabilité d'injection SQL permettant à un attaquant distant non authentifié d'injecter du SQL arbitraire dans la base de l'application, ce qui peut lui donner un accès administrateur à l'instance. À partir de là, il peut modifier la configuration de l'application, dérober les identifiants stockés des bases de données connectées, lire toutes les données accessibles via ces connexions, et les exporter.

L'échéance de correction fixée par la CISA était le 14 août 2026 — trois jours après l'inscription. Ce délai très court est réservé aux situations jugées sérieuses. Le champ « utilisation connue dans une campagne de rançongiciel » est renseigné comme inconnu, ce qui ne signifie pas « non » mais « pas documenté à ce stade ».

Précision utile : cette échéance contraint les agences fédérales américaines, pas les entreprises françaises. Ce qui vous concerne, ce n'est pas la date — c'est le fait que l'inscription au catalogue atteste d'une exploitation réelle, pas d'un risque théorique.

Une remarque de contexte, parce qu'elle éclaire la période : le même jour, la CISA a inscrit deux autres vulnérabilités, dont CVE-2026-68820, un défaut de type utilisation après libération dans le pilote Windows pour WinSock permettant une élévation de privilèges locale, avec une échéance au 25 août. La combinaison est classique dans un scénario d'attaque : une porte d'entrée applicative, puis une élévation de privilèges sur le poste atteint.

2. Raison 1 — personne ne sait que Metabase tourne

C'est la raison la plus fréquente, et la plus embarrassante à admettre. Metabase est typiquement installé par une équipe data, un analyste ou un développeur qui voulait « juste un tableau de bord rapide ». L'installation prend quelques minutes avec un conteneur. Elle n'apparaît dans aucun inventaire, aucun contrat de maintenance, aucun tableau de suivi des correctifs.

Deux ans plus tard, l'analyste est parti, le tableau de bord est utilisé chaque lundi par la direction commerciale, et l'instance tourne toujours dans sa version d'origine. Quand une alerte comme celle-ci sort, la question « sommes-nous concernés ? » n'a personne pour y répondre.

La vérification concrète, ce matin : cherchez les conteneurs et services en écoute portant le nom du produit sur l'ensemble de vos serveurs, y compris les machines de développement et les environnements de recette. Interrogez aussi vos équipes data directement — la question « est-ce que quelqu'un a installé un outil de tableaux de bord ? » produit souvent une réponse plus rapide qu'un scan.

C'est exactement le type d'angle mort que nous cartographions lors d'un audit de périmètre : l'inventaire réel diverge presque toujours de l'inventaire déclaré, et c'est dans cet écart que vivent les incidents.

3. Raison 2 — « interne » ne veut pas dire inaccessible

La deuxième réaction classique est : « notre Metabase n'est pas exposé sur Internet, donc nous ne sommes pas concernés ». C'est souvent vrai, et c'est parfois faux d'une manière que personne n'avait anticipée.

Les cas que nous rencontrons le plus souvent : une règle de pare-feu ouverte temporairement pour un prestataire et jamais refermée ; une redirection de port mise en place pour un accès depuis l'extérieur pendant une période de télétravail ; un hébergement sur une machine dont l'adresse publique a été réattribuée ; ou tout simplement une instance derrière un VPN auquel presque tout le monde a accès.

Mais même en supposant l'isolation parfaite, le raisonnement a une faille. Une vulnérabilité exploitable sans authentification est exploitable par n'importe quoi qui parle au serveur — y compris un poste de travail interne compromis. Or le phishing fournit ce point de départ tous les jours. L'isolation réseau réduit la surface d'attaque ; elle ne transforme pas une faille critique en non-problème.

La vérification : ne vous fiez pas au schéma réseau, testez. Depuis l'extérieur, tentez d'atteindre l'instance. Depuis un poste utilisateur standard, faites de même. L'écart entre l'architecture supposée et l'architecture réelle est la donnée qui compte.

4. Raison 3 — le correctif ne fait pas tourner les identifiants

Voici le point qui justifie à lui seul cet article, et celui que la majorité des communications sur cette faille passe sous silence.

Relisez la description de l'impact : l'attaquant peut dérober les identifiants stockés des bases de données connectées. Metabase, par construction, conserve les identifiants de connexion à vos bases de production pour pouvoir les interroger. C'est son travail.

Ces identifiants ne changent pas quand vous appliquez une mise à jour. Si votre instance a été compromise avant que vous ne corrigiez — et l'inscription au catalogue KEV signifie que l'exploitation était active —, l'attaquant dispose désormais d'identifiants parfaitement valides vers vos bases de production. Il n'a plus aucun besoin de repasser par Metabase. Vous avez fermé la porte d'entrée pendant qu'il était déjà à l'intérieur avec un jeu de clés.

C'est la différence entre corriger une vulnérabilité et traiter un incident. La mise à jour est nécessaire et ne suffit pas. La séquence complète est : corriger, puis faire tourner tous les identifiants de bases enregistrés dans l'instance, puis vérifier les journaux côté bases de données pour les connexions anormales.

5. Le plan des 48 prochaines heures

Si vous utilisez Metabase, voici l'ordre dans lequel nous procédons. L'ordre compte : chaque étape est conçue pour ne pas détruire les traces dont la suivante a besoin.

• Heure 0 — Localiser. Identifiez toutes les instances, y compris en recette et en développement. Une instance de test connectée à une copie de production est un vrai risque.
• Heure 1 — Réduire l'exposition. Si une instance est joignable depuis Internet, coupez cet accès immédiatement. C'est réversible et cela arrête l'hémorragie pendant que vous réfléchissez.
• Heure 2 — Collecter avant de corriger. Sauvegardez les journaux applicatifs et la liste des comptes administrateurs avant la mise à jour. Une mise à jour peut faire tourner les journaux et effacer ce que vous chercherez ensuite.
• Heure 4 — Corriger. Appliquez la version corrigée publiée par l'éditeur.
• Heure 6 — Faire tourner les identifiants. Tous les comptes de base de données enregistrés dans l'instance. Sans exception, y compris ceux jugés « en lecture seule » — un compte en lecture seule sur une base clients est exactement ce qu'un attaquant cherche.
• Heure 12 — Chercher les traces. Côté bases, examinez les connexions provenant du serveur Metabase à des heures inhabituelles ou portant sur des tables que les tableaux de bord n'interrogent jamais.
• Jour 2 — Décider de la notification. Si des données personnelles ont pu être exfiltrées, le délai de 72 heures pour notifier la CNIL court à partir de la prise de connaissance de la violation. Cette décision se prend avec un regard juridique, pas seulement technique.

Sur la partie exposition et durcissement, notre équipe applique la même logique aux briques applicatives internes qu'aux services publics. C'est un raisonnement que nos confrères de D-Open tiennent également côté développement : un outil interne connecté à la production mérite le niveau de rigueur d'un service exposé, parce que sa valeur pour un attaquant est identique. Les équipes de Plug-Tech font le même constat sur les connecteurs de données alimentant les projets d'intelligence artificielle.

6. Questions fréquentes

La deadline CISA du 14 août s'applique-t-elle aux entreprises françaises ?

Juridiquement, non. Le catalogue KEV et ses échéances s'imposent aux agences fédérales civiles américaines, pas aux entreprises françaises. En pratique, l'inscription au catalogue signifie que la CISA dispose de preuves d'exploitation active — c'est-à-dire que la faille n'est plus théorique. C'est cette information qui compte pour vous, bien plus que la date. Une vulnérabilité inscrite au KEV mérite d'être traitée en priorité, quel que soit le pays où se trouve le serveur.

Notre Metabase n'est pas exposé sur Internet, sommes-nous concernés ?

Probablement moins, mais la conclusion « pas exposé donc pas concerné » est celle qui produit le plus de mauvaises surprises. Deux vérifications s'imposent. D'abord, contrôlez l'exposition réelle plutôt que l'exposition supposée : une règle de pare-feu temporaire jamais retirée, un accès via un VPN largement ouvert ou une redirection de port oubliée suffisent. Ensuite, rappelez-vous qu'une injection SQL exploitable par un attaquant non authentifié devient exploitable par n'importe quel poste compromis du réseau interne — le phishing fournit ce point de départ tous les jours.

Une fois Metabase mis à jour, l'incident est-il clos ?

Non, et c'est le point le plus important de cet article. La description de la vulnérabilité indique qu'un attaquant peut voler les identifiants stockés des bases de données connectées. Ces identifiants ne changent pas quand vous appliquez un correctif. Si l'instance a été compromise avant la mise à jour, l'attaquant conserve des accès parfaitement valides aux bases de production, sans repasser par Metabase. La correction ferme la porte d'entrée ; seule la rotation des identifiants annule les clés déjà copiées.

Comment savoir si notre instance a déjà été compromise ?

Cherchez trois choses dans cet ordre. Les comptes administrateurs Metabase créés ou modifiés récemment, en particulier hors des horaires habituels. Les modifications de configuration de l'application, notamment l'ajout de sources de données ou de destinations d'export. Et surtout, côté bases de données connectées, les connexions provenant de l'adresse du serveur Metabase à des heures inhabituelles ou portant sur des tables que les tableaux de bord n'interrogent jamais. Si la journalisation ne permet pas de répondre, considérez la compromission comme possible et faites la rotation des identifiants malgré tout.

Ce qu'il faut retenir

CVE-2026-72898 est une vulnérabilité sérieuse : injection SQL, sans authentification, sur un outil qui détient par conception les clés de vos bases de production. Son inscription au catalogue KEV le 11 août avec une échéance à trois jours dit l'urgence mieux que n'importe quel score.

Mais l'enjeu réel pour une PME française n'est pas de tenir une échéance américaine. Il est de répondre à trois questions : savons-nous où tournent nos instances, savons-nous qui peut réellement les joindre, et avons-nous fait tourner les identifiants qu'elles détenaient ? Les deux premières relèvent de l'inventaire. La troisième est celle qu'on oublie, et c'est celle qui laisse une porte ouverte après la fermeture officielle de l'incident.