Mathspace breach shows why internal tools need identity visibility

At a glance

What this is: A self-hosted internal reporting tool at Mathspace was compromised through a critical Metabase flaw, exposing account data for more than 1 million people.

Why it matters: IAM, NHI, and security teams should treat internal analytics platforms as governed identities with explicit ownership, patch urgency, and exposure mapping, not as invisible infrastructure.

By the numbers:

• The flaw sat unpatched for 23 days after the advisory, widening the exposure window for the reporting instance.

👉 Read Unosecur’s analysis of the Mathspace data breach and internal reporting tool exposure

Context

Mathspace’s breach is a reminder that internal reporting tools are often treated as low-risk even when they sit close to sensitive data and hold standing administrative access. In identity terms, the problem is not the dashboard itself but the non-human identity behind it and the access it quietly accumulates over time.

The central governance failure was a missed escalation path. A publicly documented critical flaw in a self-hosted analytics tool should have triggered immediate review, yet the advisory sat inside process for weeks while the tool remained reachable and capable of exporting data.

Key questions

Q: What breaks when an internal reporting tool is treated as low risk?

A: The control assumption breaks at ownership and escalation. If a self-hosted BI system can query sensitive data but is not treated as a critical identity-bearing asset, urgent advisories may sit unreviewed and compromise checks may be skipped. That leaves standing access in place long enough for an attacker to turn a software flaw into a data breach.

Q: Why do self-hosted analytics tools create breach risk even without stolen passwords?

A: Because the risk is not only authentication. A vulnerable reporting platform can already hold privileged connections to live databases, so exploitation can bypass normal login monitoring and reach the data layer directly. When that system has standing access, a single unpatched flaw can expose large volumes of identity and account data.

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. If a dashboard, report server, or internal analytics platform can export personal data, query production records, or act through a service account, it has more privilege than a casual inventory usually captures. Effective review starts with effective permissions.

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.

Technical breakdown

Unauthenticated SQL injection in an internal reporting tool

The exposed flaw was an unauthenticated SQL injection in Metabase’s password-reset API. That means an attacker could send crafted input that the application passed into a database query without proper validation, turning a normal form field into a path to arbitrary SQL execution. In a self-hosted reporting environment, that is especially dangerous because the tool usually sits next to privileged data sources and often carries administrative reach through service accounts or direct database access. The risk is not only code execution. It is the ability to pivot from one weak input path into the data layer behind the business intelligence platform.

Practical implication: treat internal BI tools as internet-exposed attack surfaces and validate whether their data connections are more privileged than the tool’s user interface suggests.

Why delayed patching creates a breach window

A critical vulnerability only becomes a breach when the patch and the escalation process fail together. Here, the advisory was public for weeks before Mathspace completed remediation, and the patch landed only after the attacker had already used the flaw to access the reporting instance. That delay matters because self-hosted tools often do not benefit from automatic vendor-side containment. If the organisation owns the host, the patch timeline and compromise review are entirely on the customer side. Once the patch is delayed, every day becomes part of the attacker’s usable window.

Practical implication: tie remediation SLAs for internal tools to exploitability and data access, not to whether the system is customer-facing.

Standing administrative access turns a reporting tool into a breach amplifier

A reporting platform becomes a high-impact target when it can read live operational data, export it, and persist with broad permissions even when no one logs into it daily. That is a classic non-human identity problem: the tool’s credentials and access scope often remain stable long after the original business need changed. In this incident, the exposure was not limited to a single transaction record. It covered identity metadata for more than a million users because the compromised system had persistent reach into a reporting database. The failure is not visibility alone. It is unmanaged standing access in an internal system that was assumed to be safe because it was internal.

Practical implication: inventory internal tools as identities, map their effective permissions, and retire standing access that outlives the business need.

Threat narrative

Attacker objective: The attacker aimed to gain administrator access to the reporting platform and extract user and account data at scale.

1. Entry occurred through an unauthenticated SQL injection in a self-hosted Metabase password-reset API, allowing the attacker to reach the reporting environment without valid credentials.
2. Escalation followed when injected SQL granted administrative control of the internal tool and enabled access to the connected reporting database.
3. Impact came from data export over a sustained window, exposing identity and account metadata for more than 1 million users across Australia and New Zealand.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Poland Military Breach — Polish military email credentials compromised exposing sensitive government communications.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Delayed escalation is the real control failure here. The vulnerability was public, severe, and actively exploitable, yet the organisational response lagged long enough for the compromise window to stay open. That is not a patching problem in isolation. It is a triage and ownership problem, where the internal reporting tool did not have the same urgency as a customer-facing service. Security teams need a severity path that treats data-bearing internal systems as critical assets from the moment a credible advisory appears.

Standing access in internal tools creates identity blast radius. The account metadata exposed here was not the result of a one-off breach of a single user session. It came from a platform with durable access to a reporting database. That access pattern is exactly what NHI governance is meant to surface. The implication is that entitlement scope, not just vulnerability count, should determine whether an internal tool is allowed to keep direct data reach.

Privilege review must include self-hosted infrastructure with hidden data reach. Security programmes often review end-user accounts and cloud roles while leaving BI and reporting platforms outside the same discipline. This breach shows that the gap is structural, not procedural. A dashboard that can reach production data is part of the identity plane, and it should be judged on the same basis as any other non-human identity with standing privilege.

From our research:

• 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.
• The next step is to compare tool inventory with 52 NHI Breaches Analysis and identify which internal systems still have standing data access.

What this signals

Internal reporting platforms are increasingly part of the identity attack surface, especially when they sit between sensitive databases and users who never interact with them directly. If a tool can read, transform, and export protected data, it needs ownership, review cadence, and revocation logic like any other non-human identity. That is the governance gap this incident exposes.

Identity blast radius: the reach of a self-hosted tool is determined by the data it can touch, not by how visible it is to users. Teams should expect more breach paths to come from overlooked internal platforms, and they should use CISA cyber threat advisories as a trigger to re-rank those systems by exposure, not by convenience.

The practical signal for programmes is to move internal applications into the same lifecycle logic used for service accounts, API keys, and privileged integrations. When patching, offboarding, or recertification excludes those tools, the organisation is preserving standing reach that attackers can convert into data loss.

For practitioners

• 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. Record the owner, business purpose, and effective permissions for each one.
• 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. If a reporting platform touches live user data, it should enter the same response path as production services.
• 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. A patch alone does not prove the environment stayed clean.
• Reduce standing access in reporting systems Review service accounts, API credentials, and admin connections that let internal tools reach sensitive databases. Remove access that is broader than the reporting use case and revoke credentials that are no longer required.

Key takeaways

• Mathspace’s breach shows that a self-hosted internal tool can function like a high-value non-human identity when it has persistent access to sensitive data.
• The scale of exposure was material, with 1,079,819 people affected and a 23-day gap between disclosure and remediation that widened the attack window.
• Internal tools need the same access inventory, advisory escalation, and compromise verification discipline as production systems if organisations want to prevent repeatable data breaches.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Advisory Escalation: Advisory escalation is the process that turns a public vulnerability notice into an immediate internal response. In practice, it determines whether a critical flaw is treated as a routine patch item or as a time-sensitive exposure event that could already be in active use.

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.

👉 Unosecur’s full post covers the breach timeline, exposed data, and visibility gap behind the incident

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.