Rapport CTI technique du 8 août 2026
Résumé exécutif
Metabase a confirmé le 6 août 2026 l'exploitation active d'une injection SQL non authentifiée notée CVSS 10.0 dans son moteur d'analytique open source, affectant toutes les versions 0.58 à 0.63 et leur équivalent Enterprise. La faille, référencée GHSA-vwf4-m7j8-wcjf et dépourvue à ce jour d'identifiant CVE, permet à un attaquant distant sans compte d'injecter du SQL arbitraire dans la base applicative de Metabase et d'obtenir un accès administrateur complet sur l'instance visée. L'éditeur a bloqué les endpoints utilisés dans l'attaque et publié des correctifs pour toutes les branches concernées, avec des versions minimales sûres fixées à 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 et 0.63.5.
Trois organisations ont confirmé publiquement un impact : le fabricant d'ordinateurs Framework, l'éditeur de formulaires en ligne Tally, et LexisNexis via l'un de ses prestataires tiers exposant une API Metabase. Framework et Tally rapportent tous deux une compromission initiale le 3 août 2026, avec exfiltration de données clients (identités, adresses, hash de mot de passe pour Tally). Ce dossier concerne directement toute organisation exploitant Metabase en libre-hébergement, particulièrement celles qui connectent l'outil à des bases de données de production sans isolation stricte des identifiants.
Chronologie
| Date | Événement |
|---|---|
| 3 août 2026 | Compromission initiale confirmée des instances Metabase de Framework et Tally |
| Semaine du 3 août 2026 | LexisNexis identifie une activité anormale sur des serveurs tiers hébergeant son API Metabase et coupe la connexion |
| 6 août 2026 | Metabase publie son avis de sécurité, confirme l'exploitation active en zero-day et déploie les correctifs sur toutes les branches 0.58 à 0.63 |
| 6 août 2026 | Framework est notifié par Metabase que son instance a été accédée par l'attaquant |
| 7 août 2026 | BleepingComputer publie les détails de l'incident et les confirmations de Framework, Tally et LexisNexis |
Fiche vulnérabilité (format fiche CTI)
GHSA-vwf4-m7j8-wcjf | CVSS 10.0 (Critical) | Metabase Cloud SaaS et Metabase self-hosted, versions 0.58.x à 0.63.x (Open Source et Enterprise)
Description technique : il s'agit d'une injection SQL non authentifiée exploitable via l'endpoint /api/session/reset_password. L'attaquant envoie une requête POST spécialement construite vers cet endpoint, qui échoue avec un code 400 mais laisse échapper suffisamment de contrôle sur la requête SQL générée pour permettre l'injection de commandes arbitraires dans la base applicative de Metabase, celle qui stocke la configuration, les comptes utilisateurs et les identifiants des connexions aux bases de données connectées. Une fois l'injection réussie, l'attaquant enchaîne avec une requête GET vers /api/user/current, qui retourne un contexte de session valide, matérialisant l'élévation vers un accès administrateur complet sans jamais avoir présenté d'identifiants légitimes.
Conditions d'exploitation : aucune authentification requise, aucune interaction utilisateur nécessaire. L'attaquant a uniquement besoin d'un accès réseau à l'API HTTP de l'instance Metabase ciblée, qu'elle soit exposée publiquement ou accessible depuis un segment interne compromis.
PoC disponible : non publié à la date de rédaction. Metabase n'a pas communiqué le détail exact de la charge utile pour limiter la reproduction par des tiers, mais confirme la capacité à identifier une compromission à partir des logs applicatifs.
Patch/mitigation : mise à jour immédiate vers 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 ou 0.63.5 selon la branche utilisée. Les instances Metabase Cloud ont déjà été patchées côté éditeur. Pour les déploiements self-hosted ne pouvant pas patcher immédiatement, Metabase recommande de bloquer temporairement l'accès à l'endpoint /api/session/reset_password en amont (reverse proxy ou WAF), en note que cela désactive la fonctionnalité de réinitialisation de mot de passe le temps de la mise à jour.
Diagramme de la chaîne d'attaque
Reconstruction technique établie à partir de l'avis de sécurité Metabase (GHSA-vwf4-m7j8-wcjf) et du reporting BleepingComputer du 7 août 2026.
Analyse technique
Étape 1 : requête forgée vers l'endpoint de réinitialisation de mot de passe
L'attaquant cible /api/session/reset_password, un endpoint public par nature puisqu'il doit rester accessible aux utilisateurs non authentifiés ayant oublié leur mot de passe. Metabase confirme que la requête malveillante retourne un code 400, ce qui indique que la validation applicative rejette la requête en surface tout en laissant la couche SQL sous-jacente traiter une partie du contenu injecté avant l'échec.
Étape 2 : injection SQL dans la base applicative
La requête forgée atteint le moteur de génération de requêtes de Metabase avec un contrôle suffisant sur la structure SQL pour injecter des instructions arbitraires dans la base applicative, celle qui contient les tables de configuration, de comptes et d'identifiants chiffrés des connexions aux sources de données externes. C'est une injection SQL classique en termes de mécanisme (CWE-89), mais sa portée est aggravée par le fait qu'elle touche la base de contrôle de l'application elle-même plutôt qu'une base métier périphérique.
Étape 3 : établissement d'un contexte de session administrateur
Après l'injection, l'attaquant émet une requête GET vers /api/user/current, qui répond normalement avec les informations du compte associé à la session en cours. En manipulant l'état introduit à l'étape précédente, cette requête aboutit avec un contexte administrateur, sans qu'aucun identifiant n'ait été fourni à un moment de la chaîne. C'est la signature IOC principale documentée par Metabase : un POST 400 vers /api/session/reset_password immédiatement suivi d'un GET réussi vers /api/user/current.
Étape 4 : abus de l'accès administrateur et exfiltration
Avec un accès administrateur complet, l'attaquant peut modifier la configuration de l'instance, lire les identifiants stockés des bases de données connectées, interroger directement ces bases via les connexions existantes de Metabase, et exporter les résultats. Dans les cas documentés, cela s'est traduit par le vol de données clients chez Framework (noms, emails, adresses IP de connexion, adresses de facturation et livraison, numéros de téléphone, et pour les comptes Business, EIN et email de facturation) et chez Tally (adresses email et hash de mots de passe, les formulaires et réponses restant stockés séparément et non affectés).
Indicateurs de compromission
| Type | Valeur |
|---|---|
| Séquence réseau | Requête POST vers /api/session/reset_password retournant HTTP 400, suivie immédiatement d'une requête GET vers /api/user/current retournant HTTP 200 avec un contexte administrateur |
| Fenêtre d'exploitation confirmée | Activité observée à partir du 3 août 2026 sur les instances Framework et Tally |
| Organisations confirmées impactées | Framework (Metabase self-hosted ou géré), Tally, prestataire tiers de LexisNexis (Diligence, Metabase API, Newsdesk) |
| Signal de compromission différée | Toute session administrateur créée sans authentification préalable visible dans les logs d'accès de la même période |
Metabase n'a pas publié d'infrastructure attaquante (IP, domaines) dans son avis à la date de rédaction ; seule la signature comportementale ci-dessus est documentée.
MITRE ATT&CK
| Tactique | Technique | ID | Justification |
|---|---|---|---|
| Initial Access | Exploit Public-Facing Application | T1190 | L'endpoint /api/session/reset_password est exposé sans authentification par conception |
| Credential Access | Exploitation for Credential Access | T1212 | L'injection SQL contourne le mécanisme d'authentification pour obtenir un contexte de session privilégié |
| Privilege Escalation | Valid Accounts | T1078 | Le contexte administrateur obtenu via /api/user/current est ensuite traité comme un compte valide par le reste de l'application |
| Collection | Data from Information Repositories | T1213 | Lecture des identifiants et données via les connexions aux bases externes déjà configurées dans Metabase |
| Exfiltration | Exfiltration Over Web Service | T1567 | Export des données directement via l'interface web administrateur de l'instance compromise |
Cette cartographie est une lecture technique construite à partir de la mécanique décrite par Metabase et BleepingComputer, aucune attribution ATT&CK officielle n'ayant été publiée par l'éditeur ou un fournisseur de threat intelligence à la date de rédaction.
Remédiation : checklist opérationnelle
- Mettre à jour immédiatement toute instance Metabase self-hosted vers la version minimale sûre de sa branche (0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 ou 0.63.5).
- Si une mise à jour immédiate est impossible, bloquer l'accès à l'endpoint /api/session/reset_password au niveau du reverse proxy ou du WAF jusqu'à application du correctif.
- Rechercher dans les logs d'accès la signature POST 400 sur /api/session/reset_password suivie d'un GET 200 sur /api/user/current, sur toute la fenêtre depuis le 1er août 2026 par précaution.
- Révoquer l'intégralité des sessions utilisateurs actives sur l'instance après mise à jour.
- Auditer tous les comptes administrateurs et clés API existants pour détecter des créations ou modifications non planifiées.
- Faire tourner les identifiants de toutes les bases de données connectées à l'instance Metabase, qu'une compromission ait été confirmée ou non.
- Vérifier l'historique de requêtes (query history) pour identifier des exports ou requêtes inhabituelles sur les bases connectées durant la fenêtre suspecte.
- Pour les organisations utilisant des prestataires tiers exposant Metabase (cas LexisNexis), demander confirmation écrite du statut de correctif et du périmètre d'éventuelle exposition de données.
- Notifier les obligations réglementaires applicables (RGPD ou équivalent local) si des données personnelles de clients ont transité par une instance vulnérable pendant la fenêtre d'exploitation.
