Topic starter
22/09/2026 3:43 pm
TL;DR: Mathspace’s breach affected 1,079,819 people after an unauthenticated SQL injection in a self-hosted Metabase instance sat unpatched for 23 days, according to Unosecur’s analysis. The incident shows that internal tools with standing data access must be governed as high-blast-radius non-human identities, not as low-priority back-office systems.
NHIMG editorial — based on content published by Unosecur covering the Mathspace data breach: internal reporting tool exposure and delayed remediation
By the numbers:
- The flaw sat unpatched for 23 days after the advisory, widening the exposure window for the reporting instance.
Questions worth separating out
Q: What breaks when an internal reporting tool is treated as low risk?
A: The control assumption breaks at ownership and escalation.
Q: Why do self-hosted analytics tools create breach risk even without stolen passwords?
A: Because the risk is not only authentication.
Q: How do security teams know whether an internal tool has too much access?
A: Look at what the tool can actually reach, not what its interface suggests.
Practitioner guidance
- Map internal reporting tools as governed identities Add self-hosted BI, dashboard, and internal analytics platforms to your identity inventory, including the databases, APIs, and exports they can reach.
- Escalate critical advisories through a data-access lens Route publicly disclosed vulnerabilities by the sensitivity of the data reachable through the affected system, not by whether the tool is internal or external.
- Run compromise checks before and after patching When a self-hosted platform is exposed to a critical flaw, confirm whether the vendor or project recommends forensic checks, then complete them before restoring normal trust in the instance.
What's in the full article
Unosecur’s full analysis covers the operational detail this post intentionally leaves for the source:
- The full incident timeline and log-based chronology behind the Metabase compromise.
- The exact data fields exposed and the differences between active and former-user records.
- The remediation steps Mathspace took after discovery, including restoration conditions and notification sequencing.
- The vendor’s discussion of internal tool visibility, service account exposure, and identity graph correlation.
👉 Read Unosecur’s analysis of the Mathspace data breach and internal reporting tool exposure →
Mathspace breach and internal reporting tools: where IAM controls failed?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
22/09/2026 3:43 pm
Internal reporting tools are non-human identities, not just applications. When a self-hosted analytics platform can query sensitive databases and export records, it behaves like a governed identity with persistent reach. Mathspace’s breach shows why asset inventories that ignore internal tools miss the real blast radius. The practitioner implication is simple: if a system can access production data, it belongs in identity governance.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why internal reporting tools often stay outside the real control plane.
A question worth separating out:
Q: What should organisations do after a critical flaw hits a self-hosted tool?
A: They should verify exposure, complete the vendor or project’s compromise checks, and review all downstream accounts and databases the tool can access before restoring trust. The key question is not whether the patch is installed, but whether the system could have been used to read or export data before remediation finished.
👉 Read our full editorial: Mathspace breach shows why internal tools need identity visibility
