Introduction
Le 3 août 2026, un attaquant exploitait une vulnérabilité inconnue dans Metabase Cloud. Point d'entrée : l'endpoint de réinitialisation de mot de passe, ciblé par une injection SQL permettant d'escalader jusqu'aux droits administrateur. Depuis cette position, l'attaquant accédait aux identifiants stockés pour chaque base de données connectée à l'instance — et en exportait le contenu. Trois jours plus tard, Framework Computers révélait que les données personnelles de ses clients (noms, adresses e-mail, numéros de téléphone, adresses postales) avaient été compromises. L'éditeur a déployé un correctif sur son offre cloud en urgence. Les instances self-hosted, elles, restent exposées tant qu'elles ne sont pas mises à jour.
Quand votre outil BI tient les clés de votre entrepôt de données
Ce qui frappe dans cet incident, c'est moins la nature de la faille que ce qu'elle révèle sur la position réelle de Metabase dans les architectures data. Une plateforme BI n'est pas seulement un outil de visualisation : elle centralise les connexions aux bases de données opérationnelles, à l'entrepôt de données, parfois à des bases de test alimentées par des données de production. Elle stocke les identifiants de ces connexions. Elle les utilise en permanence pour exécuter des requêtes.
Dans ce schéma, compromettre la couche analytics suffit à court-circuiter toutes les mesures de sécurité mises en place directement sur les bases. Ce n'est pas la base qui a été attaquée en premier. C'est l'outil qui la surplombe.
Un angle mort dans vos revues d'accès
Les comptes de service créés pour les plateformes BI ont tendance à accumuler des droits larges — nécessaires pour que les équipes data puissent interroger librement les sources. Ils bénéficient souvent d'un accès en lecture sur l'intégralité de certains schémas, voire de droits d'écriture pour certains usages. Mais ces comptes passent rarement par les mêmes revues que les comptes DBA. Leurs credentials ne sont pas systématiquement inclus dans les politiques de rotation. Leur activité n'est pas toujours remontée dans le SIEM.
L'incident Metabase donne un visage concret à cet angle mort.
Actions immédiates pour les équipes self-hosted
Toutes les instances fonctionnant en version 58 ou supérieure sont concernées. Metabase distingue deux éditions par le premier chiffre du numéro de version : Community Edition (préfixe 0.x) et Enterprise Edition (préfixe 1.x), chaque branche corrective existant dans les deux variantes. Les versions minimales sûres disponibles sont :
- Branche 58 : 0.58.24 / 1.58.24
- Branche 59 : 0.59.21 / 1.59.21
- Branche 60 : 0.60.17 / 1.60.17
- Branche 61 : 0.61.11 / 1.61.11
- Branche 62 : 0.62.9 / 1.62.9
- Branche 63 : 0.63.5 / 1.63.5
Si la mise à jour immédiate n'est pas possible, bloquer l'endpoint /api/session/reset_password au niveau du reverse proxy constitue un palliatif temporaire. Il faut également révoquer les sessions actives, changer les credentials des bases connectées et auditer les logs d'activité pour détecter d'éventuels accès non autorisés.
La vraie question : que savent vos outils analytics de vos bases ?
Au-delà du patch, l'incident invite à un exercice plus fondamental. Quels droits d'accès ont réellement vos plateformes BI sur vos systèmes de données ? Ces outils disposent-ils d'accès en lecture seule et restreints aux tables strictement nécessaires, ou peuvent-ils potentiellement exporter des schémas entiers ? Les identifiants stockés sont-ils dans le périmètre de votre politique de gestion des secrets ? Les logs de ces outils sont-ils intégrés à votre surveillance ?
Une gouvernance data sérieuse ne s'arrête pas à la sécurité des bases de données elles-mêmes. Elle couvre également les couches applicatives qui y accèdent — outils analytics, pipelines d'intégration, APIs internes. Chacune représente une surface d'exposition, souvent moins bien surveillée que les systèmes sous-jacents.
Mettre à jour Metabase cette semaine est nécessaire. Savoir précisément ce que tous vos outils analytics peuvent faire avec vos données l'est tout autant.