Sixteen Days From KEV to Exfiltration - What the Mathspace Breach Says About Internal Tooling

A BI tool is pre-joined access to everything

Business intelligence software exists to answer questions across all of your data at once. To do that it holds standing credentials to the databases that matter, and it holds them in a form designed for convenient querying rather than least privilege. The whole value proposition is that somebody in operations can ask a question spanning four systems without filing a ticket.

State that as a control and it reads badly. A single web application, frequently deployed by a data team rather than an infrastructure team, holds live credentials to your production datastores and offers a query interface over them. Compromise it and you do not need to move laterally, escalate, or find the data. The tool has already found the data for you. That is what makes this class of software worth attacking, and it is why "it's only an internal reporting tool" is precisely the wrong instinct.

What actually happened

Every date below is from either the vendor's advisory, the CISA KEV catalog, or the affected organisation's own public statement. Nothing here is inferred.

Twenty-three days from a patch being available to it being applied. Sixteen days from a government catalogue saying this is being exploited right now to the data leaving. The attacker did not need a zero-day, an insider, or patience beyond three weeks.

What the flaw actually is

The CVE record is assigned by CISA rather than the vendor, which is worth noticing on its own: it signals the coordination path this took.

Read the vectors rather than the number. PR:N and UI:N mean no credentials and no user to trick. AC:L means no special conditions. Under v3.1, S:C - scope changed - is why this reaches 10.0 rather than 9.8: the impact does not stop at the vulnerable component. That is the CVSS specification describing, in advance, exactly what happened here. The injection is in Metabase; the loss is in the database Metabase was pointed at.

Note also that six release branches were affected. Any inventory that tracked only "is Metabase installed" without tracking the build would not have produced an answer.

The failure was inventory, not patch speed

The obvious reading is that twenty-three days is too slow. True, but not the useful lesson, because almost nobody consciously decides to leave a known-exploited internet-facing critical unpatched for three weeks. What actually happens is that the clock never starts, because nothing connects "Metabase published an advisory" to "we run that, on the internet, against production data."

Three questions decide whether you are in the same position. They are inventory questions, not patching questions:

• Does an authoritative list exist of every internally-built or self-hosted application you run, including the ones a data or analytics team stood up without a ticket?
• For each, does the list record whether it is reachable from the internet, and what it is credentialed to reach?
• When a vendor for anything on that list publishes a critical advisory, who finds out, and how long does that take?

If the third question has no named answer, patch windows are aspirational. The affected organisation here applied the update on 29 August after "a separate, later notice" brought it to their attention - that phrasing, from their own disclosure, describes the notification gap precisely.

Where the Essential Eight fits

Patch applications is the first of the Essential Eight, and the maturity model sets defined maximum windows for patching internet-facing services, with a much shorter window where a working exploit exists or the vulnerability is being actively exploited. Both of those conditions were publicly true here on 6 August, before anyone was compromised, and were restated by CISA on 11 August.

Check the current wording of the maturity model against your own target level rather than trusting a number quoted in an article, including this one. The point that does not depend on the specific figure: the Essential Eight also requires an asset discovery capability, and that control is doing the real work here. A patch window you cannot start is not a patch window.

Detection

One Sigma rule and one hunt. The rule is in sigma-pack; convert with sigma-cli.

1. SQL metacharacters against the reset endpoint

The vendor's interim workaround is to block /api/session/reset_password outright. That makes the endpoint a good detection anchor: on a patched and hardened instance, traffic there is already anomalous.

title: Metabase Password Reset SQL Injection Attempt
id: fbeecaf9-c9de-4071-b9c6-3576b195e679
status: experimental
description: >
    A request to Metabase's unauthenticated password-reset endpoint carrying
    SQL metacharacters. CVE-2026-72898 is an unauthenticated SQL injection in
    /api/session/reset_password that yields administrator access to the
    Metabase instance, and through it every database connection that instance
    holds.
references:
    - https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf
    - https://www.cve.org/CVERecord?id=CVE-2026-72898
author: UMBRASEC
date: 2026/09/17
tags:
    - attack.initial_access
    - attack.t1190
logsource:
    category: webserver
