Une vulnérabilité de sévérité maximale activement exploitée

Metabase, l'un des outils open-source de business intelligence et de data visualisation les plus répandus (plus de 48 600 étoiles sur GitHub), a publié le 6 août 2026 un avis de sécurité critique confirmant l'exploitation active en wild d'une vulnérabilité zero-day d'injection SQL. La faille, référencée sous l'identifiant GHSA-vwf4-m7j8-wcjf sur GitHub, affiche un score CVSS de 10,0 — la note maximale — et n'a pas encore reçu d'identifiant CVE à ce jour.

Selon l'avis publié par Metabase, « Metabase Cloud a été attaqué par quelqu'un utilisant une vulnérabilité de sécurité inconnue ('0-day') dans les versions 1.58 et supérieures ». Les instances hébergées sur Metabase Cloud ont d'ores et déjà été mises à jour vers la dernière version corrigée.

Mécanisme de l'attaque : injection SQL sans authentification → accès administrateur

La vulnérabilité permet à un attaquant distant non authentifié d'injecter du SQL arbitraire dans la base de données applicative de Metabase (la Metabase application database, qui stocke la configuration de l'instance, les comptes utilisateurs, les sessions et — surtout — les identifiants des bases de données connectées).

Le vecteur d'attaque identifié exploite l'endpoint /api/session/reset_password. Une fois l'injection SQL réussie, l'attaquant peut :

  1. Obtenir un accès administrateur à l'instance Metabase ;
  2. Modifier la configuration de l'application ;
  3. Voler les identifiants stockés pour toutes les bases de données connectées à l'instance ;
  4. Lire toutes les données accessibles via ces connexions ;
  5. Exporter les données à loisir.

La chaîne d'indicateurs de compromission (IoC) publiée par Metabase est la suivante :

  • Un appel POST /api/session/reset_password retournant un code 400 ;
  • Suivi immédiatement d'un appel GET /api/user/current retournant un code 200.

« Si vous trouvez ce schéma dans vos logs applicatifs ou vos logs d'ingress du serveur Metabase, il est probable que votre instance ait été compromise », a prévenu Sameer Al-Sakran, PDG de Metabase.

Une seconde faille critique liée aux dashboards publics

Parallèlement à la faille principale, Metabase a publié le même jour un second avis de sécurité, GHSA-r8h2-qpfx-mx59 (CVSS 9,6, Critique), décrivant une injection SQL via un dashboard ou une carte partagés publiquement. Dans ce cas, un attaquant non authentifié n'ayant besoin que de l'UUID du lien public — qui fait partie de l'URL par conception — peut exploiter un paramètre de type field-filter (dimension) pour injecter du SQL dans la base applicative et obtenir le même niveau d'accès administrateur.

Le partage public étant activé par défaut dans Metabase, la simple publication d'un lien suffit à exposer l'instance. La solution de contournement temporaire consiste à désactiver le partage public ou à dépublier les liens exposant des paramètres field-filter.

Enfin, une troisième faille, GHSA-8hmm-hrhg-ppqp (CVSS 6,5, Modérée), permet à un utilisateur authentifié de bas niveau de lire l'intégralité de la base applicative — y compris les hashes de mots de passe bcrypt et, sur les instances sans MB_ENCRYPTION_SECRET_KEY (la configuration par défaut), les identifiants en clair de toutes les bases de données connectées.

Versions affectées et correctifs

Les trois vulnérabilités affectent les versions de Metabase à partir de x.58.0. Voici le tableau des versions corrigées :

Branche Versions affectées Version corrigée
x.58 >= x.58.0, < x.58.23 x.58.24
x.59 >= x.59.0, < x.59.20 x.59.21
x.60 >= x.60.0, < x.60.16 x.60.17
x.61 >= x.61.0, < x.61.10 x.61.11
x.62 >= x.62.0, < x.62.8 x.62.9
x.63 >= x.63.0, < x.63.3 x.63.5

Les utilisateurs en auto-hébergement sont invités à appliquer les correctifs immédiatement. Les images Docker et les fichiers JAR (éditions Open Source et Enterprise) sont disponibles sur la page des releases GitHub de Metabase.

« Wide blast radius » : pourquoi l'impact pourrait être vaste

Le titre de l'article de Dark Reading du 10 août souligne à juste titre le « wide blast radius » (rayon d'impact étendu) de cette vulnérabilité. Plusieurs facteurs expliquent cette préoccupation :

  • Popularité de l'outil : Metabase est utilisé par des milliers d'organisations, des startups aux grandes entreprises, pour visualiser et analyser leurs données métier. Sa simplicité de déploiement (un simple fichier JAR ou conteneur Docker) en fait un choix courant en auto-hébergement.
  • Multiplication des bases connectées : une instance Metabase typique est connectée à plusieurs bases de données (PostgreSQL, MySQL, Snowflake, BigQuery, etc.). Un compromis de l'instance signifie donc potentiellement un compromis de toutes les bases connectées, d'où un effet de cascade.
  • Identifiants en clair par défaut : sans configuration de MB_ENCRYPTION_SECRET_KEY (le cas par défaut), les identifiants des bases connectées sont stockés en clair dans la base applicative, prêts à être exfiltrés.
  • Absence de CVE : la vulnérabilité ne dispose pas encore d'identifiant CVE, ce qui peut ralentir son identification dans les processus de gestion des vulnérabilites automatisés des organisations. À noter que, contrairement à d'autres failles récentes (Progress Kemp LoadMaster, N-able N-central, JetBrains TeamCity), la faille Metabase n'apparaît pas encore dans le catalogue KEV de la CISA au 10 août 2026, probablement en raison de l'absence de CVE.

