Metabase a alerté ses utilisateurs au sujet d’une faille Metabase à sévérité maximale, activement exploitée dans des attaques réelles. D’après l’éditeur, il s’agit d’une vulnérabilité de type zéro‑jour permettant à un attaquant distant sans authentification d’injecter du SQL dans la base de données de l’application. Résultat : l’attaquant peut accéder au compte administrateur de l’instance.
La problématique est particulièrement préoccupante, car la faille n’est pas associée à un identifiant CVE (l’éditeur ne mentionne pas de CVE). Metabase indique néanmoins un score CVSS de 10.0, ce qui reflète l’impact élevé de la brèche.
Ce que permet la faille Metabase
Selon l’avis publié par Metabase, la vulnérabilité autorise un pirate distant non authentifié à injecter des requêtes SQL arbitraires dans la base de données utilisée par l’application. Une fois l’accès administrateur obtenu, l’attaquant peut aller plus loin que l’intrusion initiale.
Concrètement, l’accès élevé permettrait à l’attaquant de :
- modifier la configuration de l’application ;
- récupérer des identifiants stockés pour les bases de données connectées ;
- lire les données accessibles via ces connexions ;
- exporter des données.
Autrement dit, le risque ne se limite pas à la compromission technique : il peut aussi impliquer l’exposition de données sensibles selon les connexions configurées dans Metabase.
Metabase Cloud déjà corrigé : que faire pour l’auto‑hébergement ?
Metabase précise que ses instances Metabase Cloud ont déjà été mises à jour vers la dernière version disponible. L’essentiel de l’action concerne donc les déploiements auto‑hébergés, pour lesquels l’éditeur recommande d’appliquer les correctifs dès que possible.
L’avis liste précisément les versions concernées et celles corrigées. Pour éviter toute confusion, voici la logique telle que communiquée par Metabase : les versions mentionnées comme « fixées » correspondent aux premières versions où la faille Metabase serait résolue.
Versions affectées et versions de correction
- >= x.58.0, < x.58.23 (corrigé dans x.58.24)
- >= x.59.0, < x.59.20 (corrigé dans x.59.21)
- >= x.60.0, < x.60.16 (corrigé dans x.60.17)
- >= x.61.0, < x.61.10 (corrigé dans x.61.11)
- >= x.62.0, < x.62.8 (corrigé dans x.62.9)
- >= x.63.0, < x.63.3 (corrigé dans x.63.5)
Si votre version se situe dans les plages affectées, la recommandation est claire : mettez à jour immédiatement.
Contournement temporaire : bloquer l’endpoint de réinitialisation
En attendant l’installation des correctifs, Metabase propose un mécanisme de réduction du risque. Le conseil temporaire est de bloquer l’endpoint : /api/session/reset_password.
Cette mesure vise à perturber le chemin d’exploitation décrit dans l’avis, particulièrement dans des environnements où l’endpoint serait accessible publiquement.
Si vous avez exposé l’endpoint : actions après mise à jour
Metabase recommande, une fois la mise à jour effectuée, d’effectuer une série de vérifications et de remédiations si votre endpoint /api/session/reset_password était accessible depuis l’extérieur. L’objectif est double : confirmer qu’il n’y a pas eu de compromission et limiter toute persistance éventuelle.
- Révoquer les sessions actives : pour ce faire, Metabase conseille d’accéder à la base de données de l’application et de supprimer toutes les lignes de la table core_session.
- Vérifier les clés d’API : supprimez toutes les clés qui ne sont pas reconnues ou attendues.
- Contrôler les comptes administrateurs : cherchez toute modification inattendue (création, élévation de privilèges, changement de rôles).
- Pivoter les identifiants des bases de données connectées à Metabase. Même si vous n’observez pas d’exfiltration manifeste, l’accès élevé peut avoir permis de récupérer des identifiants stockés.
- Inspecter les journaux du data warehouse : recherchez des signes d’accès non autorisé ou de requêtes anormales.
- Analyser l’historique Metabase : examinez l’activité et l’historique des requêtes afin de repérer toute action suspecte.
Ces étapes vont au-delà d’une simple mise à jour de la faille Metabase : elles servent à corriger un scénario plausible d’attaque menée jusqu’au contrôle de l’instance.
Indicateurs de compromission : quel schéma surveiller
Metabase n’a pas rendu publics de détails techniques sur la façon exacte dont l’activité malveillante s’est déroulée. En revanche, l’éditeur fournit des indicateurs de compromission (IoC) permettant de repérer un modèle d’exploitation.
Le schéma décrit est le suivant :
- un appel à POST /api/session/reset_password avec un code 400 ;
- suivi d’un appel à GET /api/user/current avec un code 200.
Metabase indique qu’en présence de ce motif dans les journaux de votre application ou dans les logs d’entrée (ingress) de votre serveur Metabase, il est « probable » que l’instance ait été compromise.
Le message présenté par le CEO Sameer Al‑Sakran insiste sur l’importance d’une détection rapide : si le pattern est visible, il faut traiter la situation comme un incident potentiel.
Exemple d’impact : le cas Framework
L’avis mentionne que l’un des acteurs touchés serait Framework. D’après les informations reprises par des médias, l’entreprise aurait prévenu ses clients que certaines données ont été consultées pendant l’attaque.
Les éléments évoqués incluent : les noms des clients, les adresses IP de connexion, les adresses, les numéros de téléphone et les emails. En revanche, il est précisé qu’aucune information de commande ou de paiement n’aurait été accessible.
À retenir : même si chaque incident peut varier, ce type d’exploitation montre comment une faille de serveur applicatif peut conduire à des accès à des informations personnelles, selon les configurations et la portée des données connectées.
Pourquoi cette alerte est urgente
Le risque est renforcé par deux éléments : d’une part, la faille Metabase affiche un score CVSS de 10.0 ; d’autre part, Metabase précise qu’il s’agit d’une exploitation dans la nature, donc pas seulement une démonstration technique ou une preuve de concept.
Par ailleurs, l’éditeur rappelle avoir déjà corrigé il y a environ trois ans une autre vulnérabilité jugée extrêmement sévère (CVE‑2023‑38646, CVSS 9.8) qui pouvait mener à une exécution de code à distance avant authentification sur des installations concernées.
En pratique, cela souligne la nécessité de maintenir Metabase à jour et de surveiller les accès inhabituels, surtout lorsque l’instance est exposée à Internet.
Plan d’action recommandé
Pour réduire le risque lié à cette faille Metabase, vous pouvez suivre un plan pragmatique :
- Vérifiez votre version : comparez-la aux plages affectées et mettez à jour vers la version corrigée.
- Appliquez le contournement : bloquez temporairement /api/session/reset_password pendant la période d’attente.
- Contrôlez les journaux : recherchez le motif IoC (POST reset_password avec 400, puis GET user/current avec 200).
- Exécutez les remédiations après correction si l’endpoint était publiquement accessible : révocation des sessions, revue des clés, inspection des comptes administrateurs, rotation des identifiants et analyse des historiques.
En combinant mise à jour, durcissement temporaire et investigation, vous augmentez fortement vos chances de limiter l’impact d’une attaque exploitant cette vulnérabilité.
Conclusion
La faille Metabase décrite par l’éditeur est une vulnérabilité critique exploitée à distance sans authentification, capable d’injecter du SQL et de fournir un accès administrateur. Metabase Cloud est déjà corrigé, tandis que l’auto‑hébergement requiert une action immédiate : mise à jour vers les versions indiquées, blocage temporaire de /api/session/reset_password, puis vérifications approfondies si l’endpoint était exposé.
Si vous détectez le schéma d’appels décrit dans les IoC, considérez l’incident comme plausible et lancez les mesures de remédiation recommandées.
Source: https://thehackernews.com/2026/08/metabase-zero-day-exploited-in-wild.html
