Le jour zéro critique peut fournir un accès SQL direct à la base de données sous-jacente de Metabase, exposant potentiellement les informations d’identification, les clés API et d’autres données sensibles.
Metabase, fournisseur de plateforme de Business Intelligence (BI), a divulgué une vulnérabilité d’injection SQL Zero Day, avertissant que les informations d’identification sensibles, les jetons, les clés API et d’autres données des clients peuvent avoir été exposées.
La vulnérabilité Metabase révélée le 6 août, désignée CVE-2026-72898, est identifiée comme critique, avec un score de gravité de 10, la note la plus élevée possible. Il est présent dans les versions 1.58 et supérieures.
« On ne voit pas souvent un 10/10 parfait sur CVSS, mais quand c’est le cas, soyez inquiet », a noté David Shipley, PDG de Beauceron Security. L’injection SQL est « vieille école et douloureuse, car il existe désormais un code d’exploitation de preuve de concept fonctionnel ».
Accès à la base de données « total et brut »
Metabase est un outil de BI open source que les clients peuvent connecter à des bases de données populaires, notamment Databricks, MongoDB, Oracle, Snowflake, Amazon, BigQuery et bien d’autres. Ils peuvent utiliser la plateforme pour accéder à des analyses, interroger et visualiser des données et créer des tableaux de bord, entre autres actions.
Le moteur de recherche Shodan a suivi environ 2 500 instances Metabase, et la société de sécurité Wiz a signalé qu’environ 13 % des environnements cloud ont déployé des instances Metabase auto-hébergées ; parmi ceux-ci, environ 25 % sont entièrement accessibles sur Internet.
Selon la divulgation de Metabase, un acteur malveillant a utilisé une vulnérabilité d’injection SQL Zero Day dans la plate-forme de l’entreprise pour y accéder. Le point d’entrée est .
Metabase a déclaré qu’après avoir découvert l’attaque, elle avait immédiatement bloqué les points de terminaison exploités, corrigé la vulnérabilité, mis fin aux sessions concernées et révoqué les informations d’identification utilisées lors de l’incident. Les clients Metabase Cloud ont déjà été mis à niveau et corrigés contre la vulnérabilité, mais les clients Metabase auto-hébergés peuvent toujours être vulnérables à moins qu’ils n’aient appliqué le correctif.
« Cette vulnérabilité permet aux attaquants d’avoir un accès SQL brut et total à la base de données Metabase », a déclaré Scott Miserendino, CTO chez DataBee. Ils peuvent voler ou modifier les informations d’identification des bases de données connectées, créer de nouveaux comptes d’administrateur, modifier les configurations des applications, élever les privilèges ou même « dégrader, modifier ou détruire » les informations.
Il a souligné que cette vulnérabilité peut également affecter les plates-formes qui utilisent des versions OEM de Metabase dans le cadre de leur infrastructure. Cela signifie que les utilisateurs concernés peuvent même ne pas savoir qu’ils sont concernés, car ils ne savent pas que Metabase fait partie du produit qu’ils ont acheté.
« Il s’agit d’une vulnérabilité très grave », a prévenu Miserendino.
Victimes jusqu’à présent
Les entreprises qui ont été touchées par la violation semblent, du moins jusqu’à présent, être des organisations de plus petite taille et des startups. Ils incluent Kilo Code, récemment acquis par Anaconda ; Y Combinator a soutenu Tally, qui construit des agents comptables autonomes ; fabricant d’ordinateurs personnels Framework ; plateforme d’automatisation des flux de travail n8n ; et le fournisseur de plateforme de test et de surveillance de l’IA ChecklyHQ.
Les entreprises concernées signalent que les acteurs malveillants ont accédé à des enregistrements contenant des noms d’utilisateur, des adresses e-mail, des mots de passe cloud, des hachages cryptographiques de clés API OpenTelemetry (OTel) utilisés pour la collecte de traces, des jetons d’accès Slack et d’autres informations sensibles.
Ils signalent tous qu’ils contactent directement les clients concernés et ont pris des mesures d’atténuation, notamment la rotation des informations d’identification et des clés API potentiellement concernées, la réinitialisation de tous les mots de passe des utilisateurs, l’invalidation de tous les jetons d’authentification Slackbot pour les utilisateurs concernés, la suppression des comptes d’administrateur compromis et l’examen des journaux d’audit interne.
« La vulnérabilité concernait le produit d’un fournisseur, mais la protection de vos données est notre travail, et cet incident a mis certaines d’entre elles en danger », a déclaré Checkly dans son avis.
Il a déclaré qu’il repensait les processus internes autour des outils d’analyse, améliorant l’assainissement lors du stockage des configurations et des données de contrôle et effectuant des audits approfondis pour limiter l’exposition. Ses ingénieurs de garde seront également alertés lorsque les futurs avis de sécurité des fournisseurs seront publiés afin de permettre une réponse plus rapide.
« La rotation des informations d’identification résout le problème immédiat », a noté la société. « Cela ne résout pas la raison pour laquelle cela a souffert : notre environnement d’analyse contenait plus de données sensibles et disposait d’un accès plus large que nécessaire. »
Ce que les clients concernés doivent faire
Le modèle d’attaque, selon Metabase, est le suivant :
- Un appel avec un code d’état 400
- Ceci est suivi d’un appel à avec un code d’état 200
« Si vous trouvez ce modèle dans vos journaux d’applications ou dans les journaux d’entrée de votre serveur Metabase, il est probable que votre instance ait été compromise », a déclaré la société.
Les clients doivent effectuer une mise à niveau vers un correctif approprié dès que possible. Par exemple, si vous exécutez Metabase 0.58.6, passez à 0.58.24 ou version ultérieure. Ceux qui ne peuvent pas effectuer la mise à niveau immédiatement peuvent mettre en œuvre une solution temporaire en bloquant le point de terminaison.
Si le point de terminaison d’une instance Metabase est accessible au public, les entreprises doivent révoquer toutes les sessions utilisateur actives ; examiner et supprimer toutes les clés API non reconnues ; auditer les journaux de l’entrepôt de données et les comptes d’administrateur pour détecter tout accès non autorisé ou tout autre changement inattendu ; faites pivoter les informations d’identification pour toutes les bases de données connectées ; et examinez l’activité de la métabase et les historiques de requêtes.
Si elles enveloppent l’interface REST d’un tiers, les entreprises doivent toujours effectuer leur propre détection SQLi, a conseillé Miserendino de DataBee. Cela peut être fait en incorporant un pare-feu d’accès Web (WAF) ou un proxy inverse.
« Les entreprises devraient également surveiller leurs journaux de sécurité et de base de données pour détecter la création de comptes d’administrateur nouveaux ou récemment élevés », a-t-il déclaré, « ou toute autre activité inhabituelle telle que de gros volumes de pertes de données ».
Anaconda, pour sa part, exhorte ses clients à rester diligents : « Soyez en alerte en cas de phishing/d’ingénierie sociale et maintenez l’hygiène des informations d’identification (y compris l’audit, l’examen et la rotation régulière des informations d’identification) et la surveillance du spam. »
