CVE-2026-72898 : quand une SQLi Metabase ouvre toute la chaîne de données

Le 6 août 2026, Metabase a publié une alerte critique concernant une injection SQL accessible sans authentification. La vulnérabilité, désormais suivie sous l’identifiant CVE-2026-72898, permet d’atteindre la base applicative de Metabase, d’obtenir un accès administrateur à l’instance puis, potentiellement, d’accéder aux identifiants des bases de données connectées. Metabase a confirmé une exploitation active. Le 11 août, la CISA a ajouté la faille à son catalogue Known Exploited Vulnerabilities avec une échéance de remédiation fixée au 14 août pour les organismes concernés par ses directives.

Ce dossier mérite davantage qu’une fiche CVE. Le point important n’est pas seulement qu’une application web contient une SQLi. C’est la position particulière de la plateforme compromise. Un outil de Business Intelligence se trouve au croisement des identités, des secrets techniques et des jeux de données les plus précieux de l’entreprise. Une intrusion dans Metabase ne s’arrête donc pas nécessairement à Metabase.

L’objectif de cet article est d’expliquer la chaîne de confiance qui rend cette faille si grave, de séparer les faits confirmés des hypothèses, et de proposer une méthode de réponse utilisable par une équipe sécurité. Aucun code d’exploitation ni charge SQL n’est présenté.

En bref

• CVE-2026-72898 est une injection SQL distante et non authentifiée dans un endpoint de réinitialisation de mot de passe.
• Le score CVSS v3.1 publié est de 10,0 : réseau, faible complexité, aucun privilège, aucune interaction utilisateur et impacts élevés sur confidentialité, intégrité et disponibilité.
• L’attaquant peut compromettre la base applicative, devenir administrateur Metabase, modifier la configuration et tenter d’accéder aux bases connectées.
• Metabase a confirmé une exploitation dans la nature. Framework et Tally ont publiquement décrit des vols de données liés à des compromissions de leur environnement analytique.
• La mise à jour est indispensable, mais insuffisante si l’endpoint était exposé : il faut aussi révoquer les sessions, auditer les comptes et clés, puis faire tourner les identifiants des bases connectées.

Pourquoi cette vulnérabilité dépasse le cadre d’une application web

#

Metabase sert d’interface entre des utilisateurs et plusieurs systèmes de données. Pour fonctionner, l’application maintient sa propre base, appelée ici base applicative, où elle enregistre notamment ses utilisateurs, ses sessions, ses tableaux de bord, sa configuration et les informations nécessaires aux connexions de données. Elle dialogue ensuite avec des bases métiers, des entrepôts analytiques ou des répliques de lecture.

Cette distinction est essentielle : CVE-2026-72898 vise d’abord la base applicative de Metabase. L’accès aux données métiers arrive dans un second temps, par l’intermédiaire des privilèges et des secrets que l’instance possède déjà.

Dans une architecture saine, la plateforme de BI devrait disposer de droits limités, idéalement en lecture seule, sur des vues ou des répliques prévues pour l’analyse. Dans une architecture moins mature, elle utilise parfois des comptes trop puissants, partagés entre environnements, capables de lire des tables sensibles ou même de modifier des données. Le même défaut applicatif produit alors des conséquences très différentes.

On peut résumer le risque avec une relation simple :

Risque réel =
  exploitabilité
  × exposition
  × privilèges détenus
  × valeur des données

Le CVSS mesure très bien la première partie. Il ne mesure pas la qualité de la segmentation, le périmètre des comptes de service ni la sensibilité des données que chaque organisation a connectées à Metabase. C’est pourquoi l’inventaire de l’architecture doit accompagner la lecture du score.

Ce que l’avis de sécurité confirme

#

L’avis GitHub de Metabase fournit les éléments confirmés suivants :

• l’attaque est distante et ne nécessite pas de compte ;
• l’injection SQL touche la base applicative de Metabase ;
• l’exploitation peut donner un accès administrateur à l’instance ;
• cet accès peut permettre de modifier la configuration, de voler des identifiants de bases connectées et de lire ou exporter les données accessibles avec ces connexions ;
• l’exploitation active a été confirmée par l’éditeur ;
• le contournement temporaire consiste à bloquer l’endpoint /api/session/reset_password ;
• le correctif existe pour chaque branche maintenue concernée.

