Business intelligence tools get treated as harmless. They are "just reporting" — read-only, internal, nobody's crown jewels. So they get stood up quickly, given a public hostname so the sales lead can check numbers from a hotel, and then forgotten.
That framing is wrong, and the Metabase zero-day disclosed on 6 August is the clearest possible demonstration of why. A BI dashboard is not a viewer. It is a service that stores working credentials for every database you have connected to it. Compromise the dashboard and you do not get a screenshot of a chart. You get the keys.
What happened
Metabase disclosed that its hosted platform, Metabase Cloud, had been attacked by someone using a previously unknown vulnerability. The flaw is an unauthenticated SQL injection: a remote attacker with no account, no password and no prior access can inject arbitrary SQL into the Metabase application database and escalate to administrator on the instance.
It carries a CVSS score of 10.0 — the maximum — and, unusually, no CVE identifier at all. That matters practically: if your vulnerability management process keys off CVE feeds, this one may simply not appear in it.
From administrator, Metabase's own advisory says an attacker can change the application configuration, steal the stored credentials for connected databases, read anything reachable through those connections, and export it. The dashboard becomes a pivot into the data warehouse behind it.
The exploited endpoint is /api/session/reset_password, which is publicly reachable by design on most installations.
Two victims, already confirmed
Framework, the modular laptop maker, told customers that Metabase notified it on 6 August that its instance had been vulnerable and was accessed on 3 August. The stolen data includes full names, email addresses, login IP addresses, billing and shipping addresses, phone numbers and company names. Business customers may additionally have had VAT and EIN numbers and billing email addresses taken. Framework says no order or payment information was reached.
Tally, the online form builder, said its Metabase analytics environment was compromised on the same day, 3 August. Attackers reached user email addresses and passwords stored as cryptographic hashes. Tally states that forms and the answers submitted to them live in separate storage and were not touched. BleepingComputer asked Tally which hashing algorithm was used and whether the hashes were salted; at the time of publication it had not received an answer. Until that is clarified, treat the strength of those hashes as unknown rather than assuming the best case.
Note the pattern in both disclosures: neither company was breached through its own product. They were breached through the analytics layer sitting beside it.
If you run Metabase, do this today
Metabase Cloud instances have already been upgraded by the vendor. If you self-host, nothing has happened automatically and you are still exposed.
The minimum safe releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5. Anything below the fix on your branch is vulnerable. Enterprise builds carry the matching 1.x numbering.
If you genuinely cannot patch in the next few hours, block access to /api/session/reset_password at your reverse proxy or firewall as a temporary measure. That is a stopgap, not a fix.
Patching is the easy half. Because exploitation was happening before the patch existed, you have to assume the possibility of prior compromise and clean up after it. Metabase recommends the following, and all of it is worth doing:
- Revoke every active session by deleting all rows in the
core_sessiontable of the Metabase application database. Stolen sessions survive a patch; they do not survive this. - Review API keys and delete any you do not recognise.
- Review administrator accounts for accounts or permission changes nobody remembers making.
- Rotate the credentials for every connected database. This is the step people skip and the one that matters most — the whole point of the attack was to harvest them.
- Review your data warehouse logs for query activity that did not come from a person.
- Review Metabase's own activity and query history for the same.
There is a usable indicator of compromise. In your application or ingress logs, look for a POST /api/session/reset_password returning HTTP 400, immediately followed by a GET /api/user/current returning HTTP 200. Metabase's CEO Sameer Al-Sakran has said that if you find that pattern, the instance was very likely compromised. It is a simple enough signature to grep for, and worth checking even if you have already patched.
The part that outlives this bug
Metabase will be fixed and forgotten in a fortnight. The condition that made it damaging will not be.
Internal tools reach the internet far more often than teams believe. It happens through ordinary, defensible decisions: a cloud load balancer that defaults to public, a firewall exception for a contractor that was never removed, a staging instance stood up during onboarding and never decommissioned, a Kubernetes ingress that quietly published a service somebody assumed was cluster-internal. Nobody made a bad decision. The exposure accumulated anyway.
And the tools this happens to are the worst possible candidates for it: BI dashboards, admin panels, log viewers, CI servers, database GUIs. They are chosen precisely because they have deep access to everything else.
So the useful question after a week like this is not "have we patched Metabase". It is "what else of ours is answering on the public internet that we never intended to publish".
Answering that honestly is harder than it sounds, because you cannot inventory it from the inside. An internal asset list tells you what you meant to deploy. It does not tell you what a stranger can reach. The only reliable method is to look at your own address space the way an attacker does — enumerate what actually responds, on every port, from outside your network — and compare that against the list of things you expected to find. The gap between the two is your real attack surface.
That gap is where this class of incident lives, and it is exactly what ClickScan checks for.
If you use Metabase, patch it and rotate those database credentials today. Then spend an hour finding out what else is listening.
Sources: Metabase security advisory (GHSA-vwf4-m7j8-wcjf) and the Metabase security update; BleepingComputer, 7 August 2026; The Hacker News, 8 August 2026. Victim details are as reported by Framework and Tally in their own customer notifications.