Metabase, CVE-2026-72898 and ANSSI: what a patch deployed too late reveals about your analytics tools

The Metabase patch had been available since 6 August. The attack that compromised 120 ANSSI and DINUM accounts began in August. Nine ministerial instances had not yet deployed the patch. CVE-2026-72898 illustrates an entire category of tools that NIS2 programmes do not yet cover: self-hosted analytics platforms, deployed outside the IT department and absent from inventories.

Terminal screen showing a list of software patches with CVE identifiers, severity scores and release dates

On 30 September 2026, France's national cybersecurity agency (ANSSI) published the first situation report of operation REACTIV. The findings: 99 data breaches reported since 1 August, 67 of them confirmed, and nine ministerial instances affected. The common vector: CVE-2026-72898, an SQL injection in Metabase, a data analysis tool. The patch had been available since 6 August (source: Metabase security bulletin, 6 August 2026). Three weeks had passed between the release of the patch and the first compromises. Does your organisation use Metabase, Grafana, Redash or Apache Superset? This is not a rhetorical question.

Metabase, a tool your data teams know better than your security teams

Metabase is open-source data analysis software, deployed in a few minutes on any server. It allows users to build dashboards, query databases and share reports without writing a line of code. That is its strength. It is also its security problem.

In most organisations, Metabase is deployed by a data team or a business department. It does not appear in the IT department's inventories. It is not covered by the scope of the SOC. It is not subject to the same update constraints as the ERP or the mail server. It is updated manually, outside standard patch management cycles.

This profile is shared by a whole category of tools: analytics, visualisation and reporting platforms deployed self-hosted by non-security teams. Grafana, Redash, Apache Superset, Metabase: each one has direct access to production databases. Each authenticates under a service account. None generates an alert when a critical patch becomes available.

Three weeks of exposure for a published patch

CVE-2026-72898 is an SQL injection affecting Metabase versions prior to 0.50.18.3 (open-source edition) and 1.50.18.3 (Enterprise edition). It allows an unauthenticated attacker to exfiltrate data from the database used by the application: credentials, email addresses, hashed passwords, usage statistics.

The Metabase security bulletin is dated 6 August 2026. The attack documented under REACTIV began in August 2026. Nine ministerial instances had not deployed the patch at the time of the compromise. The 30 September report records 120 compromised accounts: 118 linked to ANSSI, 2 to DINUM (source: first REACTIV situation report, ANSSI, 30 September 2026).

The delay between the availability of a patch and its actual deployment is not exceptional. In its Threat Landscape 2026, ENISA documents that 73% of organisations that suffered an intrusion had an applicable patch available at the time of the attack (source: ENISA Threat Landscape 2026, September 2026). The problem is not the publication of patches. It is the absence of a process to apply them across all production tools.

Why NIS2 does not distinguish 'business' tools from 'critical' systems

Article 21 of the NIS2 Directive requires essential and important entities to implement vulnerability handling measures. The text makes no distinction between systems managed by the IT department and those deployed by business or data teams. The obligation covers the entire information system.

In practice, most NIS2 programmes audit the systems inventoried by the IT department. Metabase, Grafana or Redash do not appear in the CMDB. They are not subject to periodic vulnerability scanning. They do not receive CERT-FR security bulletins, because the security point of contact is not aware of them.

The software component inventory under NIS2 and DORA requires documenting the components in production. This requirement includes self-hosted analytics tools. Knowing which components you use is a necessary condition. It is not sufficient: you also need a process to act on the CVEs identified for each of these components.

A concrete example: a typical exposure chain

A data team deploys Metabase on an internal server in January 2026. It connects the tool to the HR database to produce dashboards tracking headcount. Access is protected by a password. Metabase is reachable from the internal network only.

In August 2026, CVE-2026-72898 is published. The data team has not subscribed to Metabase security alerts. The IT department has not inventoried this tool. CERT-FR publishes an advisory (CERTFR-2026-AVI-1274), but nobody links it to the deployed instance.

Three weeks later, an attacker who has compromised a workstation on the internal network identifies the Metabase instance by scanning the local network. They exploit CVE-2026-72898 from inside the network. They exfiltrate the credentials, email addresses and hashed passwords of several hundred employees.

The organisation learns of the incident through a volume alert on its outbound proxy. It must notify ANSSI within 24 hours. It must notify the French data protection authority (CNIL) within 72 hours. It must inform the data subjects. The cause: a tool deployed without oversight, an unapplied patch, a team that was not made aware of the risk.

Three concrete measures to close this blind spot

Inventory self-hosted analytics tools. Metabase, Grafana, Redash, Apache Superset, Kibana, Tableau Server. Identify each instance, the version deployed, the responsible team and the databases it is connected to. This inventory must be integrated into your CMDB or your NIS2 component register.

Subscribe each instance to the vendor's security alerts. Metabase publishes its security bulletins on its GitHub repository and on security.metabase.com. Grafana maintains a security RSS feed. These sources must be monitored by the security team, not only by data teams. A critical bulletin must trigger an update procedure within a defined timeframe.

Define a remediation SLA by severity level. For CVEs with a CVSS score of 9.0 or higher, the deployment window for the patch must be set in your patch management policy. This policy must name an owner for each category of tool, including tools deployed outside the IT department. Without a named owner, no critical patch will be applied within the required timeframe.

What the ANSSI/DINUM incident changes for your NIS2 programmes

The Metabase incident does not concern ministries alone. It concerns any organisation that uses self-hosted analytics tools without including them in its patch management programme. The attack vector is mundane. The consequence is documented: 120 compromised accounts, nine affected instances, an open investigation.

Your NIS2 programme covers the systems you have inventoried. The inventory is the first obligation. It does not stop at application servers and databases. It includes the tools your teams have deployed to save time, without going through the IT department. These tools are in production. They access your data. They have vulnerabilities. They have patches. The question is whether you know about them before someone else discovers them.

Related engagement: Penetration testing

Request a call