Mathspace, an online maths-learning platform, disclosed that attackers stole data on more than a million students, staff and parents after breaching its internal Metabase reporting system. The detail that matters is where they got in: not the public app, but an internal business-intelligence tool. It is a pattern worth studying, because the systems we point inward, the dashboards and reporting tools nobody thinks of as an attack surface, are exactly where a lot of modern breaches now begin.
What happened
The public-facing product was not the way in. Attackers reached an internal reporting system, Metabase, and from that vantage point pulled data on over a million people connected to the platform, including students, which raises the stakes further given the age of many of those affected. Internal analytics tools are attractive precisely because of what they are built to do: they sit close to the data, aggregate it, and make it easy to query. A tool designed to surface information for staff will surface it just as helpfully for an intruder who reaches it.
Business-intelligence platforms often connect directly to production databases and hold broad read access across them. That is their job. But it also means compromising the dashboard can be equivalent to compromising the database behind it, without ever touching the database’s own defences. The reporting layer becomes a side door into everything it can see.
Why internal tools become the soft underbelly
Teams pour security effort into the customer-facing application because that is what the world can see. The internal admin panel, the analytics dashboard, the reporting tool get a fraction of that attention. They are assumed to be safe because they are “internal”, yet they are frequently exposed to the internet for remote staff, run with default or weak configurations, and lag behind on updates. That combination, high privilege and low scrutiny, is precisely what an attacker looks for.
The access these tools carry makes the imbalance dangerous. An internal BI platform typically has credentials to read across systems, so a foothold there is not a dead end but a launchpad. And because the traffic looks like ordinary internal use, malicious queries can blend in with legitimate ones, buying the attacker time to work through the data before anyone notices something is off.
The special weight of children’s data
There is an added dimension when the records belong to students. Children cannot meaningfully consent to how their data is handled, they are years away from the financial life where identity theft usually bites, and a breach that surfaces now can quietly follow them into adulthood. That long tail makes education-sector data unusually valuable to patient criminals and unusually damaging to lose. It also raises the bar for anyone building or operating tools that touch it: the reporting dashboard that felt like a harmless internal convenience is, when it holds a million young people’s details, a serious responsibility. Treating it with the same seriousness as a customer-facing system is not caution for its own sake; it is proportionate to what is at stake.
A short checklist for your internal tools
If this breach prompts one action, make it an honest look at your own internal tooling. A handful of questions cut to the core. Which dashboards, admin panels and reporting systems do you actually run, and does anyone own that list? Are any of them reachable from the internet, whether deliberately for remote staff or by accident? What can each one read, and is that far more than it strictly needs? Do they enforce strong authentication and sit behind network controls, or do they trust anyone already “inside”? And, crucially, would you notice if one of them suddenly started returning far more data than usual? Most organisations cannot answer all five with confidence, and the gaps are the map an attacker follows. Closing them is rarely expensive; it mostly requires deciding that the tools you point inward deserve the same scrutiny as the ones you point out.
How to close the side door
- Inventory your internal tools and treat them as first-class assets: know which internal dashboards, admin panels and BI tools exist, what each can reach, and whether any are exposed to the internet.
- Lock down access with strong authentication, least privilege and network segmentation, so a compromised dashboard cannot read far beyond what it strictly needs.
- Test the inside, not just the outside. Many programmes only pentest the public app; an internal network penetration test and a source code review probe exactly the internal systems that breaches like this exploit.
- Watch internal query patterns and data access. Managed detection and response and continuous vulnerability management help spot the abnormal use of a normal tool before a million records walk out.
Segmentation is the cheapest win
If one control pays for itself against this class of breach, it is network segmentation. An internal tool that can only reach the specific data it needs is a far smaller prize than one sitting on a flat network with a clear line of sight to everything. Segmentation does not stop the initial compromise, but it caps the damage: a foothold in the reporting dashboard should not translate into read access across every production system. Combined with least privilege on the tool’s own database accounts, it turns what could be a million-record breach into a contained incident affecting a fraction of that. It is old advice precisely because it keeps working, and it costs far less than the cleanup it prevents.
The bottom line
The Mathspace breach did not come through the front door everyone was guarding; it came through an internal reporting tool few thought to defend. That is the modern shape of a lot of incidents: the attacker skips the hardened application and goes for the privileged, overlooked system beside it. Map your internal tools, constrain what they can reach, and test them as seriously as your public product. If leaked personal data, especially children’s, ends up in circulation, dark-web monitoring is your early warning. Unsure how much an intruder could see from one internal foothold? Let us test it before someone finds out the hard way.
Tell us what you're running
Scoping is free. We reply within one business day, and under 30 minutes for active incidents.
