ANSSI et DINUM : des instances Metabase compromises, révélées par le rapport REACTIV de l'ANSSI

Le 30 septembre 2026, le CERT-FR a publié le premier point de situation de l’opération REACTIV, le dispositif de réponse aux violations de données dans les services de l’État que le Premier ministre avait demandé à l’ANSSI de mettre en place le 1er septembre. Ce rapport reconnaît que deux acteurs centraux de la sécurité et du numérique de l’État ont eux-mêmes été touchés : le laboratoire d’innovation de l’ANSSI, dont 118 comptes d’utilisateurs de l’outil d’analyse Metabase ont été compromis, et la direction interministérielle du numérique (DINUM), dont deux instances Metabase, associées à ProConnect et à Nuage-Public, l’ont été également. Les dates d’intrusion ne sont communiquées ni pour l’une ni pour l’autre : le rapport indique seulement que l’ANSSI observe une exploitation massive de la vulnérabilité depuis le début du mois d’août 2026.

Il s’agit de deux compromissions distinctes, que relie la faille exploitée et non une plateforme partagée : le rapport ne précise pas le nombre d’instances touchées côté ANSSI, et ne dit pas si les deux instances de la DINUM figurent parmi les neuf instances ministérielles qu’il dénombre. Dans sa rubrique sur les vulnérabilités récurrentes, il décrit la CVE-2026-72898, une injection SQL exploitable sans authentification qui donne accès à la base de données de Metabase puis aux droits d’administrateur, corrigée depuis le 6 août et inscrite le 11 août au catalogue des vulnérabilités activement exploitées de la CISA. Les paragraphes consacrés à l’ANSSI et à la DINUM parlent plus sobrement d’une « vulnérabilité Metabase » : le rattachement à cette CVE est celui de la presse spécialisée, cohérent avec le calendrier mais non écrit cas par cas. L’incident s’inscrit donc dans la vague qui a déjà touché Scalingo, TeleCoop, Legalstart, GreenGo, Delicity et Shipup, et, faute de dates d’intrusion, on ne sait pas s’il a précédé ou suivi le correctif, ce qui n’ôte rien à la portée symbolique d’un incident survenu chez des organismes particulièrement informés de ce risque. Certains médias évoquent 120 comptes, un chiffre qui additionne à tort les 118 comptes de l’ANSSI et les deux instances de la DINUM. Cet incident est enfin distinct de la compromission de Tchap en juin 2026, causée par un compte usurpé et traitée dans une fiche séparée.

Côté ANSSI, les données concernées sont des statistiques d’utilisation, des identifiants, des adresses électroniques et des mots de passe hachés, dont le type de hachage n’est pas précisé : un mot de passe faible ou réutilisé peut parfois être retrouvé à partir de son empreinte. Côté DINUM, il s’agit d’informations administratives d’organismes publics (SIREN, SIRET, budgets, effectifs), de métadonnées de contributions à des projets open source et d’historiques de connexions anonymisés, que l’ANSSI juge déjà publics, sans dire quelle instance contenait quelles données. Les personnes réellement exposées sont donc surtout les titulaires des 118 comptes de l’ANSSI, dont la qualité d’utilisateur d’un laboratoire de cybersécurité rend crédibles des courriels piégés ciblés, tandis que les données de la DINUM concernent des organismes plutôt que des personnes.

Sur la réaction, l’ANSSI indique avoir mis à jour les instances vulnérables, renouvelé les mots de passe de tous les comptes et désactivé ceux inutilisés depuis plus de trois mois, tandis que la DINUM a corrigé les vulnérabilités, réinitialisé les secrets et supprimé les comptes créés par l’attaquant. Le Monde Informatique rapporte le 5 octobre, sans confirmation d’autres médias, que le parquet de Paris a ouvert une enquête sur l’incident de l’ANSSI. Dans les documents consultés, aucun communiqué propre de la DINUM, aucune notification à la CNIL ni aux personnes concernées et aucune revendication d’attaquant n’apparaissent : les faits viennent de l’ANSSI, qui précise que ses chiffres sont susceptibles d’évoluer.

Les utilisateurs du laboratoire d’innovation, en particulier les comptes externes, ont intérêt à changer tout mot de passe identique ou proche utilisé ailleurs, à activer la double authentification partout où elle existe et à se méfier des messages se réclamant de l’agence. Les organisations qui exploitent Metabase doivent recenser leurs instances, les mettre à jour, bloquer l’accès public au chemin /api/session/reset_password si la mise à jour est impossible, rechercher dans les journaux une requête POST sur ce chemin suivie d’une requête GET sur /api/user/current, puis renouveler les identifiants des bases connectées et les sessions actives en cas de doute.