Metabase : une injection SQL zero-day exploitée pour dérober des données sur les instances clientes

Faille critique zero-day dans Metabase permet une injection SQL non authentifiée pour voler des données. Correctifs publiés pour versions vulnérables.

Metabase : une injection SQL zero-day exploitée pour dérober des données sur les instances clientes
Vulnérabilités

Image d’illustration générée par IA

Attaques en cours contre Metabase Cloud et les installations self-hosted

Metabase a confirmé le 7 août 2026 une campagne d’attaques zero-day visant Metabase Cloud, due à une vulnérabilité présente dans les versions 1.58 et ultérieures.

La faille est une injection SQL non authentifiée classée critique, avec un score CVSS de 10,0. Un attaquant distant peut injecter des commandes SQL arbitraires dans la base de données de l’application, sans disposer de compte, et obtenir des privilèges administrateur sur l’instance.

Cet accès peut permettre de :

  • modifier la configuration ;
  • dérober les identifiants des bases de données connectées ;
  • consulter les données accessibles via ces connexions ;
  • exporter des informations depuis l’environnement compromis.

L’attaquant n’a pas été identifié. La vulnérabilité ne possède pour l’instant aucun identifiant CVE.

Metabase a bloqué les points de terminaison utilisés lors des attaques et corrigé le service cloud. Les installations self-hosted, en revanche, nécessitent une mise à jour manuelle.

Versions vulnérables et correctifs disponibles

Les correctifs ont été publiés dans les branches 0.58 à 0.63. Les versions minimales considérées comme sûres sont :

  • 0.58.24
  • 0.59.21
  • 0.60.17
  • 0.61.11
  • 0.62.9
  • 0.63.5

Les administrateurs doivent immédiatement mettre à jour leurs instances self-hosted vers la version corrigée de la branche correspondante. Si cette opération n’est pas possible dans l’immédiat, Metabase recommande de bloquer temporairement l’accès au point de terminaison :

/api/session/reset_password

Cette mesure d’atténuation ne remplace pas l’installation du correctif.

Données dérobées et organisations concernées

Framework a confirmé le vol de données après la compromission de sa propre instance Metabase. L’accès a eu lieu le 3 août 2026 et l’entreprise en a été informée le 6 août 2026.

Les informations potentiellement dérobées comprennent le nom complet, l’adresse e-mail, l’adresse IP de connexion, les adresses de facturation et de livraison, le numéro de téléphone et le nom de l’entreprise. Pour les clients Framework for Business, le nom de l’entreprise, le numéro de téléphone, le numéro de TVA, l’EIN et l’adresse e-mail de facturation sont également concernés.

Tally a signalé la compromission de son environnement Metabase destiné à l’analyse le 3 août 2026. L’incident a concerné des adresses e-mail et des hachés cryptographiques de mots de passe. Les formulaires et les réponses envoyées étaient stockés séparément et ne semblent pas avoir été concernés. L’algorithme de hachage utilisé et l’éventuelle utilisation d’un sel ne sont pas connus.

LexisNexis a pour sa part signalé une attaque chez un prestataire tiers, ayant eu des conséquences sur les services Diligence, Metabase API et Newsdesk. L’entreprise a détecté une activité anormale sur les serveurs du prestataire et déconnecté les systèmes concernés. Elle n’a toutefois pas explicitement déclaré que l’incident était lié à l’API Metabase.

Comment vérifier une éventuelle compromission

Dans les journaux, une séquence potentiellement révélatrice peut comprendre :

  1. une requête POST vers /api/session/reset_password renvoyant une réponse HTTP 400 ;
  2. une requête GET ultérieure vers /api/user/current.

La présence de ces deux requêtes dans les journaux système peut indiquer une compromission. Les administrateurs doivent également :

  • révoquer toutes les sessions utilisateur actives ;
  • vérifier les clés API et les comptes administrateur ;
  • renouveler les identifiants des bases de données connectées ;
  • analyser les journaux et l’historique des requêtes ;
  • rechercher toute modification non autorisée de la configuration ou toute exportation inhabituelle.

La faille ayant fait l’objet d’une exploitation active, les journaux doivent être vérifiés également après l’installation du correctif.

À lire aussi

Sources

Cet article est une réécriture originale fondée sur les sources ci-dessous.

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →