Four companies publicly disclosed data breaches this week because of the same flaw: a SQL injection zero-day in Metabase, the open-source analytics platform a lot of small teams self-host for free to build dashboards on top of their databases.
Framework, Tally, n8n, and Kilo Code all confirmed exposure between August 7 and 9. The attacks started August 2. Metabase didn't disclose until August 6. That four-day window — exploitation running, most users knowing nothing — is where the damage happened.
If you're running Metabase and haven't patched, stop here and go do that first. Patched releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5 (and equivalent 1.x versions). Then come back.
What the Vulnerability Actually Did
The flaw — GHSA-vwf4-m7j8-wcjf / CVE-2026-72898, CVSS 10.0 — lives in Metabase's password reset endpoint: POST /api/session/reset_password. This is the endpoint designed to help you recover access when you're locked out. It requires no authentication by design. And it was accepting arbitrary SQL injection without any sanitization.
An unauthenticated attacker could hit that endpoint, inject SQL, and take over the application database. With admin access, they had everything Metabase stored — including the connection strings and credentials for every database you'd connected to your Metabase instance.
That's the part that matters: Metabase's whole value is that you connect it to your stuff. Your PostgreSQL backend, your MySQL CRM, your BigQuery data warehouse, whatever you're dashboarding. All of those connections, with their stored credentials, are accessible to an admin.
So this wasn't a "your Metabase data got stolen" situation. For any organization that had connected production databases, it was "the credentials to your production databases may be in someone else's hands."
Who Got Hit and What They Lost
Framework (the laptop company popular with technical teams) confirmed attackers accessed customer names, email addresses, phone numbers, and physical addresses. Payment information wasn't exposed, but the customer PII was.
Tally (invoicing software) confirmed email addresses and bcrypt-hashed password records were pulled.
n8n (workflow automation, used heavily by small teams running automated pipelines and AI workflows) confirmed 136 customer records were accessed, including five with bcrypt-hashed passwords.
Kilo Code (an open-source AI coding agent startup, recently acquired by Anaconda) confirmed that the breach exposed Slack access tokens for a subset of users on their Slackbot feature. The incident window at Metabase was roughly four hours on August 2.
None of these are massive enterprises with armies of security engineers. These are exactly the kind of orgs that reach for Metabase in the first place — startups, technical teams, companies that self-host tools to control costs and keep data local. The tool didn't fail them for being bad. It failed because nobody caught a zero-day before attackers did, and self-hosted deployments don't get automatic patches.
Why Self-Hosted Changes the Risk Equation
Metabase's cloud offering was patched rapidly once the vulnerability was discovered. Self-hosted deployments don't work that way.
When you self-host Metabase, you are the one responsible for updates. And most teams that self-host it deploy it, confirm the dashboards work, and don't think about it again. It's running in a Docker container somewhere. There's no visible sign anything is wrong until it isn't.
Security researchers scanning for exposed Metabase instances found thousands of deployments running outdated versions earlier this year. The blast radius on a broadly exploited Metabase zero-day is significant — and unlike most SaaS breaches, the damage doesn't stay contained to the BI tool. It propagates to everything the BI tool connects to.
One more thing worth naming for teams running Metabase internally: "it's not on the public internet" isn't a complete answer. If an attacker gets into your network through any other vector — phishing, a compromised employee device, a different vulnerability — they can reach your internal Metabase. At that point, a CVSS 10 unauthenticated SQLi endpoint is a fast path to everything else on your network.
What to Do
Patch first. Metabase has published the patched versions. Each active release branch (0.58.x through 0.63.x) has a minimum-safe version. Check what you're running and upgrade. If you're managing Metabase through a third party, contact them today — this severity level should get treated as urgent.
Block the endpoint if you can't patch immediately. The Metabase advisory identifies blocking POST /api/session/reset_password at the network or reverse proxy layer as a short-term mitigation. If you're behind nginx or a load balancer, a location block returning 403 for that specific path buys you time to do the upgrade properly.
Rotate your database credentials. Every database you have connected to Metabase: go to that database, generate new credentials, update the connection strings in Metabase. Assume the old credentials may be known. This is the step most teams will skip. It's the one that matters most.
Check your other connected credentials. If you've connected cloud services, APIs, or anything else through Metabase data sources — OAuth tokens, cloud IAM credentials, API keys — review and rotate those too.
Look at your logs. Specifically, look for unexpected POST requests to /api/session/reset_password from unfamiliar IPs during August 2–6. If you see hits, you have a potential incident, not just a patching job. At that point the question is containment and forensics, not just upgrade-and-move-on.
Self-hosted BI tools give small orgs real leverage. Metabase is a genuinely good product — you get dashboards on your own data, no per-seat SaaS costs, and your data stays where you put it. But "self-hosted" means you're also the one responsible for watching the patch queue.
A CVSS 10 zero-day doesn't care how good the tool is.
If you're not sure what data tools and AI tools your team is running, what databases they're connected to, or whether anyone is watching for updates, that's worth sorting out. We cover it as part of our implementation sprints — what's running, what it has access to, and whether the configuration matches the risk you're willing to carry. If that's useful, reach out.