The Metabase Zero-Day: What a CVSS 10.0 Breach Teaches Website Owners About Forgotten Tools

On August 3, 2026, attackers exploited an unknown flaw to breach Metabase's own cloud platform — and rode it straight into customer databases at laptop maker Framework and form builder Tally. The vulnerability didn't have a name yet, and the company that makes the software didn't know about it either. Four days later, it was public: a perfect 10.0-rated flaw, already being exploited in the wild.

This is the story of that breach, and the one lesson every website owner should take from it: the tools you self-host are part of your website's security, whether you remember them or not.

What happened

Metabase is a free, open-source analytics tool that thousands of small businesses run to build dashboards from their data. It's the kind of software someone installs "on a quiet Friday" — free, easy to set up, and then quietly forgotten while it keeps holding something valuable: the connection credentials for the databases it reports on.

On August 7, Metabase disclosed that its Cloud platform had been attacked, starting around August 3, through a previously unknown vulnerability — a zero-day. The flaw is an unauthenticated SQL injection in the password reset flow. In plain terms: an attacker with no login credentials could inject commands into the application's database, take over the administrator account, change the configuration, steal the stored credentials for every connected database, and export the data those databases could reach.

The severity rating is the maximum possible: CVSS 10.0. As of disclosure, the flaw had no CVE identifier yet — it's being tracked under an advisory ID (GHSA-vwf4-m7j8-wcjf) instead. That matters practically: automated security scanners that only check against the official CVE database won't flag an exposed instance until one is assigned. If you're relying on a scanner alone, this is exactly the kind of gap it can miss.

Three companies have so far confirmed impact:

• Framework, the laptop maker, told customers that names, email addresses, billing and shipping addresses, phone numbers, and company data were stolen from its Metabase instance.
• Tally, the online form builder, confirmed its analytics environment was compromised — customer email addresses and password hashes were taken (its forms and submitted answers are stored separately and were not reached).
• LexisNexis reported service disruptions after unusual activity at a third-party vendor hosting Metabase on its behalf, and disconnected the affected systems while it investigated.

Framework and Tally were both hit through Metabase's own Cloud SaaS platform — meaning the breach happened at the vendor's end, not because either company forgot to patch something. Metabase has since confirmed it blocked the malicious endpoints and pushed a fix, and every Metabase Cloud customer was patched automatically.

Self-hosted instances got no such rescue. Metabase shipped fixed versions for self-hosted users too, but applying them is entirely down to whoever runs the instance — which is exactly the population that usually doesn't have a scheduled patch window for a tool most people forgot was internet-adjacent.

Why this matters to website owners

There are two separate lessons buried in this one incident, and both apply even if you've never heard of Metabase.

1. Even the vendor can get zero-dayed. Metabase Cloud is the "someone else handles the security" option — and it still got hit by a flaw nobody knew existed. That's not a knock on Metabase; zero-days happen to well-run software too. But it's a reminder that "we pay for the managed version" reduces risk, it doesn't eliminate it.

2. If you self-host, you are the vendor. When a flaw is found in a cloud service, the provider patches everyone at once — which is what happened for Metabase Cloud customers here. When you run the software yourself, nobody is doing that job for you: not the vendor, not your hosting provider, not your developer, unless you specifically asked them to. The fix for this flaw existed within days of disclosure. The open question for every self-hosted install is simply: who applies it, and when?

Both lessons point at the same blind spot: every website owner has a version of this story somewhere — a free analytics dashboard, a booking widget, an admin panel, a monitoring script — installed once, working fine, and then nobody's job. These tools sit next to your website, sometimes on the same server, often holding the same database credentials your shop runs on. They are not "just a dashboard." They are a second front door, and the attacker in this case didn't need to break into the database directly — they logged in through the reporting tool that was already allowed to.

If you work with an agency or developer, this applies too: the person who manages your site may be running analytics or admin tools on your behalf. It's a fair question to ask — what runs on our servers, and who patches it?

What to do

If you run a self-hosted Metabase instance: update to the patched version for your branch (0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5 — whichever applies). If you genuinely can't update this week, the vendor's temporary workaround is to block access to the /api/session/reset_password endpoint. That is a stopgap, not a fix.

Patching is only half the job. Metabase published a specific signature for the attack: a POST to /api/session/reset_password returning an HTTP 400 status, followed by a successful request to /api/user/current. If your logs show that pairing, treat the instance as compromised. The vendor also recommends revoking all active sessions, reviewing API keys and administrator accounts, rotating the credentials for every connected database, and reviewing query history for anything unexpected.

If you use Metabase Cloud: you don't need to patch anything yourself — that's already been done. It's still worth reviewing your Metabase user accounts and connected database credentials as a precaution, since the exploitation window predates the public disclosure.

For everyone else: the actionable version of this story is an inventory. List the tools you run that aren't your website — dashboards, analytics, booking systems, email tools, anything that connects to customer data. Next to each one, write down whether it's self-hosted or managed by a vendor, and who updates it and when it was last updated. If a self-hosted tool has no owner, it's a risk — not because it's malicious, but because when a 10.0-rated flaw comes out, nobody will be standing by to patch yours.

And when a serious vulnerability is announced — regardless of which tool it affects, and regardless of whether it has a CVE number yet — treat patching as a this-week task, not a this-quarter task. The gap between "patch available" and "exploited in the wild" is measured in days.

Key numbers

Final takeaway

A perfect-10 vulnerability was exploited for days before anyone knew it existed — and it hit companies with real customers and real reputations, through both a managed cloud platform and (potentially) self-hosted installs. The defense isn't exotic. It's knowing what runs on your servers, knowing whether you or someone else owns the patching for it, and moving fast when a fix ships. Your website's security isn't just your website.