Le vecteur CVSS publié est :

CVSS:3.1/
AV:N/AC:L/PR:N/UI:N/
S:C/C:H/I:H/A:H
Score = 10.0

Il indique une attaque réseau, de faible complexité, sans privilège préalable ni interaction d’une victime. Le changement de périmètre, noté S:C, reflète justement la capacité du composant vulnérable à affecter d’autres ressources.

Versions affectées et correctifs

#

Le tableau reprend littéralement les bornes publiées par l’éditeur, même si l’écart apparent entre certaines bornes affectées et corrigées peut surprendre. En pratique, il ne faut pas chercher à choisir le plus petit numéro possible à partir du tableau : il faut installer la version corrigée explicitement annoncée pour sa branche, ou une version ultérieure supportée.

Chaîne d’exploitation : du point d’entrée à la donnée

#

Les détails publics permettent de décrire la logique générale, pas la requête SQL exacte ni l’implémentation interne du correctif. La séquence suivante reste donc volontairement conceptuelle.

Étape 1 : atteindre un endpoint sans authentification

#

L’endpoint de réinitialisation de mot de passe doit être joignable avant connexion pour remplir sa fonction. C’est une surface délicate : elle traite des identifiants ou jetons liés à l’identité sans bénéficier de la barrière d’une session utilisateur. Une validation ou une construction de requête incorrecte à cet endroit transforme une fonction publique en passerelle vers la base applicative.

La leçon ne consiste pas à interdire les fonctions publiques. Elle consiste à les traiter comme une frontière de confiance : requêtes paramétrées, validation structurelle, limitation de débit, journalisation et tests négatifs systématiques.

Étape 2 : manipuler la base applicative

#

Une injection SQL signifie que des données contrôlées par le client influencent la structure d’une requête au lieu de rester des valeurs. L’utilisation de paramètres liés sépare normalement le code SQL des données :

Approche vulnérable, conceptuelle :
  SQL = "SELECT ... WHERE token = '"
        + valeur_client + "'"

Approche attendue :
  SQL = "SELECT ... WHERE token = ?"
  paramètres = [valeur_client]

Ce schéma pédagogique ne décrit pas le code de Metabase. Il explique le principe général de CWE-89, catégorie attribuée à l’entrée CISA. Sans publication technique du diff causal, aller plus loin reviendrait à spéculer.

Étape 3 : passer de la base applicative au rôle administrateur

#

La base applicative porte l’état de sécurité de l’application : comptes, rôles, sessions et réglages. Une écriture ou une lecture arbitraire peut donc devenir un contournement du mécanisme d’authentification. L’attaquant n’a pas besoin de casser le mot de passe d’un administrateur s’il peut modifier directement l’état sur lequel l’application se fonde pour décider qui est administrateur.

Ce changement de perspective est fondamental. Les contrôles de connexion visibles dans l’interface ne protègent plus lorsque la source de vérité située derrière eux est manipulée.

Étape 4 : utiliser les connexions légitimes de Metabase

#

Une fois administrateur, l’attaquant peut tenter d’utiliser les fonctionnalités normales de l’outil : consulter des sources, lancer des requêtes autorisées, exporter des résultats ou récupérer la configuration de connexion. L’activité malveillante peut alors ressembler à de l’administration ou de l’analyse ordinaire.

La plateforme agit comme un confused deputy : elle possède légitimement des privilèges sur d’autres systèmes, mais les exerce au bénéfice d’un acteur qui a pris le contrôle de son contexte administratif.

Chronologie : une fenêtre de réaction extrêmement courte

#

Selon les notifications rapportées par BleepingComputer, Framework et Tally ont identifié des accès datés du 3 août, avant la publication de l’avis le 6 août. Framework a signalé le vol de données de contact et de commande. Tally a indiqué que des adresses e-mail et des hachages de mots de passe avaient été atteints, tandis que les formulaires et leurs réponses restaient séparés.

