Vulnerability Management Process: What the Mathspace Breach Shows

On 6 August 2026 Metabase published a critical security advisory and patched versions. On 10 August an attacker was inside Mathspace’s self-hosted Metabase instance. On 27 August they downloaded a database. On 29 August Mathspace applied the patch. On 3 September, reviewing historical access logs, Mathspace worked out what had happened.

1,079,819 people in Australia and New Zealand were affected: students, parents and guardians, teachers, and Mathspace’s own staff.

The coverage has settled on “unpatched software”, which is true and is not the finding. Twenty-three days passed between a public advisory and a patch, and the reason is written down in Mathspace’s own disclosure in a sentence most companies would have fought to keep out of it.

Our existing vulnerability-notification process did not identify and escalate that advisory for action.

Tilt-shift miniature of a darkened open-plan office at night, one desk lit by two monitors showing a wall of server log lines and an email client with a single unread message, the chair pushed back and empty, and a wall calendar with weeks crossed off in red — The advisory was public on 6 August. The intrusion began on the 10th. The patch went on on the 29th.

That is not a patching failure. It is a failure one step earlier, in the part of the system that is supposed to notice that a patch exists. Verifying that step is a critical part of an information security management system, and it is the subject of this article.

This was not a quiet advisory

It matters how loud the 6 August notice was, because it sets the standard against which the 23 days are judged.

The vulnerability is CVE-2026-72898, an unauthenticated SQL injection reachable through the password-reset endpoint, carrying a CVSS score of 10.0. No login, no user interaction, low complexity, administrator access to the application database. It affected self-hosted Metabase from x.58.0 through x.63.4.

And Metabase did not publish it as routine housekeeping. They published it because it had already been used against them, as a zero-day, on Metabase Cloud. By 10 August, the day the intrusion into Mathspace began, exploitation in the wild was being reported publicly.

So the signal was as strong as a signal gets: maximum severity, vendor-confirmed active exploitation, patched versions available the same day. If a vulnerability-notification process does not catch that one, it is not calibrated badly. It is not running.

Update, 24 September 2026: the window is getting shorter. On 7 September Adobe disclosed and patched CVE-2026-75650, a critical remote code execution flaw in Adobe Commerce and Magento Open Source. By 9 September Adobe had confirmed it was being exploited against merchants, and that evening ASD’s ACSC issued a critical alert noting a substantial number of potentially vulnerable instances in Australia. Mathspace took 23 days to act on its advisory. Adobe Commerce merchants had two days between the patch and confirmed exploitation. A process that waits for the next monthly patch cycle fails on a case like this by design, so the route from advisory to action needs a severity trigger that jumps the queue. And if a third party runs your online store, the ACSC’s own advice is to confirm with them that systems are patched and monitored, which is the question we set out in our N-able N-central article.

Receiving the advisory is a control

Ask most organisations how they manage vulnerabilities and you will be told about patching windows, maintenance schedules and who does the updates. All of that is downstream. It assumes somebody already knows there is something to patch.

ISO/IEC 27001:2022 splits this into two controls, and the split is the useful part.

Annex A 5.7, threat intelligence, is about collecting and analysing information on threats so that you know what is coming. In a small business this is not a threat-intelligence platform. It is a list of every product in your stack and a named subscription to each vendor’s security advisories, arriving somewhere a human reads.

Annex A 8.8, management of technical vulnerabilities, is about what happens next: obtaining information about vulnerabilities in the systems you use, evaluating your exposure, and taking action.

Read as a pair, they describe a route: advisory published, advisory received, someone assesses whether it applies to us, someone is accountable for acting, with a deadline set by severity. Break any link and the chain produces nothing, no matter how good the patching window is.

Four questions that test the chain rather than the intention.

Which mailbox do vendor advisories arrive in, and who reads it? If the answer is a personal inbox, the control has a single point of failure who takes annual leave.
Is every product on the asset register subscribed? Not the obvious ones. All of them, including the internal tools nobody thinks of as software the business depends on.
What is the maximum time between a critical advisory and action? A number, written down, that someone can be held to.
How would you know if the chain silently stopped working? This is the hardest one. An advisory process that has quietly failed looks exactly like a quiet month.

