The part of the Mathspace data breach disclosure that caught my attention was the gap between installing an update and checking what had happened before it.
It is quite easy to imagine the conversation in a smaller business. A security warning arrives. Someone updates the affected software. The website still works. The support ticket gets closed.
Everyone gets on with their day.
There is a question missing from that conversation. Primarily, did anybody use the vulnerability while it was still there?
What Mathspace Has Disclosed
In its disclosure updated on 8 September 2026, Mathspace says attackers exploited its Metabase reporting installation. It identified 1,079,819 affected people across Australia and New Zealand conprising students, parents or guardians, teachers and staff.
Downloaded records contained varying combinations of names, email addresses, usernames, internal IDs, country, account type, verification status and activity dates. Customer passwords, SSO tokens and other customer authentication credentials were not exposed. Mathspace reported no evidence of publication, sale, distribution or other misuse of the downloaded data.
Its timeline, using Australian Eastern Standard Time, records the following sequence of events:
- 6 August: Metabase published its security update. Mathspace says its notification process failed to escalate the advisory.
- 10 August: The earliest unauthorised access identified in the investigation.
- 27 August: Data downloaded from the Australian reporting database.
- 29 August: Mathspace updated Metabase after a later notice, without completing the recommended compromise checks.
- 3 September: Historical log review confirmed access before patching.
That chronology is useful because it separates fixing the software from discovering the incident. A successful update can leave a substantial question unanswered.
The Update Has a Specific Job
A patch addresses a software weakness. It cannot retrieve information already downloaded, and it does not necessarily remove access an attacker established before the update.
Fixing a defective lock stops someone using that defect tomorrow. It tells you very little about whether somebody entered the building yesterday.
Metabase's 6 August security notice made the additional work explicit. For installations with the affected endpoint publicly accessible, it called for session revocation, API-key and administrator reviews, connected-database credential rotation, and checks of database logs and application activity after upgrading. It also described an access pattern to look for in logs.
That is rather more than clicking an update button.
Metabase's subsequent technical explanation described how the attack could create a session and then an API key for downloading data. An API key is a credential software can use to access a service. If an attacker has created one, fixing the original entry point does not by itself establish that the key has stopped working.
This is why patch management and incident response need to be treated as separate jobs, even when the same person handles both. One asks whether the vulnerable software has been corrected. The other asks what happened during the exposure and what access might remain.
What Happens After a Serious Vulnerability
The response should fit the vulnerability and the installation. A flaw in an unused local feature does not automatically justify the same investigation as a remotely exploitable flaw in a public administration service.
Start by identifying the affected software and checking whether the vulnerable function was reachable. Establish how long that was true, as far as the evidence allows. A server installed last week has a different exposure window from one that has been running unchanged for a year.
Apply the vendor's fix or containment guidance promptly. Where compromise is suspected, preserve available evidence as part of that work; reinstalling everything first can make the later investigation much harder. Containment and evidence collection may need to happen alongside each other.
Then someone needs to read the rest of the advisory. Are there known indicators of compromise? Which logs might show the attack? Could the affected application create accounts, issue tokens or reach another database?
Depending on those answers, the work may include ending active sessions, removing unexpected administrator accounts, revoking API keys or changing exposed credentials. Connected systems may need their own checks. Keep monitoring afterwards, and record what was checked and what could not be established.
Changing a password can be part of that response. Assuming it invalidates every existing session or application token is another matter; that behaviour needs checking for the particular service. The stronger MFA controls I have written about remain useful, but turning on MFA after an incident does not explain what happened beforehand.
None of this requires treating every update as a confirmed breach. It requires knowing when the update alone cannot answer the question.
Logs Become Interesting Quite Suddenly
Historical logs are easy to regard as technical clutter until someone asks whether an account accessed a system three weeks ago.
At that point, discovering that the logs were overwritten on Monday is unhelpful.
Useful records can show login attempts, account changes, requests to an application or activity against a database. No single log necessarily tells the whole story. An application may record who signed in while another system records what information they queried.
ASD's event logging and threat detection guidance recommends retention long enough to support investigations, based on the system's risks. It also points out that default retention can be insufficient and storage limits can cause older records to be overwritten.
A small business does not need to collect everything forever. It does need to know which useful records exist, how long they survive and who can retrieve them. Logs should be protected from unauthorised changes, and access should reflect the sensitive information they may contain.
There is also a difference between finding no suspicious activity in useful, complete records and finding nothing because the relevant activity was never recorded. A consultant's report should make that limitation clear. I would rather explain an evidence gap than give someone reassurance the records cannot support.
The Small-Business Version
You do not need Metabase for this to matter. The same questions arise around a WordPress plugin, a hosting control panel, a NAS with remote access, a VPN gateway or an old webmail installation.
Does somebody know it is there? Who receives security advisories for it? And when a warning arrives, does it reach a person who can actually act?
An advisory sent to a former employee's mailbox is not much of a notification process.
Ownership needs to include the follow-up. If a hosting provider applies updates, establish whether its service also includes checking for earlier compromise. The business owner should not have to infer that from a ticket saying the latest version is installed. Agree who investigates, who can obtain the logs and when specialist help is needed.
Every additional service creates more of this work. That is one reason to remove applications and integrations that no longer serve a useful purpose. A reporting dashboard may be convenient, but its data access and maintenance still need an owner.
For a suitable brochure website, a static site can remove unnecessary application components. Hosting access, DNS, deployment credentials and connected services still need protection. The benefit is having fewer exposed components demanding attention, rather than some promise of an unhackable website.
The related problem of systems becoming difficult to maintain is covered in my Exchange and technical-debt article. Here, the question continues after the update succeeds. Namely, what evidence do we have about the what happened in the time before it?
A Private Household Can Have the Same Dependencies
A family with several properties can have home networks, CCTV, cloud storage, personal email, shared calendars and remote support supplied by different people. An assistant arranges travel. An accountant receives documents. A property manager has access to another system.
Nobody necessarily thinks of all that as one technology environment.
For high-net-worth individuals and families, the sensitive material can be spread across those relationships. After an incident, the difficult work may be establishing what the exposed system could see and which other accounts or services trusted it.
Consider a hypothetical household NAS used for document storage. Updating it addresses the disclosed software flaw. Understanding a possible intrusion means checking available access records, shared folders, user accounts and any credentials held by applications on the device. The response depends on what was accessible, rather than the fact that the box now reports current firmware.
The same care applies to a compromised personal email account. Existing sessions, forwarding rules and delegated access may need review, along with connected accounts. An assistant or adviser might need to act too. That should be coordinated discreetly, without circulating private documents more widely than necessary.
Solway Web Consulting provides personalised IT and cybersecurity consulting for private clients in Sydney. Part of the value of that oversight is knowing how the household's accounts and providers fit together before someone has to reconstruct the arrangement during an incident.
When someone tells you the patch is installed, that is useful news. Ask what was checked for earlier access as well. The answer may be reassuring, may require further investigation, or may be limited by missing records. Any of those is more useful than silently assuming the update answered both questions.
Tags: security, small-business, private-client, australia