- The Mess: Mathspace left a critical Metabase vulnerability unpatched while attackers were already inside the reporting system. The result was access to data belonging to more than 1 million students, parents and staff.
- The Damage: A reporting dashboard became a gateway into a database containing personal information on 1,079,819 people.
- The Fix: Patch Metabase immediately, investigate before and after the patch, and treat every Internet-facing Metabase instance as compromised until proven otherwise.
This is what a CVSS 10.0 SQL injection looks like when patch management fails.
Mathspace has disclosed a data breach affecting 1,079,819 students, staff, parents and guardians in Australia and New Zealand.
The attackers exploited a critical vulnerability in the company’s self-hosted Metabase installation, which Mathspace used as an internal reporting platform. The vulnerable instance provided administrative access without requiring a legitimate login.
And the timeline is brutal.
Metabase released its security fix on August 6.
Unauthorized access to Mathspace began on August 10.
Attackers downloaded data from the Australian reporting database on August 27.
Mathspace finally patched Metabase on August 29.
The company confirmed the compromise on September 3.
Twenty-three days separated the vendor’s disclosure from Mathspace’s patch.
The attackers needed four.
The vulnerability was already known
The vulnerability is CVE-2026-72898.
It is a remote, unauthenticated SQL injection in Metabase’s password-reset functionality.
The affected endpoint is:
/reset_password
An attacker can inject arbitrary SQL and obtain administrator access to the Metabase instance.
CVE data assigns the vulnerability CVSS 10.0 Critical with:
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
In other words:
- network reachable;
- low attack complexity;
- no authentication;
- no user interaction;
- high confidentiality impact;
- high integrity impact;
- high availability impact.
The vulnerability was added to CISA’s Known Exploited Vulnerabilities catalog on August 11. CISA classified exploitation as active and set a remediation deadline of August 14 for federal agencies.
This wasn’t a vulnerability waiting for someone to discover a working exploit.
Attackers were already using it.
Metabase knew something was wrong before the disclosure
Metabase’s own investigation makes the story even more interesting.
On August 3, a Metabase Cloud customer reported that an API key had been created outside normal working hours.
Metabase found an anomalous access pattern involving the same source IP creating API keys across two customer instances.
The company traced the activity back to a zero-day vulnerability that allowed an attacker to generate an active session.
Metabase patched its cloud infrastructure and released fixes for self-hosted installations on August 6.
The vendor later stated that fewer than 3% of Metabase Cloud customers were compromised before the vulnerability was patched, while some self-hosted and open-source deployments were also affected.
That last category is exactly where Mathspace ended up.
The vulnerable component was not the student platform
This detail makes the incident more interesting from an architectural perspective.
The attacker did not need to compromise Mathspace’s main education application.
They went after the reporting layer.
Metabase had access to an internal reporting database containing information about more than a million people.
Once the attacker obtained administrator access to Metabase, the reporting system became the bridge into the underlying data.
That is the classic danger of analytics infrastructure:
read-only-looking dashboards often have very powerful database connections behind them.
A dashboard may look harmless.
Its backend credentials may not be.
The attack timeline
The timeline published by Mathspace gives a remarkably clean picture:
August 6
Metabase publishes the security advisory and patched versions.
August 10
Mathspace’s Metabase instance experiences unauthorized access.
August 11
CVE-2026-72898 enters CISA KEV.
August 12
Metabase releases additional hardened versions addressing related issues.
August 27
Attackers download information from Mathspace’s Australian reporting database.
August 29
Mathspace upgrades its Metabase instance.
September 3
Historical log analysis confirms that unauthorized access occurred before the upgrade.
September 4
Authorities and relevant education organizations are notified.
September 6 onward
Affected individuals begin receiving notifications.
This is why patching alone wasn’t enough.
By August 29, the vulnerability was closed.
The data was already gone.
What was stolen?
Mathspace says the affected dataset contained information including:
- user ID;
- username;
- first and last name;
- email address;
- country;
- time zone;
- user type;
- email-verification status;
- account creation date;
- last login;
- last activity.
The company says academic records, learning activities, assessment results, password hashes, authentication tokens, SSO credentials and API credentials were not exposed.
That is good news.
It does not make the breach harmless.
A database containing names, email addresses, school-related identities and account metadata is extremely useful for targeted phishing.
Especially when the victims are students, parents and educators.
The reporting database was the real prize
This is the part security teams should pay attention to.
An attacker doesn’t necessarily need the primary production database.
Secondary systems often contain a copy.
Reporting databases.
Data warehouses.
BI platforms.
Analytics clusters.
ETL staging systems.
Export buckets.
Debug databases.
They frequently contain large amounts of production information while receiving less security attention.
Mathspace’s incident is a textbook demonstration.
The vulnerable application was a reporting tool.
The valuable asset was the database connected to it.
The attack path therefore looked like:
Internet
↓
Metabase /reset_password
↓
CVE-2026-72898
↓
Unauthenticated SQL injection
↓
Metabase administrator
↓
Connected reporting database
↓
1,079,819 affected people
There was no need to compromise every user account individually.
One management application was enough.
Metabase’s postmortem exposes the deeper problem
Metabase later explained that the original zero-day was not simply one badly written line of SQL.
The attack chain crossed four layers of the codebase.
The password-reset endpoint accepted additional parameters because its schema validation wasn’t closed.
A previous authentication refactor changed how request parameters were passed through.
Those behaviors interacted with the database layer and ultimately enabled an attacker to manipulate sensitive state.
That is precisely the sort of vulnerability that automated code analysis increasingly finds.
Not:
“This function has a buffer overflow.”
But:
“These four individually reasonable pieces of code combine into an authentication bypass.”
Metabase subsequently hardened multiple layers of the platform, including schema validation, SQL generation, permission checks, session handling, SSRF protections and database impersonation mechanisms.
The patch notification failed
Mathspace’s own admission is probably the most important part of the entire incident.
The company said its existing vulnerability-notification process did not identify and escalate the Metabase advisory for action.
The instance therefore remained vulnerable after the vendor had already released the fix.
Worse, after updating on August 29, Mathspace did not immediately perform the additional compromise checks recommended for potentially affected systems.
The breach was confirmed only after historical logs were reviewed on September 3.
This creates two separate failures:
Patch management failure
The vulnerability wasn’t patched quickly enough.
Incident-response failure
The team didn’t immediately determine whether exploitation had already occurred.
The second failure matters just as much as the first.
Patching a compromised server does not clean it
This should be printed above every vulnerability-management dashboard.
If exploitation started on August 10 and the server was patched on August 29, the patch closes the vulnerability.
It does not erase:
- stolen credentials;
- created sessions;
- modified configuration;
- attacker-created accounts;
- database queries;
- exported data;
- persistence;
- previously downloaded files.
Metabase itself recommended compromise checks following exploitation.
Its security guidance tells self-hosted administrators to inspect API keys, administrator accounts, sessions, database credentials, query history and connected database logs.
That’s the correct response pattern.
Patch first.
But don’t stop there.
What Metabase administrators should do now
If you run a self-hosted Metabase instance, start with the version.
CVE-2026-72898 affects releases before the corresponding patched builds, including:
- 0.58.x before 0.58.24;
- 0.59.x before 0.59.21;
- 0.60.x before 0.60.17;
- 0.61.x before 0.61.11;
- 0.62.x before 0.62.9;
- 0.63.x before 0.63.5.
The CVE record also covers corresponding 1.x enterprise releases.
Then investigate.
Look for suspicious calls involving:
POST /api/session/reset_password
Metabase identified a characteristic attack pattern involving a failed password-reset request followed by a successful request to:
GET /api/user/current
The vendor recommends treating this pattern as a potential compromise indicator.
Also review:
- active sessions;
- API keys;
- administrator accounts;
- database credentials;
- query history;
- Metabase audit activity;
- reverse-proxy logs;
- firewall logs;
- database logs.
If compromise is suspected, rotate credentials for connected databases.
The dangerous assumption
A lot of organizations think about Metabase like this:
“It’s only a dashboard.”
That’s the wrong mental model.
Metabase can connect to databases containing:
- customer data;
- financial information;
- employee records;
- business intelligence;
- authentication-related data;
- production metrics.
The application itself may have relatively little sensitive data.
Its connections can have enormous value.
Compromise the analytics layer and you can potentially inherit the permissions of every database connection it is allowed to use.
The supply-chain lesson is not about Metabase
Mathspace’s breach is ultimately a story about vulnerability management.
The vendor released the fix.
The vulnerability entered CISA KEV.
Attackers began exploiting it.
The affected organization didn’t patch.
Data left the environment.
That sequence is painfully ordinary.
The software was not some obscure abandoned project.
The vulnerability wasn’t unknown when Mathspace was compromised.
The warning existed.
The patch existed.
The exploit existed.
The missing component was operational speed.
Bugstoday’s take
This is why a CVSS 10.0 doesn’t mean much if the patch sits in a ticket queue.
Mathspace had four days between the Metabase patch and the beginning of unauthorized access.
The company then had another nineteen days before applying the fix.
By the time Metabase was finally updated, the attacker had already downloaded data belonging to more than a million people.
The most dangerous sentence in this story isn’t:
“Metabase had a critical SQL injection.”
It’s:
“Our vulnerability-notification process did not identify and escalate the advisory.”
That’s how breaches happen in the real world.
Not because nobody knew about the vulnerability.
Because somebody knew — and the patch didn’t reach production fast enough.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- Mathspace — Data breach investigation and affected users
- Metabase — August 2026 security vulnerability postmortem
- Metabase — Security update and remediation guidance
- CVE.org / CISA CNA — CVE-2026-72898
- CISA — Known Exploited Vulnerabilities Catalog
- Metabase — Security advisories
