Zero-day Metabase par injection SQL exploitée : Framework et Tally confirment des fuites de données

YuSMP Group Editorial Team Équipe éditoriale, YuSMP Group

L’essentiel

Que s’est-il passé ?

Metabase a détecté les intrusions le 3 août 2026. Trois jours plus tard, le 6 août, l’éditeur a prévenu les clients touchés, bloqué les points de terminaison d’API utilisés lors des attaques et publié des versions corrigées. La divulgation publique a suivi le 7 août.

Framework a été la première victime d’envergure à communiquer. Dans un e-mail envoyé à tous ses clients le 7 août, l’entreprise a indiqué que des attaquants avaient accédé à des fiches clients via un service tiers de business intelligence – Metabase. Les données volées comprennent noms, adresses e-mail, numéros de téléphone et adresses de facturation et de livraison. Les données de paiement ne sont pas concernées.

Tally, qui conçoit des formulaires numériques utilisés par des milliers d’entreprises, a confirmé une compromission distincte exposant les adresses e-mail et les mots de passe hachés de ses comptes utilisateurs, sans atteindre les données des formulaires clients. LexisNexis a également signalé que son intégration API Metabase avait été touchée ; l’ampleur reste à confirmer.

Comment fonctionne la vulnérabilité ?

Il s’agit d’une injection SQL sans authentification dans la couche applicative de Metabase. Metabase stocke chaînes de connexion, identifiants et résultats de requêtes pour chaque source de données qu’il gère. En injectant du SQL directement dans la base de Metabase – sans s’authentifier au préalable –, un attaquant peut s’élever au rang d’administrateur, lire les identifiants stockés et, de là, rebondir vers chaque source de données connectée.

Le périmètre d’impact potentiel est large. En production, une instance Metabase détient souvent les identifiants de plusieurs entrepôts de données, bases transactionnelles et API externes. Sa compromission peut donc exposer bien plus que les données visibles dans les tableaux de bord. Si Metabase interroge directement les bases de production, c’est l’ensemble des données qui est en jeu. C’est précisément pourquoi les audits de sécurité réguliers doivent couvrir les outils de BI et d’analytique, pas seulement les serveurs applicatifs et les API.

Aucun identifiant CVE n’a encore été attribué. Le score CVSS est de 10.0 – le maximum –, reflet de la combinaison absence d’authentification, exposition totale des données et exploitation à distance.

Comment détecter une compromission ?

Metabase a identifié une signature précise de l’attaque dans les journaux : une requête POST vers /api/session/reset_password renvoyant HTTP 400, suivie immédiatement d’une requête GET réussie vers /api/user/current renvoyant HTTP 200. Recherchez ce motif dans les journaux du serveur web et de l’application. Si vous le trouvez, considérez l’instance comme entièrement compromise.

Marche à suivre en cas de compromission confirmée : renouveler tous les identifiants de bases de données et clés d’API stockés dans Metabase ou accessibles par son biais, recenser les jeux de données et systèmes en aval auxquels l’instance avait accès, et examiner les journaux d’accès de ces systèmes entre le 3 et le 6 août à la recherche de requêtes ou d’exports inhabituels.

Qu’est-ce que cela signifie pour les équipes logicielles aux États-Unis et dans l’UE ?

L’incident Metabase s’inscrit dans un schéma récurrent en 2026 : le maillon le plus faible d’une pile logicielle n’est souvent pas l’application développée en interne, mais l’outillage opérationnel tiers qui l’entoure. Présenté comme un outil d’analyse interne, Metabase fait généralement l’objet de moins de contrôles que les systèmes exposés aux clients – alors qu’il détient les accès aux mêmes bases de données.

Pour les équipes FinTech, HealthTech et e-commerce, l’enjeu est majeur. Dans ces environnements, Metabase est souvent relié à des bases contenant données financières, données personnelles, données de santé ou historiques de paiement. Au titre du RGPD, une violation touchant des données de résidents européens doit être notifiée à l’autorité de contrôle compétente dans les 72 heures suivant sa découverte. Aux États-Unis, la loi HIPAA impose, pour les données de santé, une notification au Department of Health and Human Services et, le cas échéant, aux personnes concernées.

La leçon d’architecture porte sur le périmètre d’impact. Un outil qui agrège les identifiants de nombreuses sources de données devient une cible de choix. Appliquez à votre couche BI et analytique les mêmes contrôles d’accès, la même discipline de correctifs et la même couverture d’audit qu’à votre couche API.

Qu’est-ce que cela signifie pour le marché français ?

En France, Metabase est très répandu chez les start-up et scale-up de la French Tech, souvent auto-hébergé par l’équipe data sur un serveur isolé, hors du périmètre suivi par le RSSI. Ce sont précisément ces instances « fantômes » qui posent problème aujourd’hui. Si des données personnelles ont pu être consultées, la notification à la CNIL doit intervenir dans les 72 heures après la prise de connaissance de la violation (article 33 du RGPD), via le téléservice de notification de la CNIL, et chaque incident doit être consigné dans le registre interne des violations.

Le CERT-FR de l’ANSSI publie régulièrement des alertes sur ce type de vulnérabilités critiques ; pour les entités soumises à NIS2, une chaîne de déclaration des incidents importants s’ajoute aux obligations RGPD. Concrètement : recensez dès maintenant toutes les instances Metabase de l’organisation, y compris celles non déclarées à la DSI, et documentez la date du correctif et l’analyse des journaux – ce sont les preuves que demanderont le DPO et les auditeurs.

Que faire maintenant ?

• Identifiez votre version. Dans Metabase : Paramètres → Admin → Troubleshooting → Version. Comparez-la à la plage concernée (toute version de 1.58 à 0.63).
• Appliquez le correctif immédiatement. Passez à la version corrigée de votre version mineure : 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 ou 0.63.5. Sur Metabase Cloud, le correctif a été appliqué automatiquement ; vérifiez la version affichée dans votre instance.
• Si vous ne pouvez pas corriger tout de suite, mettez l’instance hors ligne ou bloquez l’accès externe jusqu’à la mise à jour. Une instance Metabase non corrigée et accessible depuis Internet est un risque actif.
• Analysez vos journaux à la recherche de la signature d’attaque décrite plus haut. Si vous la trouvez, lancez la réponse à incident : renouvelez les identifiants et auditez les systèmes en aval.
• Renouvelez les identifiants stockés par précaution, même sans trace dans les journaux. L’attaque a duré au moins trois jours avant d’être détectée ; la rotation reste la bonne mesure.
• Vérifiez l’exposition réseau de Metabase. Dans la plupart des environnements, un outil de BI ne devrait pas être accessible directement depuis Internet. Si c’est le cas, limitez l’accès au VPN ou au réseau interne.
• Pour les équipes soumises au RGPD : si votre instance contenait des données personnelles de résidents européens et que vous trouvez des traces d’accès, le délai de 72 heures pour notifier l’autorité de contrôle court à partir de la prise de connaissance – documentez ce moment.

Questions fréquentes