Victimes confirmées : Framework et Tally

L'article de BleepingComputer du 7 août, signé Mayank Parmar, a été le premier à identifier publiquement des victimes : le fabricant d'ordinateurs modulaires Framework et la plateforme de formulaires en ligne Tally.

Selon les informations rapportées par Engadget et citées par The Hacker News, Framework a alerté l'ensemble de ses clients que les données suivantes avaient été consultées lors de l'attaque :

  • Noms des clients
  • Adresses IP de connexion
  • Adresses postales
  • Numéros de téléphone
  • Adresses e-mail

Framework a toutefois précisé qu'aucune information de commande ou de paiement n'avait été compromise. L'entreprise a indiqué que la violation était le résultat de l'exploitation de la vulnérabilité Metabase.

Tally, pour sa part, est mentionné comme victime dans l'article de BleepingComputer, mais les détails précis sur l'étendue de la fuite de données côté Tally n'étaient pas publiquement disponibles au moment de la rédaction.

Mesures à prendre après la mise à jour

Pour les organisations dont l'endpoint /api/session/reset_password était publiquement accessible, Metabase recommande les mesures post-remédiation suivantes :

  1. Révoquer toutes les sessions actives en supprimant toutes les lignes de la table core_session dans la base applicative ;
  2. Examiner et supprimer les clés API non reconnues ;
  3. Vérifier les comptes administrateurs pour tout changement inattendu ;
  4. Rotater les identifiants de toutes les bases de données connectées ;
  5. Examiner les logs des entrepôts de données pour toute trace d'accès non autorisé ;
  6. Passer en revue l'historique d'activité et de requêtes Metabase pour toute activité suspecte.

Pour la faille liée aux dashboards publics (GHSA-r8h2-qpfx-mx59), les organisations doivent également examiner les cartes et dashboards publics utilisant des paramètres field-filter et, idéalement, désactiver le partage public si ce n'est pas nécessaire.

Un historique de failles critiques

Ce n'est pas la première fois que Metabase est confronté à une vulnérabilité de sévérité maximale. En juillet 2023, la société avait corrigé CVE-2023-38646 (CVSS 9,8), une faille d'exécution de code à distance pré-authentifiée qui avait également fait l'objet d'un avis urgent de mise à jour immédiate.

Plus récemment, le dépôt GitHub de Metabase a publié plusieurs autres avis critiques en 2026 :

  • Arbitrary File Read/Write via Unsafe H2 Built-in Functions (GHSA-cwxq-fmxq-jv8h, 12 juillet 2026) ;
  • Unsafe Deserialization of H2 Query Results (GHSA-w95f-x9v9-wv36, 30 juin 2026) ;
  • Arbitrary Code Execution via Database Connection Detail Bypass (GHSA-8wx2-rxp2-4x35, 30 juin 2026) ;
  • Remote Code Execution via Snowflake JDBC Driver Arbitrary File Write (GHSA-r6x2-rchx-q9g9, 28 mai 2026) ;
  • Arbitrary File Read via MySQL Connection Property Injection (GHSA-mfpj-crjq-xrcp, 28 mai 2026).

Cette série de vulnérabilités soulève des questions sur la surface d'attaque d'un outil qui, par conception, se connecte à de multiples sources de données et manipule des requêtes SQL — un profil qui en fait une cible de choix pour les attaquants cherchant à pivoter vers les données métier sensibles.

Recommandations pour les organisations francophones

Les organisations utilisant Metabase en auto-hébergement doivent agir sans délai :

  • Vérifier la version installée et appliquer le correctif correspondant à la branche utilisée ;
  • Si la mise à jour immédiate est impossible, bloquer l'endpoint /api/session/reset_password au niveau du pare-feu applicatif ou du reverse proxy, et désactiver le partage public des dashboards ;
  • Rechercher les IoC dans les logs : en priorité le schéma POST /api/session/reset_password (400) → GET /api/user/current (200) ;
  • Considérer la rotation systématique des identifiants des bases connectées, par précaution, même si aucun indicateur de compromission n'est détecté ;
  • Configurer MB_ENCRYPTION_SECRET_KEY si ce n'est pas déjà fait, afin de chiffrer les identifiants stockés dans la base applicative.

La simplicité d'usage qui fait le succès de Metabase — déploiement rapide, partage public par défaut, connexions multiples — constitue aussi sa plus grande surface de risque. Dans un contexte où les outils de BI centralisent l'accès à l'ensemble du patrimoine de données d'une organisation, une faille de cette sévérité ne laisse aucune marge de manœuvre.