Metabase, l’outil de business intelligence open source très répandu, a publié le 6 août un avis de sécurité sur une faille activement exploitée : une injection SQL accessible sans authentification, référencée CVE-2026-72898 et notée 10/10 (CVSS 3.1). Metabase Cloud a été attaqué avant la publication du correctif ; les instances auto-hébergées sont vulnérables tant qu’elles ne sont pas mises à jour. Première victime connue : le fabricant de PC réparables Framework.
Ce que permet la faille
Le point d’entrée est l’API /api/session/reset_password. Un attaquant distant peut y injecter du SQL arbitraire dans la base applicative de Metabase et obtenir un accès administrateur. D’après l’avis, il peut ensuite :
- modifier la configuration de l’instance ;
- voler les identifiants des bases de données connectées, que Metabase stocke pour exécuter les requêtes ;
- lire et exporter les données accessibles via ces connexions.
C’est ce qui rend l’incident sérieux : Metabase est par nature branché sur les entrepôts de données de l’entreprise, souvent avec des droits de lecture larges. Une instance compromise donne un accès direct aux données métier, et les identifiants volés restent valables tant qu’ils ne sont pas changés.
Versions vulnérables et corrigées
| Branche | Version corrigée minimale |
|---|---|
| 0.63 | 0.63.5 |
| 0.62 | 0.62.9 |
| 0.61 | 0.61.11 |
| 0.60 | 0.60.17 |
| 0.59 | 0.59.21 |
| 0.58 | 0.58.24 |
Les versions antérieures à la 58 ne sont pas concernées. Les clients de Metabase Cloud ont déjà été corrigés. Attention aux numéros : une 0.58.6, par exemple, reste vulnérable et doit passer en 0.58.24 au minimum.
Framework, première victime visible
Le 6 août, Framework a commencé à écrire à ses clients : des attaquants ont obtenu leurs noms, adresses e-mail, numéros de téléphone et adresses postales via l’instance Metabase Cloud de l’entreprise. Un porte-parole a indiqué à TechCrunch que « tous les clients » sont concernés, sans donner de chiffre. Les données de paiement ne seraient pas touchées. Framework dit avoir changé ses identifiants d’accès dès la notification.
Si votre instance Metabase auto-hébergée exposait /api/session/reset_password sur Internet avant la mise à jour, la mise à jour ne suffit pas : partez du principe que l’instance a pu être compromise et suivez les étapes ci-dessous.
Que faire si vous utilisez Metabase
- Mettez à jour vers la version corrigée de votre branche (image Docker
metabase/metabase:v0.58.24, en adaptant le numéro). - Si vous ne pouvez pas mettre à jour tout de suite, bloquez l’URL
/api/session/reset_passwordau niveau du reverse proxy. - Si l’URL était accessible publiquement : supprimez toutes les lignes de la table
core_sessionde la base applicative pour invalider les sessions, passez en revue les clés d’API et les comptes administrateurs, et changez les identifiants de toutes les bases connectées. - Examinez les journaux de vos entrepôts de données et l’historique des requêtes Metabase à la recherche d’accès inhabituels.
Metabase donne un indicateur de compromission dans les journaux HTTP : une requête POST /api/session/reset_password qui renvoie 400, suivie d’un GET /api/user/current qui renvoie 200.
# Mettre à jour une instance Docker (adapter la branche)
docker pull metabase/metabase:v0.58.24
# Repérer le motif signalé par Metabase dans les journaux nginx
grep -E 'POST /api/session/reset_password|GET /api/user/current' /var/log/nginx/access.logPour le blocage temporaire, un simple location = /api/session/reset_password { return 403; } dans la configuration nginx suffit ; la fonction de réinitialisation du mot de passe sera indisponible en attendant la mise à jour.
Ce qu’on en retient
Un outil de BI concentre des identifiants vers presque toutes les bases de l’entreprise. Il mérite d’être traité comme un système sensible : pas d’exposition directe sur Internet, accès derrière un VPN ou un SSO, et des comptes de base de données en lecture seule limités au strict nécessaire.