SAN FRANCISCO, 9 AUG 2026 — A laptop company and a form builder were broken into on the same day, by the same bug, in a piece of software neither of their customers had ever used.

The software is Metabase, an open-source business-intelligence tool that turns database queries into dashboards. On 3 August someone exploited a flaw in it that nobody outside the attacker knew existed. Metabase published an advisory three days later. Two of its customers have since told their own users what was taken.

What is known

Framework, which makes deliberately repairable laptops, emailed customers late on Thursday 6 August. Spokesperson Eric Schumacher told TechCrunch the notice went to "all customers" and declined to give a number.

The fields taken were full names, email addresses, login IP addresses, billing and shipping addresses, phone numbers and company names. Business accounts may additionally have exposed VAT and EIN numbers and a billing email address. No payment data was involved. Framework says it rotated its credentials, confirmed no change to admin access and no access to anything outside Metabase, and is reviewing how it stores data with external database vendors.

Tally, a form builder, said its Metabase environment was reached the same day and that email addresses and password hashes were taken. Form definitions and submitted responses sit in a separate database and were not touched. Metabase notified Tally on 6 August; access was cut off that day. Tally told users to change their passwords and turn on two-factor authentication.

The URL was the credential

Metabase's advisory, GHSA-r8h2-qpfx-mx59, has no CVE assigned yet. It describes SQL injection reachable through a publicly shared dashboard or card that uses field-filter parameters. The attacker needs only the public link's UUID, which is by design part of the URL.

That UUID is enough to run arbitrary SQL against the Metabase application database, exposing settings, sessions, API keys and the stored credentials for every data source the instance connects to.

Public sharing is on by default.

Metabase scores the flaw 9.6. It is network-reachable, needs no privileges, and carries a scope change, meaning a compromise does not stay inside the component where it began. Several outlets reported 10.0; the vendor's own advisory says 9.6, and that is the number we have used. Affected releases are v58.0 to 58.23, v59.0 to 59.20, v60.0 to 60.16, v61.0 to 61.10, v62.0 to 62.8 and v63.0 to 63.4. The fixes are 58.24, 59.21, 60.17, 61.11, 62.9 and 63.5. Anything older than 58 was never vulnerable. Credit goes to a researcher named as perivamsi.

Why the BI server is the worst box to lose

Diagram tracing the blast radius: a public Metabase dashboard link, whose URL is the only secret, leads by SQL injection to the application database holding sessions and API keys, which holds every stored data-source credential, which in turn reaches a production replica, a data warehouse, a billing database and a CRM.
The reason a read-only reporting tool is a high-value target: it is the one box in the estate holding a live credential to everything worth reading. RECATOOLS diagram.

A business-intelligence tool is, by construction, the system with a working credential to every database worth querying. That is the job. You connect it to the production replica, the warehouse, billing and the CRM, and then you stop thinking about it, because it is read-only, it is internal, and it is a dashboard.

Read-only is not the property that matters. What matters is that the credentials to reach all of it sit in one place, and a bug that yields admin on that box yields the credentials.

Metabase's own remediation list says as much. After upgrading, it tells administrators to revoke sessions, review API keys, audit admin accounts, rotate the database credentials and read the data-warehouse logs. This is not a patch-and-move-on job. It is the incident response you run when a set of production credentials may be in someone else's hands.

Most threat models file the analytics stack under low value because it does not process transactions. It does not need to. It has the keys.

Framework's customers were never Metabase's customers

Somebody who bought a laptop transacted with Framework. Framework put some of that record into a hosted reporting tool. The tool was compromised, and a home address is now somewhere the buyer has never heard of. There was no consent screen, no vendor page, no way to have known.

This is the part of third-party risk that questionnaires do not reach. Framework can answer for its own security posture and, to a degree, for its vendor's. It cannot answer for a zero-day in that vendor that did not exist when the questionnaire was filled in — and nor can anyone else. The one lever a company holds is how much data it puts into an external database, which is what Framework says it is now examining.

The vendor patched; the customers disclosed

The disclosures themselves are telling.

Metabase's 6 August post, under chief executive Sameer Al-Sakran's byline, is an upgrade notice. It details the flaw, lists the fixed versions and gives remediation steps. It states that Metabase Cloud "was attacked" using a zero-day. It does not tell a reader that data was taken out of customer instances. That emerged through Framework's and Tally's own notifications, and then through reporting.

This is not necessarily evasion. A platform often cannot characterise what happened inside each tenant, and telling affected customers before the internet is the right order to do things in. But the consequence is that the public picture of a platform compromise gets assembled from whichever downstream companies choose to disclose, in whatever detail they choose. Two have. Nobody has said how many instances were reached in total.

Two endpoints, one incident

One thread we could not tie off, and it matters if you are hunting.

The advisory describes the injection arriving through publicly shared dashboards with field-filter parameters. Metabase's blog post, however, gives an indicator of compromise that looks nothing like the advisory's description. It points to a failed POST to /api/session/reset_password returning 400, followed by a successful GET to /api/user/current returning 200, the signature of a session that should not exist.

Those may be the same chain described at two different layers, or the observed intrusion may have taken a path the advisory summarises differently. Metabase has not publicly reconciled them and we are not going to guess. Search your logs for both.

If you self-host

Upgrade to a fixed release, and treat that as the first of six or seven steps rather than the end of the matter. The rest comes from the vendor's own list: revoke all sessions, audit API keys, review who holds admin, rotate credentials for every connected data source, and go through the query and download history for activity you cannot account for.

If you truly cannot upgrade today, the interim measure is to unpublish public links that use field-filter parameters, or turn public sharing off entirely. Be clear-eyed about the cost, which is that every dashboard someone outside your login wall depends on will stop working. That is the trade, and for most organisations it is worth making for a day.

What to watch

Whether a CVE is assigned, and whether anyone publishes a scan of how many self-hosted instances remain exposed — no such count exists yet. For now the scope of exposure is unknown, which is not the same as small.

Whether more downstream companies disclose. Two customers named themselves in four days; platform incidents usually surface for weeks.

And whether Framework's review of what it puts into external databases produces anything specific, because a commitment to review one's methodology for data storage with external vendors is a sentence many companies write after a breach and few return to.