Faille critique Metabase : ce que doivent faire les TPE

Si votre entreprise auto-héberge Metabase et que l’interface est accessible depuis Internet, faites vérifier sa version et ses journaux sans attendre. La vulnérabilité CVE-2026-72898, notée 10/10, permet à un attaquant distant non authentifié d’injecter du SQL dans la base applicative de Metabase et d’obtenir des droits administrateur.[1][2]

Le CERT-FR indique avoir connaissance de nombreuses compromissions d’instances vulnérables.[1] Il ne s’agit donc pas d’une faille seulement théorique. Une mise à jour est indispensable, mais une instance qui a été exposée doit aussi faire l’objet de vérifications et de mesures de remédiation.

Metabase : qui doit se sentir concerné ?

Metabase est un outil de business intelligence qui produit des tableaux de bord à partir de bases de données commerciales, financières ou opérationnelles. Deux situations doivent être distinguées :

• Metabase Cloud : l’éditeur indique avoir bloqué l’attaque puis corrigé ses instances cloud. Les clients Metabase Cloud ont été mis à jour par l’éditeur.[3]
• Metabase auto-hébergé : l’entreprise ou son prestataire reste responsable de la mise à jour et de l’analyse de l’instance. L’urgence est plus forte si l’application, ou son point d’entrée de réinitialisation de mot de passe, était accessible publiquement.[1][3]

L’éditeur précise que cette CVE concerne les branches x.58 à x.63. Une installation antérieure à la branche 58 n’est pas affectée par cette vulnérabilité précise selon Metabase, mais elle peut être ancienne ou exposée à d’autres failles : ce constat ne vaut pas certificat de sécurité.[2][3]

Pourquoi cette faille est critique

L’attaque passe par un point d’entrée accessible sans authentification. Elle peut permettre de créer une session valide avec des droits administrateur. À partir de là, l’attaquant peut notamment modifier la configuration, récupérer des identifiants stockés pour les bases connectées, lire les données auxquelles Metabase a accès et les exporter.[2][3]

Le 27 août, Metabase a indiqué que moins de 3 % de ses clients cloud avaient été compromis avant le correctif. L’éditeur mentionne aussi des utilisateurs open source et des clients auto-hébergés disposant d’instances publiques, sans publier de nombre global.[4] Ce chiffre ne permet donc pas d’estimer la proportion de TPE françaises touchées.

Quelles versions installer ?

Les premiers correctifs de CVE-2026-72898 ont été publiés le 6 août. Depuis, le CERT-FR a relevé ses seuils minimaux pour tenir compte des correctifs Metabase publiés ensuite. Au 14 septembre 2026, son alerte demande de ne pas rester sous les versions suivantes :[1][2]

Le préfixe est généralement 0 pour l’édition open source et 1 pour l’édition Enterprise : par exemple, 0.63.10 et 1.63.10 appartiennent à la branche x.63. Ne vous arrêtez pas au premier correctif cité dans l’avis CVE : installez la dernière version corrective disponible de votre branche, après sauvegarde de la base applicative et lecture de la procédure de mise à niveau de Metabase.[1][2]

Si vous ne pouvez pas mettre à jour immédiatement, Metabase recommande de bloquer temporairement l’accès public à /api/session/reset_password. Cette mesure réduit l’exposition, mais ne remplace ni le correctif ni la recherche d’une compromission antérieure.[1][2]

Quels signes rechercher dans les journaux ?

Le CERT-FR décrit la succession suivante dans les journaux applicatifs et Metabase :[1]

1. POST /api/session/reset_password avec un statut HTTP 400 ;
2. puis GET /api/user/current avec un statut HTTP 200.

Le retour d’incident publié ensuite par Metabase écrit le premier chemin sous la forme /api/session/password-reset.[4] Puisque les deux graphies apparaissent dans les sources officielles, la recherche dans les journaux doit couvrir les deux, avec leurs variantes de chemin éventuelles selon la version et le frontal web.

Cette séquence est un indicateur à investiguer, pas à elle seule une preuve suffisante pour déclarer l’ensemble du système sain ou compromis. L’absence de cette seule trace ne permet pas non plus d’exclure une intrusion : les journaux peuvent être incomplets, avoir expiré ou avoir été altérés.

