Metabase zero-day CVSS 10 : admin sans auth, exploitation active

Les faits

Le 8 août 2026, Metabase a publiquement confirmé l'existence d'une vulnérabilité zero-day de sévérité maximale, notée CVSS 10.0, affectant aussi bien l'édition open source que la version Enterprise de sa plateforme de Business Intelligence. La découverte n'a rien de théorique : la faille avait déjà été exploitée en conditions réelles avant sa divulgation. Le 3 août 2026, l'infrastructure cloud de l'éditeur a elle-même été compromise par un acteur non identifié, qui s'est appuyé sur cette faille — un Metabase zero-day CVSS 10 SQL injection — pour contourner intégralement l'authentification et obtenir des privilèges administrateur sur les instances exposées. Le vecteur combine un défaut de contrôle d'accès et une injection SQL dans un endpoint accessible sans jeton valide. Toute instance Metabase joignable depuis Internet doit être considérée comme compromise jusqu'à preuve du contraire, et corrigée sans délai.

La faille est une injection SQL non authentifiée (CWE-89) localisée dans l'endpoint POST /api/session/reset_password de l'API Metabase. Cet endpoint, destiné à la réinitialisation de mot de passe, est accessible sans authentification par conception — ce qui en fait une surface d'attaque ouverte à n'importe quel acteur disposant d'une connectivité réseau vers l'instance. En injectant des instructions SQL arbitraires via les paramètres de cet endpoint, un attaquant peut interagir directement avec la base de données applicative de Metabase sans jamais avoir fourni le moindre identifiant valide.

L'impact de l'exploitation réussie est total. L'attaquant peut : modifier la configuration de l'application pour s'octroyer des droits administrateur ; extraire les credentials des bases de données connectées à Metabase (PostgreSQL, MySQL, BigQuery, Snowflake, Redshift, MongoDB) ; lire ou exporter l'intégralité des données accessibles via les connexions configurées ; modifier ou supprimer dashboards et datasets. En pratique, quelques requêtes HTTP non authentifiées suffisent à obtenir les mots de passe des bases de données de production d'une organisation entière.

La faille est référencée GHSA-vwf4-m7j8-wcjf dans la GitHub Security Advisory. Une assignation CVE est en cours — CVE-2026-59826 est par ailleurs référencé sur cvefeed.io comme une vulnérabilité distincte d'exécution de code arbitraire via contournement des paramètres de connexion base de données dans Metabase. Les versions affectées s'étendent de 0.58 à 0.63 pour Metabase OSS et de 1.58 à 1.63 pour Metabase Enterprise, couvrant environ 18 mois de versions publiées.

La détection de la compromission initiale est intervenue lorsque l'équipe sécurité de Metabase a observé des patterns anormaux sur son infrastructure cloud le 3 août : des requêtes non authentifiées vers /api/session/reset_password avec des payloads inhabituellement volumineux, provenant d'adresses IP inconnues. La réponse a été rapide — blocage des endpoints malveillants, développement et déploiement du patch, migration automatique des clients cloud — mais les instances self-hosted ont été exposées sans le savoir pendant 5 jours, entre la compromission du 3 août et la divulgation publique du 8 août.

La nature de Metabase comme outil de Business Intelligence rend cette vulnérabilité particulièrement dangereuse. Metabase est typiquement connecté aux sources de données les plus sensibles de l'organisation : entrepôts analytiques, bases clients, systèmes CRM, données de facturation, bases RH. Il dispose généralement de comptes de service avec des droits en lecture (parfois lecture-écriture) sur ces systèmes. La compromission d'une instance Metabase peut déboucher sur l'exfiltration de l'intégralité du patrimoine de données analytiques d'une organisation, voire sur la compromission des bases sous-jacentes si les credentials extraits sont réutilisés ou si les comptes disposent de droits d'écriture.

Un facteur aggravant mérite attention : Metabase est fréquemment installé par des équipes data ou produit en dehors du périmètre de contrôle de la DSI ou de l'équipe sécurité, sur des serveurs cloud accessibles depuis Internet sans authentification préalable — notamment pour les dashboards publics. Ce phénomène de shadow IT BI génère une exposition non maîtrisée. Les instances ainsi exposées sont indexables sur Shodan et d'autres moteurs de recherche d'appareils connectés, facilitant leur identification par des attaquants qui n'ont plus qu'à tester l'endpoint vulnérable.

À la date de divulgation du 8 août 2026, des versions corrigées sont disponibles pour toutes les branches affectées. Les utilisateurs Metabase Cloud sont automatiquement protégés. Les utilisateurs self-hosted doivent appliquer la mise à jour manuellement, analyser leurs journaux d'accès pour détecter des requêtes suspectes vers /api/session/reset_password depuis au moins le 1er août, et inspecter les comptes utilisateurs pour détecter des créations ou modifications non autorisées de comptes administrateurs. Les bases de données connectées à l'instance doivent être traitées comme potentiellement compromises jusqu'à preuve du contraire.

Impact et exposition

Toute instance Metabase self-hosted non patchée et accessible depuis Internet est à considérer compromise jusqu'à preuve du contraire. Metabase OSS et Enterprise sont tous deux affectés. Les organisations qui exposent leurs dashboards Metabase publiquement sans authentification préalable — pratique courante pour les portails de transparence ou les dashboards clients — offrent la surface d'attaque la plus accessible. Les bases de données connectées (PostgreSQL, MySQL, BigQuery, Snowflake, Redshift) doivent être considérées potentiellement compromises si l'instance était vulnérable et exposée lors de la fenêtre du 3 au 8 août.

Recommandations

• Immédiat — Mettre à jour toutes les instances Metabase self-hosted vers la dernière version corrective. Vérifier la version via l'interface admin ou les logs de démarrage du service.
• Audit de compromission — Analyser les logs d'accès depuis le 1er août : requêtes POST vers /api/session/reset_password avec payloads anormaux, créations de comptes admin, modifications de configuration, accès inhabituels aux connexions de données.
• Rotation des credentials — Changer immédiatement tous les mots de passe des comptes de service des bases de données connectées à Metabase, en supposant qu'ils ont été exfiltrés si l'instance était exposée.
• Inventaire shadow IT — Identifier toutes les instances Metabase déployées dans l'organisation, y compris celles gérées par des équipes data hors du périmètre IT/Sécurité, et s'assurer qu'elles sont toutes patchées.
• Notification RGPD — Si des données personnelles étaient accessibles via Metabase et que l'instance était exposée, évaluer l'obligation de notification à la CNIL dans les 72h suivant la constatation d'une violation potentielle.