On 3 August somebody started reading other companies' production databases. They did not break into any of those companies. They came in through the business intelligence tool all of them shared, because that was where the credentials lived.
A BI server is where an organisation wires up its databases so they can be queried without friction. The price of that convenience seldom reaches the risk register: the machine ends up holding the keys to everything else. The flaw Metabase disclosed on 6 August shows what happens when somebody picks them up.
What happened, in order
The public timeline, drawn from Metabase's security advisory and reporting by BleepingComputer, spans four days.
- 3 August: the earliest access date victims have confirmed, on Metabase Cloud instances.
- 6 August: Metabase identifies the flaw, patches Metabase Cloud instances automatically, publishes its advisory and urges self-hosted customers to upgrade. It notifies affected customers the same day.
- 7 and 8 August: Framework and Tally publish their breach notifications.
The flaw is a SQL injection exploitable without prior authentication against the application's own database, scored at CVSS 10.0. It was exploited before any fix existed, which makes it a zero-day in the strict sense, and it carries no CVE identifier. It affects versions 1.58 and later, including self-hosted installations.
Why does a BI flaw end up in all your customers' data?
Because Metabase was never the target that mattered. In outline, the chain runs like this: the attacker injects queries against the application database without credentials, escalates to instance administrator and, at that level, reaches the store holding the credentials for every connected database. Nothing further needs to be exploited. They connect as the data team would and query whatever those credentials allow, so the exfiltration travels through an authorised channel.
The pattern matches the OAuth abuse against Salesforce, where attackers walked in on legitimate permissions inherited from a trusted integration.
The question worth asking today has little to do with whether your instance was patched. It has to do with how far the credentials that instance stored could reach. If the connection account was a database administrator with read access across the whole schema, the scope of the incident is the whole schema.
What the two confirmed cases reveal
Framework, the modular laptop maker, notified its entire customer base that an attacker accessed names, email addresses, phone numbers, postal addresses and login IP addresses. The company stated that payment information was not affected, that it rotated its credentials after being notified, and that it confirmed no changes to admin access and no access to systems beyond Metabase.
Tally, the online form platform, told its users that its analytics environment was compromised on 3 August and that the attacker reached email addresses and passwords in hashed form, without reaching forms or the responses submitted to them.
The comparison between the two is instructive. At Framework, the exposed data is contact and address detail — enough to build very convincing impersonation campaigns against an entire customer base. At Tally, segmentation held: analytics could see accounts, not form content, and that contained the damage. What made the difference was what had been wired into the tool, and with which permissions.
Why the usual controls did not catch it
There are four reasons, and none of them is negligence.
There was no CVE. Vulnerability management programmes fed only by public identifiers and the KEV catalogue had nothing to prioritise. Vulnerability monitoring has to include vendor advisories, which is where this one surfaced.
It was a managed service. On Metabase Cloud the customer patches nothing and never sees the operating system, because the attack surface belongs to the provider. The customer's only lever came afterwards, in which credentials had been deposited and with what permissions.
The traffic was legitimate. With connection credentials already stolen, queries arrive at the database from the usual source and as the usual account. There is no malware to catch and no odd process on a server, only an authorised session asking questions.
The instance logs sat within the attacker's reach. Metabase warns that system logs showing the compromise pattern may themselves have been tampered with, which points back to a familiar principle: the useful evidence is the copy you ship off-box.
How do you detect the compromise in your logs?
Metabase published a specific indicator of compromise, easy to search for in access logs.
Pattern:POST /api/session/reset_password→ 400, followed byGET /api/user/current→ 200 from the same session or source. Treat it as compromise until proven otherwise, not as one more alert to triage.
The hunt should not stop there. Review the instance's query history for bulk extractions or queries against tables that account never touches; look for access to connected databases outside the data team's hours and from addresses other than the instance's; and check whether administrator accounts or API keys were created or modified around those dates. Where the SIEM actually receives database query logs, the anomalous extraction leaves more trace than the initial intrusion.
What to do now
Order matters here, because upgrading without rotating leaves the attacker holding valid credentials.
| Action | Why | Priority |
|---|---|---|
| Upgrade to a fixed release (0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5 or later) | Closes the entry path. Cloud was patched automatically by the vendor | Immediate (self-hosted) |
| Rotate credentials for EVERY connected database | This is the asset the attacker was after; a patch does not invalidate what was already taken | Immediate |
| Revoke all active sessions | Ejects any session the attacker may still hold | Immediate |
| Review administrator accounts and API keys | Detects persistence created during the access window | High |
| Hunt the compromise pattern and inspect query history | Establishes whether access occurred and what was queried | High |
| Assess personal data scope and notification duties | Starts the GDPR clock and, where applicable, NIS2 | High, in parallel |
If the compromise pattern appears, credential rotation stops being precautionary and becomes containment of a live incident.
Where an instance turns out to be compromised, scoping should not be done by eye. Establishing what the attacker queried, and for how long, is work for digital forensics and an incident response team with the log history to hand.
The data that should never have been there
The structural lesson lies in what data your analytics tool can see.
Most questions put to a BI tool are answered with aggregates, cohorts and trends; a customer's phone number and postal address are rarely the answer. Even so, the usual practice is to connect it to the production database with an over-privileged account because that is quickest, then let the analyst decide later what to look at. That shortcut turns a vendor's flaw into a notification to the entire customer base.
The measures that would have contained this incident are unglamorous and well understood: read-only accounts scoped to specific views rather than the full schema; views exposing aggregated or pseudonymised columns instead of direct identifiers; separation between analytics and the tables holding contact data; and an inventory of which sources are wired to which tool, with a named owner. This is data minimisation implemented in the schema, not drafted in the privacy policy.
The lifespan of those connection credentials deserves the same scrutiny, because they typically never expire. They are accounts without an assigned owner, holding read access to the most sensitive parts of the business, with nobody rotating them.
Do you have to notify if the flaw was your provider's?
Generally yes, and it is the point that generates most debate when responsibilities are mapped out. Under the GDPR, the company deciding why its customers' data is processed remains the controller, and that status does not transfer to the BI provider merely because the flaw was theirs. Where the breach poses a risk to the rights of data subjects, notifying the supervisory authority falls to the controller, within 72 hours of becoming aware. Where that risk is high, communicating with the affected individuals is added on top, which is the step Framework took with its customers.
The provider acts as processor, and its duty is to inform the controller without undue delay, which is what happened on 6 August. Entities in scope of NIS2 must add their own significant-incident reporting, with early warning inside 24 hours, plus the obligation to manage supply chain risk. In Spain the transposing law is still pending; the substantive obligation is not.
In practice this is settled before the incident: contracts with explicit notification deadlines, and third-party risk management that records which provider processes which data with what access. By the time the advisory lands, the clock has already started.
What this case leaves behind
Metabase patched its managed service, published an advisory with indicators of compromise and engaged an external forensic firm. Even so, the problem has no vendor-side fix: the damage was set by the reach of the credentials each customer had entrusted to it.
That is the asymmetry of the SaaS model. You can outsource running a tool, but not accountability for the data you hand it. When reviewing data integrations, the question that pays is not how many tools you have connected, but what an attacker would see if any one of them fell tomorrow. Measuring that reach is the work we do at Hard2bit as a cybersecurity company, before somebody else measures it for us.
Sources and attribution: this article draws on public disclosures available on 9 August 2026 — Metabase's security advisory and the breach notifications issued by Framework and Tally, as reported by BleepingComputer, TechCrunch and The Hacker News. The scope of these incidents may widen as the ongoing forensic investigation progresses. These companies are named on the basis of their own public statements, and no assessment of their security posture is implied.
Note: this content is defensive and educational in purpose. The indicators and actions described should be validated against the vendor's official advisory and adapted to each environment before being applied in production. It does not constitute legal advice on notification obligations.
