Une faille zero-day dans Metabase a été exploitée en conditions réelles avant la publication du correctif, et l’éditeur vient de publier une mise à jour d’urgence. Pour les PME-ETI, l’alerte est sérieuse : Metabase est l’un des outils de business intelligence open source les plus déployés, souvent exposé sur Internet pour permettre aux équipes métier de consulter leurs tableaux de bord — et connecté, par construction, à l’ensemble des bases de données de l’entreprise.
Metabase : un zero-day exploité avant le correctif
Metabase a corrigé une vulnérabilité qui était déjà activement exploitée au moment de la divulgation. Les analyses publiées évoquent un rayon d’impact large : l’application se place au carrefour du système d’information, avec des identifiants de connexion vers PostgreSQL, MySQL, SQL Server, Snowflake ou BigQuery stockés dans sa configuration.
Le schéma d’attaque est classique et redoutablement efficace :
- Une instance Metabase exposée publiquement, souvent derrière un simple reverse proxy.
- Une requête forgée permettant d’atteindre le moteur de requêtes sans authentification complète.
- Un accès aux données métier, puis aux identifiants de bases stockés côté serveur.
- Un pivot vers les bases de production, qui contiennent clients, contrats et données RH.
Autrement dit, compromettre l’outil de BI revient souvent à compromettre toutes les bases qu’il interroge, sans jamais toucher directement aux serveurs de bases de données.
Pourquoi les PME-ETI sont particulièrement exposées
Dans une grande entreprise, l’outil de BI vit derrière un VPN et un portail d’authentification unique. Dans une PME-ETI, il est fréquemment installé en quelques minutes sur une VM, publié en HTTPS pour les commerciaux en déplacement, puis oublié. Aucun inventaire ne le mentionne, aucune procédure de mise à jour ne le couvre, et le compte de service qu’il utilise dispose souvent de droits de lecture bien plus larges que nécessaire.
Sécuriser Metabase : les actions à mener cette semaine
La priorité absolue est le correctif, mais le patch seul ne suffit pas si l’instance a déjà été atteinte. Voici l’ordre d’exécution recommandé.
1. Corriger et vérifier la version
- Appliquer immédiatement la dernière version publiée par l’éditeur, sur les déploiements Docker comme sur les installations JAR.
- Vérifier la version réellement en service après redémarrage — un conteneur non relancé continue d’exécuter l’ancienne image.
- Recenser les instances oubliées : environnements de recette, POC internes, instances hébergées par un prestataire.
2. Chercher les traces de compromission
- Rechercher dans les journaux applicatifs les requêtes anormales vers les points d’accès d’API, en particulier les appels non authentifiés.
- Contrôler la table des utilisateurs Metabase : tout compte administrateur créé récemment doit être considéré comme suspect.
- Analyser les journaux des bases de données cibles : volumétrie de lecture inhabituelle, requêtes hors horaires, exports massifs.
3. Réduire la surface d’exposition
- Retirer l’instance de l’Internet public : accès via VPN, tunnel identitaire ou liste d’adresses autorisées.
- Imposer le SSO et l’authentification multifacteur sur tous les comptes, sans exception pour les comptes techniques.
- Appliquer le moindre privilège aux comptes de service : lecture seule, sur les seules tables nécessaires, jamais un compte propriétaire de schéma.
4. Faire tourner les secrets
Si l’instance était exposée avant le correctif, il faut partir du principe que les identifiants de connexion aux bases ont pu être lus. Régénérer les mots de passe des comptes de service, révoquer les jetons d’API Metabase, et invalider les sessions actives. C’est la même logique de réduction de la fenêtre d’exposition que nous décrivions dans notre article sur la réduction de la fenêtre de patch.
Le zero-day n’est pas une fatalité, l’exposition si
Un zero-day comme celui de Metabase ne se prévient pas : par définition, aucun correctif n’existait au moment de l’exploitation. Ce qui se pilote, en revanche, c’est le fait qu’une application interne de business intelligence soit joignable depuis n’importe quelle adresse IP de la planète. Les mêmes réflexes s’appliquaient à la faille critique TeamCity : les outils internes qui détiennent les clés du système d’information ne doivent pas vivre sur Internet.
Pour une PME-ETI, la bonne pratique tient en trois lignes : inventorier les applications internes publiées, les placer derrière une authentification forte, et surveiller les comptes de service qui les relient aux bases de production. C’est le meilleur rempart contre le prochain zero-day exploité.