La plateforme australienne d’apprentissage des mathématiques Mathspace a confirmé une fuite touchant 1 079 819 personnes en Australie et en Nouvelle-Zélande : élèves, parents, enseignants et salariés. Les attaquants sont entrés par son instance Metabase auto-hébergée, l’outil de tableaux de bord utilisé pour le reporting interne. L’intérêt du cas est ailleurs : Mathspace avait bien installé le correctif, mais trop tard et sans vérifier si elle avait déjà été compromise.
Chronologie : le correctif est arrivé après l’intrusion
| Date (2026) | Événement |
|---|---|
| 6 août | Metabase publie un avis critique et des versions corrigées |
| 10 août | Premier accès non autorisé identifié chez Mathspace |
| 27 août | Téléchargement de données depuis la base de reporting australienne |
| 29 août | Mathspace met à jour Metabase, à la suite d’un rappel de l’éditeur |
| 3 sept. | L’analyse des journaux révèle l’intrusion ; confinement |
| 4 sept. | Écoles et régulateurs prévenus |
| 6 sept. | Début des notifications individuelles |
Selon le récit publié par l’entreprise, l’avis critique du 6 août n’a pas été remonté par son processus de veille sur les vulnérabilités. Et lors de la mise à jour du 29 août, les vérifications de compromission recommandées par Metabase n’ont pas été réalisées. Ce n’est qu’en relisant les journaux d’accès, le 3 septembre, que l’équipe a découvert que l’attaquant était là depuis plusieurs semaines.
Quelles données ont fuité
- identifiant et nom d’utilisateur, prénom et nom, adresse email ;
- pays, fuseau horaire, type d’utilisateur (élève, parent, enseignant…) ;
- statut de vérification de l’email, dates d’inscription, de dernière activité et de dernière connexion.
Mathspace affirme que ni les résultats scolaires, ni les hachages de mots de passe, ni les jetons SSO ou d’API ne figuraient dans les données exposées. Le lien entre un compte et son école n’était pas directement présent, mais peut se deviner quand l’établissement a un domaine email reconnaissable.
La faille Metabase en question
Mathspace ne cite pas d’identifiant, mais décrit une faille permettant d’obtenir les droits administrateur sans se connecter. Cela correspond à la CVE-2026-72898, détaillée par Bishop Fox : une injection SQL sans authentification dans POST /api/session/reset_password, qui touche les branches 58 à 63. Un administrateur Metabase a accès aux connexions vers les bases de données et entrepôts branchés à l’outil, d’où le volume de la fuite.
| Branche | Version corrigée minimale |
|---|---|
| 58.x | 58.24 |
| 59.x | 59.21 |
| 60.x | 60.17 |
| 61.x | 61.11 |
| 62.x | 62.9 |
| 63.x | 63.5 |
Si votre instance était exposée sur Internet avec une version vulnérable, partez du principe qu’elle a pu être compromise avant la mise à jour, même si vous l’avez faite rapidement.
Vérifier une instance Metabase
Au-delà de la montée de version, cherchez des traces d’appels à l’endpoint vulnérable dans les journaux de votre reverse proxy. Exemple pour nginx au format de log par défaut :
# Appels à l'endpoint de réinitialisation, regroupés par adresse IP source
zgrep -h 'POST /api/session/reset_password' /var/log/nginx/access.log*
| awk '{print $1}' | sort | uniq -c | sort -rn- contrôlez les comptes administrateurs : créations, changements de droits, d’email ou de mot de passe inattendus ;
- relisez l’historique d’activité et de requêtes de Metabase, ainsi que les journaux de la base applicative et de l’entrepôt de données ;
- comme l’a fait Mathspace, révoquez les clés d’API et changez les identifiants des bases connectées (ici Snowflake et Cloud SQL).
La leçon vaut pour tous les outils internes exposés : un correctif ferme la porte, il ne chasse pas l’intrus déjà entré. Quand un avis signale une exploitation active, la mise à jour doit toujours être suivie d’une recherche de compromission.