That last question is the one that catches most organisations. Mathspace did not receive a series of advisories and ignore them. The advisory never reached anyone who could act on it, and nothing in the business was designed to notice the absence.

Organisations with many sites have a second link to test: the instruction going out is not the same as the patch going on. Victoria’s Department of Education sent a patch directive to every school technician six and a half hours after ASD’s alert, had no way to confirm schools acted on it, and lost student data through one school that had not. We set out that case in the patch directive not every school applied.

Patching is not the end of the incident

The second admission in the disclosure is the one that turned a bad month into a breach affecting a million people.

At the time of updating, we did not complete the additional compromise checks recommended for potentially affected systems.

Mathspace patched on 29 August. The data had already gone on 27 August. Patching closed the door on an empty room, and because the recommended post-patch compromise checks were not done, nobody looked at what had happened while the door was open. The breach was confirmed five days later, on 3 September, from access logs the company already held.

This is the difference between two questions that sound similar and are not:

Are we still vulnerable? Answered by patching.
Were we already compromised? Answered only by looking.

When a critical vulnerability has been public and exploited for three weeks, the second question is the one that matters, and the answer lives in your logs. Annex A 8.15, logging, and 8.16, monitoring activities, are what make it answerable. Mathspace had the logs. What was missing was the step that says: after patching a system that was exposed, go and read them.

Worth being precise about where this sits. Incident management under Annex A 5.24 to 5.26 should have started on the day the exposure was discovered, not on the day the export was found. “We were reachable for 23 days by an actively exploited critical vulnerability” is itself an information security event that needs assessing and deciding on. Treating the patch as the closure is how three weeks of unread logs become somebody else’s problem.

Update, 28 September 2026: when the exploit comes before the patch. ASD’s ACSC has issued a critical alert on eight newly disclosed vulnerabilities in Citrix NetScaler ADC and NetScaler Gateway, the remote access appliances many organisations put at the edge of their network. At least two, CVE-2026-88771 and CVE-2026-88772, were being exploited around the world before a patch existed, and the first allows an unauthenticated attacker to run commands on every configuration of the device. At the time, ASD had not yet received reports of confirmed exploitation in Australia. The advice goes further than “patch”: review the conditions each vulnerability needs, and check device logs for signs of the attacks those conditions allow. That is this section’s point in its sharpest form. When exploitation starts before the fix, no patching window, however fast, answers the question “were we already compromised?” Only the logs do. If your NetScaler is managed by an IT provider, ask them the question directly: which version, when it was patched, and what the log review found.

Update, 2 October 2026: it has now happened here. ASD’s ACSC has updated the alert. Since first publishing it on 28 September, the ACSC has received reports from Australian organisations confirming exploitation, and it recommends reviewing for evidence of compromise since at least 4 September, more than three weeks before the alert. Citrix has made indicators of compromise available through NetScaler Console. That date is the lesson. An organisation that patched the day the alert landed may still have been open for more than three weeks beforehand, and a patch does nothing about anyone who got in during that time. If you run a NetScaler, treat that exposure window as an information security event to assess under Annex A 5.25, check the device against Citrix’s indicators, and read the logs back to 4 September.

The reporting tool held a million records

There is a third finding here, and it is the one most likely to apply to your business.

The compromised system was Metabase, a business intelligence tool used for internal reporting. Not the product. Not the customer-facing platform. The dashboard the team uses to answer questions about the business.

It held, or could reach, personal information on more than a million people. The exported fields were user ID, username, first name, last name, email address, country, time zone, user type, email-verification status, last-active date, last-login date and date joined. No passwords, no authentication tokens, no SSO credentials, no academic records.

Mathspace were careful to correct their own earlier account of this, and the correction is instructive:

This is more information than names and email addresses alone. Our earlier communications did not describe the account details fully.

The audit question is whether that system was ever treated as an asset holding personal information at all. Reporting and analytics tools accumulate copies of production data by design, and they are routinely classified as internal tooling rather than as systems holding customer records. We have written about the same failure from a different angle in the assets nobody put on the register.