Ces cas illustrent deux principes :

1. un correctif publié le jeudi ne répare pas une intrusion survenue le lundi ;
2. la séparation des données limite réellement l’impact, comme le montre le cloisonnement annoncé par Tally.

Il faut également éviter les associations hâtives. Un incident LexisNexis évoqué dans les premiers articles concernait un service nommé « Metabase API », mais une clarification ultérieure a indiqué qu’il ne s’agissait pas du service Metabase Cloud. Il n’est donc pas retenu ici comme victime confirmée de CVE-2026-72898.

Détection : chercher une chaîne, pas un indicateur isolé

#

L’indicateur réseau le plus précis publiquement rapporté est une requête POST vers /api/session/reset_password retournant un code 400, suivie d’une requête GET réussie vers /api/user/current. Une telle séquence est beaucoup plus intéressante que le seul code 400, courant sur un endpoint recevant des entrées invalides.

Logique de corrélation générique

#

Fenêtre : 5 minutes

Événement A
  méthode = POST
  chemin = /api/session/reset_password
  statut = 400

SUIVI PAR événement B
  même IP source ou même identifiant de connexion
  méthode = GET
  chemin = /api/user/current
  statut = 200

Priorité : critique
  si aucune session valide
  n'existait avant A

Cette règle doit être adaptée au format des logs et testée sur l’historique. Un reverse proxy peut modifier les chemins, masquer l’adresse du client ou ne pas journaliser le corps. Les environnements derrière un CDN doivent utiliser l’adresse client transmise par un en-tête de confiance, sans accepter cet en-tête directement depuis Internet.

Sources de preuve à préserver

#

L’absence d’un événement dans Metabase ne prouve pas l’absence d’intrusion. Un administrateur compromis peut agir via des fonctions légitimes, et certains journaux peuvent être incomplets. Il faut reconstruire l’activité en croisant le plan applicatif et le plan de données.

Réponse immédiate : contenir, corriger, assainir

#

La mise à jour arrête le vecteur connu. Elle ne révoque ni une session volée, ni une clé créée, ni un secret déjà copié. L’ordre des opérations doit limiter l’exposition tout en préservant les preuves.

1. Identifier le périmètre

#

• Inventorier toutes les instances Metabase, y compris les environnements de test et les anciennes URL.
• Relever version, mode d’hébergement, exposition Internet et propriétaire métier.
• Lister chaque base connectée, le compte utilisé, ses privilèges et les données accessibles.
• Déterminer si /api/session/reset_password était publiquement joignable pendant la période à risque.

2. Conserver les éléments nécessaires à l’enquête

#

Avant toute purge, exporter les logs du reverse proxy, de Metabase, de la base applicative et des bases connectées. Capturer les métadonnées des comptes, clés API et sessions. Dans un incident avéré, une copie cohérente de la base applicative peut être nécessaire selon les procédures forensiques internes.

3. Réduire l’exposition

#

Si la mise à jour ne peut pas être appliquée immédiatement, bloquer temporairement l’endpoint vulnérable au niveau du reverse proxy ou du WAF. Exemple conceptuel pour Nginx :

location = /api/session/reset_password {
    return 403;
}

Ce contournement dégrade la fonction de réinitialisation de mot de passe et ne remplace pas le correctif. Il ne faut pas le retirer tant que la version corrigée n’est pas déployée et vérifiée.

4. Installer une version corrigée

#

Utiliser l’image, le paquet ou le JAR correspondant à la branche supportée. Vérifier l’empreinte ou la provenance du binaire, redémarrer proprement, puis confirmer la version réellement en exécution. Une mise à jour déclarée dans un fichier de déploiement mais non appliquée sur les pods actifs ne constitue pas une remédiation.

5. Invalider l’état potentiellement compromis

#

Metabase demande de révoquer toutes les sessions actives, notamment en supprimant les lignes de core_session dans la base applicative selon sa procédure. Il recommande aussi :

• de supprimer les clés API inconnues ;
• de vérifier les comptes administrateurs et leurs modifications ;
• de tourner les identifiants de toutes les bases connectées ;
• d’examiner les journaux des entrepôts de données ;
• de rechercher les requêtes et activités Metabase non autorisées.

