Mathspace

On September 3, 2026 Mathspace confirmed that unauthorized parties accessed an internal reporting system and downloaded information on students, their parents or guardians, and school staff. The total was 1,079,819 individuals.

The route was a self-hosted installation of Metabase, an open source business intelligence tool. Attackers exploited a critical SQL injection zero-day to obtain administrator access without a legitimate login. Mathspace was one victim in a wider campaign against internet facing Metabase instances.

Records covering students, parents and guardians, and school staff, drawn from the internal reporting system rather than the learning product itself. That distinction shapes everything else about this incident.

A reporting tool exists to join data that lives apart. It is pointed at the production database precisely so somebody can ask questions that span tables, which means it holds the broadest possible read permission in the organization by design. Whatever the analytics team needed to see, the attacker saw.

Children first, then the adults attached to them. A maths platform knows a student's name, school, year level and performance over time, and links each one to a parent or guardian contact.

The specific harm for minors is duration. A student in this set is ten years from opening a first bank account, and the identifiers in the record will still be current when they do. The parent records carry the immediate risk, since a contact detail tied to a named child at a named school is unusually convincing material for a targeted approach.

Self-hosting Metabase is a defensible choice, often made for exactly the right reason: keeping student analytics inside your own infrastructure rather than sending it to a vendor. Many education platforms do it to satisfy the data residency promises they make to schools.

The risk is that self-hosting transfers the patching duty along with the control. A managed instance would have been fixed by the provider. A self-hosted one is fixed when the team that installed it notices, and internal tools are the ones nobody has scheduled.

Which data the reporting tool could reach. A dashboard is not usually inventoried as a data store, because it holds no data of its own. It holds a connection, and the connection is the exposure.

That is why a zero-day in a BI tool produces a million person breach at a company whose product is maths exercises. The blast radius was never a property of Metabase. It was a property of the credential Metabase held, and nobody had drawn a line around what that credential could read.

Mathspace produced a precise figure, 1,079,819, and produced it quickly. Knowing the count after the fact is the easy half. Knowing beforehand that one internal tool could enumerate every student, parent and teacher in the system is the half that would have changed the decision to leave it reachable.

No group has claimed Mathspace specifically. The campaign against Metabase instances hit multiple companies, and in at least one related case the ShinyHunters extortion gang sent the emails.

A zero-day used at scale against a common internal tool is opportunistic rather than targeted. Mathspace was not selected. It was scanned, and it answered.

Scoping the reporting connection. A BI tool reading a purpose built analytics schema, with identifiers removed, produces the same charts and a far smaller breach. Pointing it at production with administrative reach is the default, and the default is what got exercised here.

Second, knowing which internal tools hold live credentials into student data. The organization could name its production database. What it could not do, before September 3, was list every system holding a key into it and say what each one could see.