Metabase : des compromissions signalées, les correctifs à vérifier

Une alerte sur des attaques constatées

Le 10 septembre 2026, le CERT-FR a signalé de nombreuses compromissions d’installations Metabase vulnérables. L’alerte porte sur une injection SQL, c’est-à-dire l’introduction de commandes non prévues dans une base de données. L’attaque peut donner à une personne non authentifiée les droits d’administrateur de Metabase.

Selon l’éditeur, l’attaquant peut ensuite récupérer les identifiants enregistrés pour les bases connectées et consulter les données accessibles par ces connexions. Le périmètre dépasse donc le seul compte utilisateur de l’outil. Pour le dirigeant, la vérification doit couvrir à la fois la version installée et les accès aux données.

Les installations à faire vérifier

Sont concernées les PME qui exploitent une installation Metabase auto-hébergée, administrée en interne ou par leur prestataire. Les éditions gratuite et payante disposent de correctifs. Les numéros ci-dessous utilisent la notation de l’éditeur : x vaut 0 pour l’édition libre et 1 pour l’édition payante.

Metabase indiquait le 6 août que ses clients Metabase Cloud avaient déjà reçu le correctif contre la vulnérabilité initiale. Cela ne signifie pas qu’aucune attaque n’avait précédé cette correction : son retour d’incident décrit des clients touchés avant le déploiement. Cette situation doit être distinguée de celle d’un logiciel installé et maintenu par votre entreprise.

L’exposition publique détermine aussi les suites à donner. Si le point d’accès /api/session/reset_password est accessible publiquement, l’éditeur demande des opérations supplémentaires après la mise à jour. Il ne conditionne pas ces opérations à la découverte préalable d’une intrusion.

Deux étapes de correction à distinguer

Le premier avis date du 6 août 2026. Un autre bulletin, publié le 11 août, traite de plusieurs faiblesses supplémentaires et indique les versions corrigées suivantes, par branche :

• Branche x.58 : x.58.28.
• Branche x.59 : x.59.25.
• Branche x.60 : x.60.21.
• Branche x.61 : x.61.15.
• Branche x.62 : x.62.13.
• Branche x.63 : x.63.10.

Ces seuils correspondent à ceux repris dans l’alerte de septembre. Ils servent de repères pour ces correctifs, sans constituer une recommandation de rester durablement sur une ancienne branche. Le bulletin complémentaire inclut également les versions antérieures à x.58.28 : pour une installation plus ancienne, suivez la procédure de mise à jour de l’éditeur.

Une intervention réalisée début août ne suffit donc pas à clore le sujet sans relever son numéro de version final. Demandez ce numéro à votre administrateur, ainsi que le compte rendu des vérifications d’accès.

Les actions à engager avec votre administrateur

1. Relevez la version et l’édition installées. Comparez-les aux correctifs de la branche correspondante. Suivez la procédure de mise à jour correspondant à votre installation.
2. Préparez et appliquez la mise à jour. Sauvegardez d’abord la base applicative de Metabase, puis suivez la procédure adaptée à votre installation.
3. Si la correction immédiate est impossible, bloquez temporairement le point d’accès concerné. Cette mesure de contournement est celle proposée par l’éditeur ; elle ne remplace pas la mise à jour.
4. Si ce point d’accès est public, réexaminez les accès après correction. Révoquez les sessions actives, supprimez les clés API inconnues — les identifiants des accès automatisés — et recherchez les modifications inattendues des comptes administrateurs. Renouvelez les identifiants de toutes les bases connectées.
5. Dans cette même situation, examinez les traces. Faites contrôler les journaux des bases connectées et l’historique des activités et requêtes Metabase pour rechercher des accès non autorisés.
6. Si une intrusion est suspectée, engagez une qualification d’incident. Faites évaluer son périmètre et ses conséquences ; préservez les traces avant toute réinitialisation d’un équipement suspect.

VCSTS accompagne les entreprises dans la sécurité de leurs infrastructures.