La marche à suivre pour une TPE

1. Identifier l’instance et son exposition

Demandez à la personne qui administre vos outils :

• la version exacte et l’édition de Metabase ;
• le mode d’hébergement : Metabase Cloud ou auto-hébergé ;
• si l’instance ou le chemin de réinitialisation était accessible depuis Internet ;
• depuis quand les journaux du reverse proxy, de l’application et des bases sont conservés.

Ne déduisez pas la version à partir d’un simple nom d’image Docker ou d’un document ancien : relevez-la sur l’instance réellement exécutée.

2. Préserver les éléments utiles avant les opérations destructives

Avant de purger des sessions, supprimer une clé ou réinstaller un composant, conservez les journaux disponibles et faites réaliser une sauvegarde cohérente de la base applicative. Si des signes suspects existent, limitez l’exposition et faites qualifier l’incident par une personne compétente. Cette précaution évite d’effacer les seuls éléments permettant de comprendre ce qui s’est passé.

3. Mettre à jour vers une version sûre de la branche

Suivez la procédure officielle de mise à niveau et vérifiez le bon fonctionnement après redémarrage : connexion, tableaux de bord, tâches planifiées et accès aux sources de données. Le CERT-FR recommande d’appliquer les correctifs dans les plus brefs délais.[1]

4. Si le point d’entrée était public, traiter le risque de compromission

Après la mise à jour, Metabase préconise :[1][2]

• de révoquer toutes les sessions actives en supprimant les lignes de la table core_session de la base applicative ;
• d’examiner les clés API et de supprimer celles qui ne sont pas reconnues ;
• de contrôler les comptes administrateur et leurs modifications ;
• de renouveler les identifiants des bases de données connectées ;
• d’examiner les journaux des entrepôts de données ;
• d’examiner l’historique des activités et des requêtes dans Metabase.

La suppression des sessions et la rotation des accès doivent être préparées : elles peuvent interrompre les utilisateurs ou les connexions aux bases. Ne copiez pas une commande trouvée sur Internet directement sur la base de production. Faites exécuter ces opérations par l’administrateur, après sauvegarde, en suivant les instructions de l’éditeur.

5. Escalader si les traces sont suspectes

En cas de compromission confirmée ou fortement suspectée, le CERT-FR demande de signaler l’événement, de mettre en copie l’éventuel CSIRT métier et de suivre ses fiches réflexes de qualification et d’endiguement.[1] Une analyse doit aussi déterminer quelles données et quels identifiants étaient accessibles depuis Metabase : corriger l’application ne suffit pas à invalider ce qu’un attaquant aurait déjà récupéré.

La question à poser aujourd’hui

Vous n’avez pas besoin de maîtriser l’injection SQL pour lancer la bonne vérification. Posez cette question à votre prestataire ou à votre équipe informatique :

Avons-nous une instance Metabase auto-hébergée dans une branche x.58 à x.63, était-elle exposée publiquement, vers quelle version a-t-elle été mise à jour et avons-nous contrôlé les journaux et les accès aux bases connectées ?

Si personne ne peut répondre clairement, l’inventaire, la veille et le suivi des correctifs doivent être cadrés. Ils peuvent l’être dans une démarche d’infogérance.

Pour faire vérifier une instance ou organiser la remédiation en Drôme et en Ardèche, vous pouvez contacter Hugo Informatique. L’objectif est d’établir les faits, de réduire l’exposition et de remettre les accès en sécurité sans confondre mise à jour et preuve d’absence de compromission.

Sources

[1] https://www.cert.ssi.gouv.fr/alerte/CERTFR-2026-ALE-010/ — CERT-FR, « Vulnérabilité dans Metabase », 10 septembre 2026.

[2] https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf — Metabase, bulletin de sécurité de CVE-2026-72898, 6 août 2026.

[3] https://www.metabase.com/blog/security-update-6-aug-2026 — Metabase, « Security update available for Metabase », 6 août 2026.

[4] https://www.metabase.com/blog/vulnerability-what-happened — Metabase, retour d’incident, 27 août 2026.