Le 30 septembre 2026, l'ANSSI publiait le premier point de situation de l'opération REACTIV. Bilan : 99 violations de données signalées depuis le 1er août, dont 67 confirmées, neuf instances ministérielles affectées. Le vecteur commun : la CVE-2026-72898, une injection SQL dans Metabase, un outil d'analyse de données. Le correctif était disponible depuis le 6 août (source : bulletin de sécurité Metabase, 6 août 2026). Trois semaines s'étaient écoulées entre la publication du correctif et les premières compromissions. Votre organisation utilise-t-elle Metabase, Grafana, Redash ou Apache Superset ? La question n'est pas rhétorique.
Metabase, un outil que vos équipes data connaissent mieux que vos équipes sécurité
Metabase est un logiciel d'analyse de données en libre accès, déployé en quelques minutes sur n'importe quel serveur. Il permet de construire des tableaux de bord, d'interroger des bases de données et de partager des rapports sans écrire une ligne de code. C'est sa force. C'est aussi son problème de sécurité.
Dans la plupart des organisations, Metabase est déployé par une équipe data ou un service métier. Il ne figure pas dans les inventaires de la DSI. Il n'est pas couvert par le périmètre du SOC. Il n'est pas soumis aux mêmes contraintes de mise à jour que l'ERP ou le serveur de messagerie. Il se met à jour manuellement, en dehors des cycles de patch management standards.
Ce profil est partagé par toute une catégorie d'outils : les plateformes d'analyse, de visualisation et de reporting déployées en self-hosted par des équipes non-sécurité. Grafana, Redash, Apache Superset, Metabase : chacun accède directement aux bases de données de production. Chacun s'authentifie sous un compte de service. Aucun ne génère d'alerte quand un correctif critique est disponible.
Trois semaines d'exposition pour un correctif publié
La CVE-2026-72898 est une injection SQL dans les versions de Metabase antérieures à 0.50.18.3 (édition open-source) et 1.50.18.3 (édition Entreprise). Elle permet à un attaquant non authentifié d'exfiltrer des données depuis la base utilisée par l'application : identifiants, adresses de messagerie, mots de passe hachés, statistiques d'utilisation.
Le bulletin de sécurité Metabase date du 6 août 2026. L'attaque documentée dans le cadre de REACTIV a commencé en août 2026. Neuf instances ministérielles n'avaient pas déployé le correctif au moment de la compromission. Le bilan du 30 septembre fait état de 120 comptes compromis : 118 liés à l'ANSSI, 2 à la DINUM (source : premier point de situation REACTIV, ANSSI, 30 septembre 2026).
Le délai entre la disponibilité d'un correctif et son déploiement effectif n'est pas exceptionnel. L'ENISA, dans son Threat Landscape 2026, documente que 73 % des organisations victimes d'une intrusion disposaient d'un correctif applicable au moment de l'attaque (source : ENISA Threat Landscape 2026, septembre 2026). Le problème n'est pas la publication des correctifs. C'est l'absence de processus pour les appliquer sur tous les outils en production.
Pourquoi NIS2 ne distingue pas les outils « métier » des systèmes « critiques »
L'Article 21 de la directive NIS2 impose aux entités essentielles et importantes de mettre en place des mesures de gestion des vulnérabilités. Le texte ne fait aucune distinction entre les systèmes gérés par la DSI et ceux déployés par des équipes métier ou data. L'obligation couvre l'ensemble du système d'information.
Dans les faits, la plupart des programmes NIS2 auditent les systèmes inventoriés par la DSI. Metabase, Grafana ou Redash n'apparaissent pas dans le CMDB. Ils ne font pas l'objet d'un scan de vulnérabilité périodique. Ils ne reçoivent pas les bulletins de sécurité du CERT-FR, faute d'être connus du point de contact sécurité.
L'inventaire des composants logiciels sous NIS2 et DORA impose de documenter les composants en production. Cette exigence inclut les outils analytiques auto-hébergés. Connaître les composants que vous utilisez est une condition nécessaire. Elle ne suffit pas : il faut également un processus pour agir sur les CVE identifiées pour chacun de ces composants.
Un exemple concret : la chaîne d'exposition type
Une équipe data déploie Metabase sur un serveur interne en janvier 2026. Elle connecte l'outil à la base de données RH pour produire des tableaux de bord de suivi des effectifs. L'accès est sécurisé par un mot de passe. Metabase est accessible depuis le réseau interne uniquement.
En août 2026, la CVE-2026-72898 est publiée. L'équipe data n'a pas d'abonnement aux alertes de sécurité Metabase. La DSI n'a pas inventorié cet outil. Le CERT-FR publie un avis (CERTFR-2026-AVI-1274), mais personne ne fait le lien avec l'instance déployée.
Trois semaines plus tard, un attaquant ayant compromis un poste du réseau interne identifie l'instance Metabase par scan du réseau local. Il exploite la CVE-2026-72898 depuis l'intérieur. Il exfiltre les identifiants, les adresses de messagerie et les mots de passe hachés de plusieurs centaines de collaborateurs.
L'organisation apprend l'incident lors d'une alerte volumétrique sur son proxy de sortie. Elle doit notifier l'ANSSI dans les 24 heures. Elle doit notifier la CNIL sous 72 heures. Elle doit informer les personnes concernées. La cause : un outil déployé sans surveillance, un correctif non appliqué, une équipe non sensibilisée.
Trois mesures concrètes pour fermer cet angle mort
Inventorier les outils analytiques auto-hébergés. Metabase, Grafana, Redash, Apache Superset, Kibana, Tableau Server. Identifiez chaque instance, la version déployée, l'équipe responsable et les bases de données auxquelles elle est connectée. Cet inventaire doit être intégré à votre CMDB ou à votre registre de composants NIS2.
Abonner chaque instance aux alertes de sécurité de l'éditeur. Metabase publie ses bulletins de sécurité sur son dépôt GitHub et sur security.metabase.com. Grafana maintient un fil RSS de sécurité. Ces sources doivent être surveillées par l'équipe sécurité, pas seulement par les équipes data. Un bulletin critique doit déclencher une procédure de mise à jour dans un délai défini.
Définir un SLA de correction par niveau de criticité. Pour les CVE de score CVSS supérieur ou égal à 9.0, la fenêtre de déploiement du correctif doit être fixée dans votre politique de patch management. Cette politique doit nommer un responsable pour chaque catégorie d'outil, y compris les outils déployés hors DSI. Sans responsable nommé, aucun correctif critique ne sera appliqué dans les délais.
Ce que l'incident ANSSI/DINUM change pour vos programmes NIS2
L'incident Metabase ne concerne pas uniquement les ministères. Il concerne toute organisation qui utilise des outils analytiques auto-hébergés sans les intégrer à son programme de patch management. Le vecteur est banal. La conséquence est documentée : 120 comptes compromis, neuf instances affectées, une enquête ouverte.
Votre programme NIS2 couvre les systèmes que vous avez inventoriés. L'inventaire est la première obligation. Il ne s'arrête pas aux serveurs d'application et aux bases de données. Il inclut les outils que vos équipes ont déployés pour gagner du temps, sans passer par la DSI. Ces outils sont en production. Ils accèdent à vos données. Ils ont des vulnérabilités. Ils ont des correctifs. La question est de savoir si vous les connaissez avant que quelqu'un d'autre ne les découvre.