Mathspace Exposed 1.08M Accounts—Passwords Were Not in the Export

The September 8 Mathspace incident update puts the breach at 1,079,819 affected people in Australia and New Zealand, including students, parents or guardians, teachers and company staff. Attackers downloaded names, email addresses and account metadata, but the export did not contain passwords, authentication credentials or academic records.

The attackers gained access to a self-hosted Metabase installation used for internal reporting, rather than the system delivering lessons and assignments. The compromised reporting system was taken offline, affected accounts and records were identified, and the investigation into the scope of the exposure was completed; the learning service remained available.

What was—and was not—in the export

ABC News’ account of the exposed fields independently corroborates that the export included internal user IDs, usernames, first and last names, email addresses, country, time zone, user type, email-verification status, last-active date, last-login date and date joined. Not every field was present for every person, and retained information belonging to former or inactive users may also have been affected.

Academic records, learning activities, results, assessment records, password hashes, authentication tokens, single sign-on credentials and API credentials were excluded. The dataset also lacked a direct record connecting each account to a school, although an identifiable school email domain may allow that association to be inferred.

This boundary is important. The exposed information could help an impersonator sound credible, but it does not itself provide a working password, an authenticated session or access to a student’s performance history.

A blanket Mathspace password reset is not justified

Mathspace is not requiring a password reset because customer passwords and other authentication credentials were not part of the export. For this incident alone, resetting every account would address a credential exposure that the completed scope investigation did not find.

A password should still be replaced if it is reused across services or if suspicious account activity creates a separate reason to act. Users should reach Mathspace or another affected service independently, rather than following an unexpected reset link.

The response should follow the kind of information exposed, not only the size of the incident. That distinction between containing leaked credentials and limiting impersonation risk also explains why the appropriate breach response varies from case to case.

The realistic risk is targeted impersonation

Names, email addresses, account roles and activity dates can make a fraudulent approach more convincing. A message might claim that a student’s access needs restoring, that a parent must verify an account or that a teacher must review an urgent security notice. These are plausible scenarios based on the exposed fields, not evidence that such campaigns have occurred.

The dangerous element would be a request to open an attachment, visit an unfamiliar sign-in page, disclose a password or provide a verification code. Correct personal details do not prove that the sender represents Mathspace or a school.

No evidence had emerged that the downloaded data was published, distributed, sold or otherwise misused, and the attacker’s identity remained unknown at the time of the update. Phishing and impersonation are therefore prospective risks rather than confirmed consequences of the breach.

Proportionate action for each affected group

Students and families

• Treat unexpected messages about Mathspace, a school or the breach as unverified, even when they contain a correct name, email address or account role.
• Open Mathspace or the school’s website independently instead of using an unexpected link or attachment.
• Do not provide passwords or verification codes in response to a message. Students who are unsure should ask a parent, guardian or teacher for help.
• Change a password where it was reused or where unexplained account activity provides a separate reason to do so.

Schools and administrators

• Give families a verified contact channel and distinguish the exposed profile metadata from passwords and academic records that were not included.
• Warn staff that an attacker could pose as a student, parent, colleague or Mathspace representative using accurate account details.
• Contact Mathspace through the address published in its incident notice to request affected-record information associated with the school.
• Avoid embedding sign-in links in breach communications, so genuine notices do not encourage the behaviour an impersonator may exploit.

School IT and security teams

• Monitor for lookalike domains, unusual password-reset activity and messages using Mathspace-themed lures.
• Preserve suspicious emails with their headers, links and attachment details for investigation and reporting.
• Check whether exposed usernames or email addresses overlap with local identity systems, without ordering indiscriminate resets unless password reuse or evidence of compromise supplies a separate reason.
• Require help-desk staff to verify identity through established records before changing account details or assisting with access.

How the reporting system was compromised

SecurityWeek’s technical account identifies the flaw as CVE-2026-72898, a critical SQL injection vulnerability patched by Metabase on August 6, 2026; unauthorised access at Mathspace dated back to August 10, data was downloaded from its Australian reporting database on August 27, and the company updated its installation on August 29.

The initial critical advisory was not identified and escalated through the existing vulnerability-notification process. When the update was installed, the additional compromise checks recommended for potentially affected systems were not completed, leaving the earlier intrusion undiscovered until historical access logs were reviewed.

Containment included taking Metabase offline, revoking its API keys, disabling its database-access accounts and changing passwords for the associated Cloud SQL databases. Privacy, cybersecurity and education authorities in Australia and New Zealand were notified, while schools and affected individuals began receiving notices.

Metabase remains offline while recovery checks continue. Individual notifications, responses to school requests and a post-incident account of changes to advisory escalation and compromise checks remain outstanding; any evidence of misuse or revision to the affected dataset would alter the present risk assessment, but neither has been disclosed.

Also read:

• After a Data Breach, the Right Fix Depends on What Was Exposed
• Why DSPM Matters: It Shows Which Sensitive Data Is Exposed—and Why
• Corporate Data Defense: Software Flaws Now Beat Stolen Passwords