Le 7 septembre 2026, la fuite de données de Mathspace a été rendue publique après la compromission d’un système de reporting interne. L’éditeur australien de soutien scolaire en mathématiques a confirmé que 1 079 819 personnes en Australie et en Nouvelle-Zélande étaient concernées : des élèves, des parents ou responsables, des enseignants et des membres du personnel Mathspace.
L’incident ne correspond pas à une fuite de résultats scolaires ou de mots de passe. Il montre en revanche comment un outil d’analyse interne peut concentrer des informations éducatives et des métadonnées de comptes, puis rendre les messages d’hameçonnage plus crédibles. La chronologie et le périmètre ci-dessous suivent les informations publiées par Mathspace et corroborées par la presse australienne.
Ce que Mathspace a confirmé
Mathspace indique que des parties non autorisées ont accédé à une installation auto-hébergée de Metabase utilisée pour le reporting interne. L’accès a commencé au plus tôt le 10 août 2026, selon l’analyse des journaux, et des informations ont été téléchargées depuis la base de reporting australienne le 27 août. L’entreprise dit avoir confirmé la compromission le 3 septembre, puis avoir commencé à prévenir ses écoles le 4 septembre et les personnes concernées à partir du 6 septembre.
Le point d’entrée est décrit comme une vulnérabilité de sécurité de l’installation Metabase qui a permis d’obtenir des privilèges d’administrateur sans connexion légitime. Mathspace explique que son processus de notification des vulnérabilités n’a pas fait remonter l’avis critique publié le 6 août ; son instance a été mise à jour le 29 août. L’entreprise enquête encore sur cette défaillance de processus et sur les contrôles de compromission qui n’ont pas été menés au moment de la mise à jour.
Metabase a ensuite expliqué publiquement la vulnérabilité d’août et ses correctifs. Cette description éclaire le risque du logiciel, mais elle ne permet pas d’affirmer quel chemin technique exact a été utilisé contre Mathspace au-delà de l’accès administrateur décrit par l’éditeur.
Un outil de reporting au centre de l’incident
Metabase n’était pas présenté comme la plateforme de cours de Mathspace, mais comme un outil interne de reporting connecté à des données de l’organisation. Sa compromission a donc créé un point d’accès à une copie analytique de données provenant de plusieurs catégories d’utilisateurs, sans que l’attaquant ait besoin de prendre le contrôle des comptes élèves un par un.
Mathspace a retiré le système compromis du réseau le 3 septembre, révoqué ses clés API, désactivé les comptes d’accès aux bases Metabase dans ses environnements Snowflake australien et américain, et changé les mots de passe des bases Cloud SQL utilisées par Metabase. Ces mesures contiennent l’accès au système de reporting ; elles ne transforment pas pour autant les données déjà téléchargées en données récupérées.
Quel périmètre de données et quelles inconnues
Le nombre confirmé est de 1 079 819 personnes, toutes situées en Australie ou en Nouvelle-Zélande. Les champs exportés pouvaient inclure un identifiant utilisateur, un nom d’utilisateur, les prénom et nom, l’adresse e-mail, le pays, le fuseau horaire, le type d’utilisateur, le statut de vérification de l’adresse, la dernière activité, la dernière connexion et la date de création du compte. Mathspace précise que chaque personne ne disposait pas nécessairement de tous ces champs.
L’éditeur affirme que les dossiers scolaires, les activités d’apprentissage, les résultats, les évaluations, les mots de passe et leurs condensats, les jetons d’authentification, les identifiants SSO et les identifiants API n’ont pas été exposés. Les exports ne contenaient pas non plus de liaison directe entre un compte et son école ; une adresse e-mail appartenant à un domaine identifiable peut toutefois donner un contexte supplémentaire.
Mathspace dit ne disposer d’aucune preuve, à ce stade, d’une publication, d’une vente ou d’une utilisation abusive des données, et ne connaît pas l’identité de l’attaquant. Ce sont des éléments d’enquête en cours, pas une garantie que les données téléchargées ne seront jamais utilisées.
Ce que les personnes concernées peuvent faire
Le risque immédiat est surtout celui d’une usurpation convaincante. Un message peut reprendre un nom, une adresse e-mail, une référence à une école ou la date de l’incident sans être envoyé par Mathspace. Les élèves doivent demander l’aide d’un parent, d’un responsable ou d’un enseignant en cas de doute.
Pour tous les publics concernés :
- vérifiez une notification en ouvrant vous-même le site officiel ou en utilisant une adresse connue ; ne suivez pas un lien fourni par un message inattendu ;
- ne transmettez jamais de mot de passe, de code de vérification ou de document en réponse à une demande urgente ;
- remplacez les mots de passe réutilisés sur d’autres services, en commençant par la messagerie et les comptes professionnels ;
- signalez les messages suspects ou les activités inhabituelles à data-breach-response@mathspace.co, après avoir vérifié l’adresse par une source indépendante.
Mathspace ne demande pas de réinitialisation générale du mot de passe Mathspace selon sa communication actuelle. Cette consigne n’annule pas la rotation d’un secret réutilisé ailleurs ni une modification ciblée en cas d’activité suspecte.
Ce que les écoles et les éditeurs doivent revoir
Les écoles peuvent demander à Mathspace le nombre de personnes concernées et les détails des enregistrements associés à leur établissement. Les échanges individuels doivent être organisés par un canal sécurisé, plutôt que par une pièce jointe ou un tableur envoyé à plusieurs destinataires.
Pour les équipes qui exploitent un outil de reporting, le cas Mathspace impose trois vérifications concrètes : les alertes de sécurité doivent parvenir à un responsable qui peut décider et suivre une mise à jour ; une mise à jour d’un composant exposé doit être suivie de contrôles de compromission adaptés ; enfin, les comptes de service, clés API et accès aux bases doivent pouvoir être révoqués séparément et rapidement.
La question n’est pas de supprimer tout reporting. Elle consiste à limiter les colonnes copiées dans les vues analytiques, séparer les environnements et contrôler qui peut exporter. Un outil interne peut devenir une copie centrale de données éducatives sans avoir été conçu comme un système de dossiers scolaires.
Le lien avec Soclyde
Soclyde n’a pas protégé Mathspace et ne peut pas réparer la compromission de Metabase. Son utilité se situe dans la gestion des secrets autour de ce type d’architecture : générer un secret unique pour chaque compte d’administration, clé API ou base de données, le conserver dans un coffre chiffré local-first et réduire les copies dans les documents, tableurs et conversations.
Cette discipline ne remplace ni la correction de Metabase, ni la segmentation des bases, ni les journaux d’accès. Elle rend toutefois une révocation plus praticable lorsqu’un outil de reporting ou un compte de service doit être isolé. Pour structurer cette démarche, consultez le guide du générateur de mots de passe sécurisé ou contactez Soclyde.
À retenir
La fuite Mathspace est confirmée : un système Metabase de reporting interne a été compromis et les données de comptes de 1 079 819 personnes en Australie et en Nouvelle-Zélande ont été téléchargées. Les noms, e-mails et métadonnées de compte peuvent alimenter des tentatives d’usurpation, même si Mathspace indique que les résultats scolaires, les mots de passe et les jetons d’authentification n’ont pas été exposés.
Les bons réflexes sont de vérifier les notifications depuis une source indépendante, de refuser toute demande de code et de supprimer la réutilisation des mots de passe. Pour les organisations, l’incident rappelle que le reporting doit être traité comme une surface de données sensible : inventaire, privilèges minimaux, correctifs suivis, exports limités et secrets révocables.