A practical test: take your asset register and mark every system that can read production data. Then ask which of those you would have said “holds customer information” about without looking. The gap between the two lists is the exposure.

What Mathspace did well, which is worth saying

It is easy to write this kind of article as a pile-on. That would be both unfair and less useful, because the reason we can analyse this case at all is that the company chose to publish the root cause.

Most breach notifications say an unauthorised third party accessed systems and the matter is being investigated. Mathspace named two specific process failures, said they are investigating why each happened, corrected their own earlier under-description of the data, published the exact number of people affected rather than a rounded one, and committed to publishing what changes come out of the post-incident review.

They also contained it properly once they knew: the reporting system taken offline, API keys revoked, database accounts disabled across both environments, credentials rotated, and the application database and access logs preserved for investigation.

That is what a functioning incident response looks like, arriving late. The failure was upstream, in the two processes they have named. The response after 3 September is closer to the standard than most.

The notification timeline, and what the law asks

Mathspace confirmed the breach on 3 September and reported it on 4 September to the OAIC, the ACSC, New Zealand’s Office of the Privacy Commissioner and New Zealand’s National Cyber Security Centre, along with Australian state and territory education departments. Schools were told from 4 September and individuals from 6 September.

Today, the notifiable data breach scheme gives you up to 30 days to carry out a reasonable and expeditious assessment of a suspected breach, and once you have reasonable grounds to believe there has been an eligible data breach you must notify the Commissioner and affected individuals as soon as practicable. There is no fixed-hour deadline in force.

That is being added to. The exposure draft released on 31 August 2026 would require a statement to the Commissioner within 72 hours of forming reasonable grounds to believe an eligible data breach has occurred. The 30-day assessment window for suspected breaches is retained, so it is a second clock rather than a replacement, and it starts at the moment of belief rather than the moment of suspicion. Consultation closed on 18 September 2026. It is not law yet, and the government has said it intends to introduce the bill before the end of 2026. We have set out what it would ask of you in what your data breach response plan has to prove.

Measured against the proposed rule, Mathspace clears it comfortably. Belief formed on 3 September, regulators notified on 4 September. One day, against a proposed 72 hours. If you want a worked example of what the new clock would feel like in practice, this is the first clean one.

Which is the point worth taking away. The pressure in this timeline was never at the notification end. It is in the 24 days between the intrusion starting and anyone knowing it had. No notification deadline, existing or proposed, does anything about that stretch. Only the two controls at the top of this article do.

The audit you can run this week

This is a clause 9.2 internal audit that takes an afternoon and produces a real finding.

Take the last three critical advisories for products in your stack. Not ones you were told about. Go to the vendors’ security pages and find them yourself. For each one, trace it forward:

Did it arrive anywhere in your organisation? Show the email, the ticket or the feed entry.
Who assessed whether it applied to you, and when?
What date was it actioned, and how long did that take from publication?
If the vendor recommended compromise checks after patching, were they done, and what did they find?

Any advisory you cannot trace to step one is the Mathspace finding, sitting in your business today. It is not evidence that nothing has happened. It is evidence that you would not know.

Where Streamline fits

Vulnerability management is one of the areas where a certified system and a real one come apart most easily. The documented procedure describes a route from advisory to action. Whether anything travels that route is a different question, and it is answered by sampling, not by reading the procedure.

Streamline builds and maintains ISO 27001 information security management systems for Australian organisations, and runs the independent internal audits that test whether controls like 5.7 and 8.8 are doing anything. You deal directly with a practising ISO Lead Auditor, so the sampling is the sampling a certification auditor would run. A gap analysis is the usual starting point, and ISO mentoring is the route where your own team does the building.

Run the three-advisory test first. Get in touch if you cannot trace all three.

Sources

General guidance only. This article is general information, not legal, financial, safety or compliance advice, and it does not take account of your specific circumstances. Streamline ISO Consultants are ISO management-system consultants, not lawyers or licensed advisers. Standards, laws and regulator guidance change, and details were correct only at the time of writing. Always seek professional advice before acting. See our full Disclaimer.