Metabase Zero-Day: Framework and Tally Data Stolen
Metabase has confirmed that attackers exploited a previously unknown, unauthenticated SQL injection flaw against real customer environments. The vulnerability carries a maximum CVSS score of 10.0 and can turn one public password-reset endpoint into administrator access to a Metabase instance. Framework and Tally are among the customers reported to have confirmed data theft.
This is not a proof of concept, a scanner sighting or a criminal claim. Metabase says its own Cloud service was attacked, the vendor confirmed active exploitation, and affected customers received incident reports describing activity in their instances. The patch exists now. The useful question is no longer whether the bug is exploitable, but whether an exposed instance was reached before it was patched.
What the zero-day allows
The advisory, currently tracked as GHSA-vwf4-m7j8-wcjf with no CVE assigned, describes a pre-authentication SQL injection in the Metabase application database. No account and no user interaction are required. A remote attacker can inject arbitrary SQL and use that access to become a Metabase administrator.
That distinction between the application database and a connected data warehouse sounds comforting until you follow the trust chain. The application database contains the configuration and credentials Metabase uses to reach its connected databases. Administrator access can therefore expose stored connection credentials, permit configuration changes, and let the attacker query or export whatever those database accounts are allowed to read.
Metabase is an analytics layer, so broad read access is often the entire reason it was deployed. The product does not need a separate database vulnerability when the legitimate service account already has access to customer, finance or operational data. Compromising the analytics control plane can be enough.
Affected and fixed versions
Metabase says releases before version 58 are not affected by this specific flaw. Both open-source and Enterprise release lines from 58 through 63 require a patched point release. The minimum safe versions are:
0.58.24/1.58.240.59.21/1.59.210.60.17/1.60.170.61.11/1.61.110.62.9/1.62.90.63.5/1.63.5
Metabase Cloud instances have already been upgraded. Self-hosted deployments must be updated by their operators. If an immediate upgrade is genuinely impossible, the vendor's temporary workaround is to block /api/session/reset_password at the reverse proxy or load balancer. That is a short bridge to patching, not a permanent fix.
The detection pattern is unusually specific
Metabase published a concise log sequence associated with the observed attacks:
- A
POST /api/session/reset_passwordrequest returns HTTP 400. - A subsequent
GET /api/user/currentrequest returns HTTP 200.
The first response can look like a failed request. The second shows that the caller obtained an authenticated user context anyway. Metabase says finding this sequence in application or ingress logs likely means the instance was compromised. Searching only for successful password-reset requests will miss it.
Preserve the raw ingress, application, identity and database logs before rotating or rebuilding anything. A clean server after remediation is useful for recovery; an intact timeline is what tells you which credentials and datasets must be treated as exposed.
What Framework and Tally change about the story
The Framework disclosure reportedly covers customer names, email addresses, phone numbers and billing or shipping addresses, while excluding order and payment data. Framework said it rotated credentials for databases connected to its Metabase instance and began reducing the breadth of data shared with analytics platforms. Tally also disclosed unauthorized access connected to the Metabase incident.
Those disclosures matter because they demonstrate the second half of the exploit chain: administrator access was not merely possible; attackers used affected customer instances to reach data behind them. They also expose the architectural lesson. An analytics platform should query views built for analytics, not inherit a standing credential that can read every column in a production customer database.
Incident-response checklist
- Upgrade first. Confirm the running container or JAR version, rather than assuming a deployment pipeline pulled a new mutable tag.
- Hunt for the published request sequence. Search reverse-proxy, WAF and Metabase logs for the HTTP 400 reset request followed by an HTTP 200 current-user request.
- Revoke every active session. Metabase instructs operators to delete all rows from
core_sessionin the application database. - Review administrators and API keys. Remove unknown accounts, unexpected privilege changes and unrecognized keys.
- Rotate connected-database credentials. Do this even if the Metabase host itself looks clean; those credentials were inside the compromised trust boundary.
- Review warehouse query and export history. Look for unusual tables, broad selects, large result sets and activity outside normal schedules.
- Reduce future blast radius. Replace broad production access with least-privilege, read-only analytics views; exclude credentials, recovery tokens and unnecessary personal fields entirely.
If secrets were exposed, rotation is only the beginning. Our credential leak response playbook covers containment, evidence preservation and verification after rotation.
The lesson is the reachable data, not the dashboard
The patch closes one endpoint. It does not change the more durable risk: business intelligence systems concentrate access. They sit between friendly dashboards and the databases everyone is trying to protect, often with credentials that live for months and permissions that grow over years.
Treat Metabase and similar analytics platforms as privileged infrastructure. Keep them off the public internet where possible, monitor their control-plane actions, give every connection its own narrow database role, and make exports observable. A dashboard compromise should become a contained incident, not a universal query interface for an attacker.