The Mathspace Breach: Self-Hosted Software and the Patching Trap

Last week Mathspace, the Australian online maths platform used by thousands of schools, confirmed one of the largest education data breaches in the country's history. More than a million students, parents and school staff across Australia and New Zealand had personal details taken, including names, email addresses and account information.

The breach deserves your attention for two reasons: it shows how one unpatched system can undo an otherwise sensible security setup, and the software at the centre of it, a self-hosted reporting tool called Metabase, is exactly the kind of thing many businesses run without a second thought.

What happened at Mathspace

On 3 September Mathspace confirmed that unauthorised parties had accessed an internal reporting system and downloaded records covering students, parents and guardians, teachers, and Mathspace staff. In total 1,079,819 people were affected, all in Australia and New Zealand. No passwords, authentication tokens or academic records were taken, and no evidence has emerged that the data was published or sold. Mathspace notified the Office of the Australian Information Commissioner and the Australian Cyber Security Centre, and is contacting affected individuals.

Mathspace was open about how the attackers got in. They exploited a known vulnerability in a self-hosted installation of Metabase, an internal reporting tool. The flaw, tracked as CVE-2026-72898 and rated 10 out of 10 on the CVSS severity scale, is an SQL injection bug that lets an unauthenticated attacker gain administrator access. It was exploited in the wild before a fix existed; Metabase published a critical advisory and patched versions in early August.

Mathspace did not act on that advisory quickly enough. Unauthorised access began on 10 August and data was downloaded on 27 August, but the instance was only updated on 29 August, more than two weeks after the attackers were inside. Mathspace is investigating why the initial advisory was not escalated and why the vendor's recommended compromise checks were not completed when the update was applied; the intrusion was confirmed on 3 September, after a review of historical logs.

"We are investigating why the initial advisory was not escalated and why those checks were not completed sooner. We are changing both processes as part of our incident response."

That admission contains the two failures that matter. The warning was missed, so nobody treated a critical, exploited-in-the-wild vulnerability as an emergency. And the patch was treated as the end of the job, with no check for whether the system was already compromised. A patch does not evict an attacker who is already inside; that is why the vendor's compromise checks exist, and why the intrusion only surfaced weeks later in the logs.

Self-hosting means the patch queue is yours

The word that should stop you in Mathspace's account is "self-hosted". Metabase is a business intelligence tool thousands of organisations install on their own servers for dashboards and reporting. When you run software yourself, you take on the vendor's security burden: watching advisories, judging severity, scheduling, testing, applying, then checking that nothing bad happened first.

Nothing pushes that work to you. A critical advisory is an email to a mailing list, or a page on a vendor site you have to be checking. If nobody is explicitly responsible for reading those advisories and acting within days, you do not have a patching process; you have a hope.

Mathspace is a technology company with engineers, and it still missed a critical advisory for weeks. When GitHub disclosed a critical remote code execution flaw in its self-hosted Enterprise Server product in early 2025, 88% of self-hosted instances were still unpatched at public disclosure. A reporting dashboard, a wiki, a file server, a VPN appliance, a mail server: every self-hosted component is an asset someone must track, version and patch, and the most mundane ones get forgotten. Internal tools often sit in front of large amounts of data, as Mathspace's reporting database proved.

The Time You Have to Patch Is Shrinking

The second trend is the patch window itself, the gap between a fix being published and attackers weaponising it. It is collapsing. Organisations historically took a median of 32 days to apply patches to known vulnerabilities; by 2025 the median time from disclosure to exploitation had fallen to roughly five days (Cloud Security Alliance). Rapid7's 2026 threat landscape report counted 146 vulnerabilities actively exploited in 2025, up 105% on the year before, with known-exploited vulnerabilities landing on CISA's catalogue about five days after disclosure.

In the Metabase case, the extortion group ShinyHunters claimed responsibility for hacking Metabase instances within days of the patch release, before many monthly maintenance windows had even opened. Policies built around 30-day SLAs and quarterly change windows were calibrated for a threat environment that no longer exists; internet-facing systems with exploited vulnerabilities need patching in days, which is why Australian government guidance through the Essential Eight treats prompt patching as a core control.

Vibe Coding Is Adding to the Pile

The third trend is the software itself. More of the code running the modern world is written by AI, at a speed and volume human review was never designed for. "Vibe coding", accepting AI-generated code with minimal scrutiny, is mainstream: a quarter of startups in Y Combinator's Winter 2025 cohort reported codebases that were 95% AI-generated.

The security data on AI-generated code is sobering. Veracode tested more than 100 large language models on security-sensitive coding tasks and found that 45% of generated samples introduced OWASP Top 10 vulnerabilities, with no improvement across testing cycles into 2026. Georgia Tech's Vibe Security Radar project tracked 74 CVEs in the first three months of 2026 traced directly to AI-generated code, and estimates the true figure is five to ten times higher. Around one in five packages referenced by AI-generated code do not exist, a pattern attackers exploit by registering those hallucinated names as malicious packages, a technique researchers call slopsquatting. Scans of more than 5,000 applications built on AI coding platforms found over 2,000 critical vulnerabilities and more than 400 exposed secrets.

Meanwhile AI is accelerating the other side: AI-assisted analysis has compressed the time from disclosure to working exploit from weeks to days, and in a growing number of cases to hours. The result is a squeeze from both directions: AI writes more software with measurable security debt, while AI helps attackers weaponise each disclosed flaw faster than human-scale patching can respond.

What Your Business Should Do About It

Most of the businesses we talk to do not run Metabase. They run the small-print equivalent: the dashboard someone installed five years ago, the file server under the desk, the internal tool a developer built for the team, the web app an ex-employee's company still hosts. Each one is a self-hosted asset with a patch queue, and each is the kind of forgotten system that shows up as an entry point in breach reports. Here is what the Mathspace timeline says you should be doing:

1. Inventory everything, starting with what faces the internet. If you cannot name every system that answers connections from outside your network, you cannot patch what you do not know exists. Include the internal tools: reporting, dashboards, wikis, file shares. They hold data too.
2. Watch the right warnings. Subscribe to vendor security advisories for every product you run, and check CISA's Known Exploited Vulnerabilities catalogue. Treat a CVSS 9+ finding, or anything already exploited in the wild, as an emergency rather than a ticket for the next change window.
3. Patch fast, then verify. Apply fixes to internet-facing systems within days of release. Then do the second step Mathspace missed: run the vendor's compromise-check guidance and review logs for signs the system was hit before you patched.
4. Have an emergency path. A pre-approved process for urgent patches that does not wait for committee sign-off or the monthly maintenance window. In 2026, the window between advisory and exploit can be shorter than your change calendar.
5. Question whether to self-host at all. The right question about any piece of software is whether you can patch it within the window the threat environment demands. If you cannot, the vendor's managed version is the safer choice, and patching becomes someone else's job.
6. If AI wrote it, review it like code from an unknown developer. If your team uses AI coding tools, or a key vendor builds on them, ask what review happened before it reached production: security scanning, dependency checks, and human review of anything that touches logins and access controls. Untested AI-generated code is how the vulnerability pile keeps growing.

Patching is unglamorous work, and it does not end when the update is applied. It is an inventory problem, an alerting problem and a discipline problem, and it needs an owner. The businesses that stay safe have someone explicitly responsible for the patch queue every week, and they escalate exploited vulnerabilities the same day they are disclosed.

← Back to all articles    See Our Services →