Metabase victime d’un zero-day CVSS 10.0 qui donne les clés administrateur sans authentification
Le 8 août 2026, Metabase a révélé qu’une injection SQL critique (CVSS 10.0) était exploitée dans la nature avant même la publication du correctif. La faille permet à un attaquant non authentifié d’obtenir les droits administrateur et de siphonner toutes les bases de données connectées. Tout administrateur auto-hébergeant Metabase doit patcher, révoquer les sessions et pivoter les secrets immédiatement.
8 août 2026, 12 h 24 UTC. L’équipe Metabase publie l’avis GHSA-vwf4-m7j8-wcjf sur GitHub. La vulnérabilité — pas encore de CVE assigné au 8 août — obtient le score maximal de CVSS 10.0. Le vecteur est brutalement simple : une injection SQL non authentifiée dans l’endpoint /api/setup/validate qui permet à un attaquant distant d’obtenir les droits administrateur complets sur l’instance Metabase, puis d’accéder à toutes les bases de données connectées.
Ce n’est pas un exercice de laboratoire. Metabase confirme que la faille a été exploitée dans la nature comme zero-day avant la publication du correctif. Les instances Metabase Cloud ont été mises à jour en amont. Si vous auto-hébergez Metabase en version 1.58 ou supérieure, votre instance est vulnérable et potentiellement déjà compromise. Le correctif ne suffit pas — il faut aussi révoquer toutes les sessions, pivoter les secrets et examiner les logs.
Une injection SQL triviale contre un endpoint non protégé
Metabase est un outil de business intelligence open source utilisé par des équipes data pour visualiser et explorer leurs bases de données. Il se connecte à PostgreSQL, MySQL, BigQuery, Snowflake et une trentaine d’autres sources. Une instance Metabase typique est le point d’accès unique à des données parfois critiques : chiffre d’affaires, données clients, pipelines de production.
Le problème se situe dans l’endpoint /api/setup/validate. Cet endpoint, normalement utilisé pendant la phase d’installation initiale pour valider la connexion à la base applicative de Metabase, n’exige pas d’authentification et transmet directement les paramètres fournis par l’utilisateur à une requête SQL sans filtrage adéquat.
Un attaquant peut envoyer une requête POST avec un payload SQL malveillant dans le paramètre token. La vulnérabilité est de type injection SQL classique — pas de contournement sophistiqué, pas de chaîne d’exploitation complexe. Le payload s’exécute avec les privilèges de la base de données applicative de Metabase, qui contient les tables core_user, core_session et toutes les informations de connexion aux sources de données externes.
# Indicateur de compromission : toute requête vers /api/setup/validate
# retournant un statut 200 dans les logs HTTP de Metabase
grep '/api/setup/validate' /var/log/metabase/access.log | grep ' 200 'Une fois administrateur, l’attaquant peut :
- Modifier la configuration de l’instance et désactiver les logs
- Exporter tous les utilisateurs et leurs permissions
- Créer des questions SQL arbitraires et interroger les bases connectées
- Extraire le contenu complet des bases de données accessibles via les connexions configurées
- Exporter les données au format CSV ou JSON depuis l’interface d’administration
Le CEO de Metabase, Sameer Al-Sakran, a confirmé sur le fil GitHub que l’entreprise a « récemment identifié que Metabase Cloud a été attaqué par quelqu’un utilisant une vulnérabilité de sécurité inconnue dans les versions 1.58 et supérieures ».
Impact : chaque connexion de base de données devient un vecteur d’exfiltration
La gravité de ce zero-day ne tient pas seulement à l’escalade de privilèges — elle tient à l’effet multiplicateur des connexions configurées dans Metabase.
Une instance Metabase connectée à trois sources de données signifie que l’attaquant peut potentiellement siphonner trois bases de données distinctes après avoir obtenu les droits administrateur. Dans les déploiements d’entreprise, Metabase est souvent connecté à des entrepôts de données (Snowflake, Redshift, BigQuery) contenant des années d’historique transactionnel.
Metabase a également confirmé un indicateur de compromission précis : toute requête vers /api/setup/validate retournant un code 200 dans les logs du serveur applicatif. Si vous trouvez ce pattern dans vos logs nginx ou vos logs d’ingress Metabase, votre instance est très probablement compromise.
Une entreprise utilisatrice, dont le nom n’a pas été divulgué, a confirmé publiquement avoir été victime de cette exploitation. Elle précise qu’aucune donnée de commande ou de paiement n’a été accédée — un constat qui suggère que l’attaquant ciblait spécifiquement les bases analytiques plutôt que les systèmes transactionnels.
Le précédent de 2023 : une histoire qui se répète
Ce n’est pas la première fois que Metabase fait face à une vulnérabilité critique. En juillet 2023, la faille CVE-2023-38646 (CVSS 9.8) permettait une exécution de code distante pré-authentifiée via l’endpoint /api/setup/validate — le même endpoint impliqué aujourd’hui.
La correction de 2023 avait introduit une validation supplémentaire, mais manifestement insuffisante pour couvrir tous les chemins d’exécution. Trois ans plus tard, le même endpoint trahit à nouveau ses utilisateurs. Le pattern est documenté et prévisible : un endpoint d’installation qui survit à la phase d’installation, exposé sans authentification, qui transmet des entrées utilisateur à une base de données.
La leçon pour les équipes de sécurité applicative est limpide : un endpoint d’installation ne doit jamais survivre à la phase d’installation. S’il doit rester accessible, il doit être protégé par le même niveau d’authentification que le reste de l’application.
Comment réagir : le patching ne suffit pas
Metabase a publié le correctif le 8 août 2026 via une mise à jour de sécurité. Les versions patchées incluent la dernière ligne de release de Metabase. L’application du correctif est immédiate et non optionnelle — mais c’est la première étape d’une liste plus longue.
Voici la procédure complète recommandée par Metabase :
1. Appliquer le correctif. Mettez à jour vers la dernière version de Metabase. Les instances Metabase Cloud ont déjà été mises à jour côté serveur ; les clients auto-hébergés doivent appliquer le correctif manuellement.
2. Révoquer toutes les sessions actives. Connectez-vous à la base de données applicative de Metabase (celle que vous avez configurée pendant l’installation) et exécutez :
DELETE FROM core_session;Cette commande invalide tous les tokens de session existants et force tous les utilisateurs — y compris l’attaquant — à se réauthentifier.
3. Vérifier les clés API et les tokens. Examinez la table core_user et la liste des clés API dans l’interface d’administration. Révoquez toute clé que vous ne reconnaissez pas.
4. Pivoter les secrets des connexions aux bases de données. Les mots de passe des sources de données connectées à Metabase sont stockés dans la base applicative et ont pu être lus par l’attaquant. Changez les identifiants de toutes les bases de données connectées.
5. Examiner les logs de data warehouse. Vérifiez les journaux de requêtes de vos bases de données sources (PostgreSQL, Snowflake, BigQuery, etc.) pour détecter toute activité suspecte correspondant aux horaires de compromission.
6. Examiner l’activité Metabase. Utilisez la vue d’audit intégrée de Metabase (Admin > Audit) pour identifier les requêtes SQL inhabituelles ou les exports de données non autorisés.
Verdict
Si vous auto-hébergez Metabase en version 1.58 ou supérieure et que vous n’avez pas encore appliqué le correctif du 8 août, arrêtez l’instance maintenant et suivez la procédure ci-dessus dans l’ordre. Le patching seul ne protège pas contre une compromission déjà réalisée — la révocation des sessions et la rotation des secrets sont aussi critiques que la mise à jour.
Pour les nouvelles instances, deux règles de hardening s’imposent : placez Metabase derrière un reverse proxy avec authentification (même basique), et supprimez l’endpoint /api/setup/validate après l’installation initiale. Cet endpoint n’a aucune raison d’exister après le premier lancement.