La rotation doit se faire côté système de données, pas seulement dans l’interface Metabase. Un ancien mot de passe reste valable tant que la base qui l’accepte ne l’a pas révoqué.

6. Évaluer l’obligation de notification

#

Si des données personnelles ou réglementées ont pu être consultées, l’équipe juridique et le délégué à la protection des données doivent être associés rapidement. L’existence d’un accès administrateur ne prouve pas à elle seule l’exfiltration, mais l’absence de logs détaillés peut empêcher de l’exclure.

Durcissement durable de la chaîne analytique

#

Moindre privilège des comptes de données

#

Metabase ne devrait pas se connecter avec un compte propriétaire de schéma ou administrateur de base. Créer un compte distinct par environnement et par source, limité aux vues nécessaires. Pour les tableaux de bord, un accès en lecture sur une réplique ou un schéma analytique réduit fortement le rayon d’explosion.

Segmentation réseau

#

L’interface peut être exposée aux employés sans rendre toutes les bases joignables depuis le même segment. Autoriser uniquement les flux nécessaires entre l’instance et les destinations précises. Les bases d’administration, de paiement ou d’identité ne doivent pas devenir accessibles par simple commodité analytique.

Gestion des secrets

#

• Un secret par connexion et par environnement.
• Rotation automatique lorsque la technologie le permet.
• Durée de vie courte pour les identifiants fédérés.
• Aucun secret partagé avec un pipeline ou une application métier.
• Surveillance des lectures de secrets et des échecs d’authentification après rotation.

Réduction de la surface Internet

#

Si le besoin ne justifie pas une exposition publique, placer Metabase derrière un accès privé, un proxy d’identité ou un VPN d’entreprise. L’authentification forte à l’entrée reste utile, mais elle ne corrige pas un endpoint pré-authentification vulnérable. Le filtrage réseau constitue une barrière supplémentaire, pas un substitut aux mises à jour.

Observabilité indépendante

#

Les journaux importants doivent être exportés en temps réel vers une plateforme que l’administrateur Metabase ne peut pas modifier. Conserver au minimum : authentifications, changements de rôles, création de clés, modifications de sources, requêtes, exports et volumes de résultats. Sur les entrepôts, l’identité technique Metabase doit être suffisamment distincte pour établir une ligne de base.

Une grille simple pour mesurer son exposition

#

Une seule colonne critique ne prouve pas une compromission. Plusieurs réponses critiques indiquent toutefois qu’une vulnérabilité applicative peut rapidement devenir un incident de données majeur.

Ce qu’il faut retenir

#

CVE-2026-72898 combine tous les facteurs d’une urgence réelle : accès réseau, aucune authentification, faible complexité, score 10, exploitation active et produit placé au coeur du système de données. L’ajout rapide au catalogue CISA KEV confirme que la priorité ne vient pas uniquement d’un calcul théorique.

Le correctif ferme l’entrée. La réponse complète doit aussi traiter l’état que l’attaquant a pu obtenir et les systèmes que Metabase pouvait atteindre. Révoquer les sessions, auditer les administrateurs, supprimer les clés inconnues, tourner les identifiants et analyser les requêtes des entrepôts font partie de la même remédiation.

Enfin, la leçon dépasse Metabase : tout outil qui agrège des accès à plusieurs sources devient un plan de contrôle. Sa sécurité doit être évaluée non seulement selon les données qu’il stocke directement, mais selon les privilèges qu’il peut exercer ailleurs.

Sources

#

• Metabase, avis de sécurité GitHub, « SQL injection using an unauthenticated endpoint leading to admin access », 6 août 2026
• CISA, Known Exploited Vulnerabilities Catalog, entrée CVE-2026-72898 ajoutée le 11 août 2026
• CISA, flux JSON du catalogue KEV
• NIST NVD, CVE-2026-72898
• BleepingComputer, « Metabase SQLi zero-day exploited in customer data-theft attacks », 7 août 2026
• Traficom, NCSC-FI, bulletin de vulnérabilité 2026-22, 11 août 2026