detection:
    endpoint:
        cs-uri-stem|contains: '/api/session/reset_password'
    sqli_markers:
        cs-uri-query|contains:
            - ''''
            - ' or '
            - ' and '
            - 'union'
            - 'select'
            - 'sleep('
            - 'pg_sleep'
            - '--'
            - '/*'
            - ';'
    condition: endpoint and sqli_markers
level: high

Be clear about what this does not do. Webserver-category logs record the request line. An exploit that carries its payload in the POST body will not match, and you should assume a competent one does. This rule catches scanners, opportunistic spray, and the naive case; it is a tripwire, not a guarantee. If you have a WAF or proxy that captures request bodies, that is where the authoritative version of this detection lives.

2. Hunt: the shape of the endpoint's traffic

Password reset is a rare, human-paced action. Exploitation of a blind or error-based injection is neither. Over your proxy or web logs for the Metabase host, group requests to /api/session/reset_password by source address per hour and look for any source responsible for more requests than your users plausibly generate in a day. Ten resets from one address in ten minutes is not a forgetful employee.

Pair that with the egress side, which is the signal that mattered on 27 August. A BI host has a characteristic traffic profile: substantial inbound queries, modest outbound responses to internal clients. Bulk extraction inverts it. If you baseline one thing on that host, baseline outbound volume, and alert on a multiple of the daily norm rather than an absolute threshold.

ATT&CK

KEV is a trigger, not a newsletter

The single highest-value date in the timeline is 11 August. CISA's Known Exploited Vulnerabilities catalog is a short, curated list of things confirmed to be under active exploitation. It is far smaller than a CVE feed and far more actionable, and it is free. Sixteen days of warning sat in a public JSON file.

We publish kev-watch for this: a zero-dependency Python script that reads the catalog and reports newly-added CVEs matching products you care about. No install, no account, no packages.

python3 kev_watch.py --watch metabase postgres nginx

Run against the catalog on 11 August, a watch list containing metabase would have produced a hit that day. The tool is not the point - a cron job and grep over the same feed would have done it. The point is that the trigger has to be automatic and pointed at a list of what you actually run. A human subscribing to a mailing list is the control that failed here.

Credit where it is due

The disclosure itself is good, and saying so costs nothing. The public statement gives a dated timeline, an exact affected count of 1,079,819, the specific software and that it was self-hosted, an itemised list of exposed fields - user ID, username, first and last name, email address, country, time zone, user type, email-verification status, last-active date, last-login date, date joined - and an explicit list of what was not taken: no academic records, results or assessments, no password hashes, no authentication tokens, no SSO credentials, no API credentials. It names the regulators notified: the OAIC and ACSC in Australia, the Privacy Commissioner and NCSC in New Zealand.

That is more precision than most breach notifications contain, and it is the reason this article can be written from primary sources rather than speculation. An organisation that tells you the field list is an organisation you can actually assess. Compare it to the "an unauthorised third party may have accessed certain information" template and the difference is not cosmetic - one lets affected people make decisions, the other does not.

What to do this week

1. Answer the Metabase question directly. Do you run it, at what build, and is it reachable from the internet? If yes to the first and you cannot immediately answer the other two, that is your finding.
2. Patch to 58.24 / 59.21 / 60.17 / 61.11 / 62.9 / 63.5 and block /api/session/reset_password at the proxy in the meantime.
3. If you were running an affected build while exposed, assume admin access. Revoke sessions, audit API keys and administrator accounts, rotate every database credential the instance held, and review access logs. That is the vendor's guidance, not ours.
4. Inventory the rest. Every self-hosted internal tool, what it is credentialed to reach, and whether it is internet-facing. BI tools, wikis, dashboards, admin panels, CI runners.
5. Put KEV on a trigger against that inventory, and give the resulting alert a named owner.
6. Baseline outbound volume from hosts that hold credentials to bulk data.

Honest limitations

We have no visibility into the intrusion beyond what has been published, and this article does not speculate about it. The initial access vector is stated by the affected organisation; the sequence between 10 and 27 August is not public, and we have not invented one. We have not tested the exploit, and no exploit details appear here beyond the endpoint the vendor itself published in its workaround. The Sigma rule is experimental and has not been validated against a real exploitation attempt - treat it as a starting point, tune it against your own logs, and read the false-positive notes in the file before alerting on it.

On the Essential Eight timeframes, check the current maturity model rather than any number quoted second-hand. The argument in this article does not depend on the specific figure.

References

• Metabase - GHSA-vwf4-m7j8-wcjf, SQL injection using an unauthenticated endpoint leading to admin access
• MITRE - CVE-2026-72898
• NVD - CVE-2026-72898
• CISA - Known Exploited Vulnerabilities catalog
• Mathspace - Data breach: what happened and what affected users should know
• MITRE - CWE-89
• MITRE ATT&CK - T1190
• MITRE ATT&CK - T1213.006
• MITRE ATT&CK - T1567
• FIRST - CVSS v3.1 spec
• FIRST - CVSS v4.0 spec
• ASD's ACSC - Essential Eight
• OAIC - Notifiable Data Breaches scheme