On 3 August 2026, attackers exploited a previously unknown, unauthenticated SQL injection in Metabase — starting with Metabase's own Cloud SaaS platform. Framework and Tally, both Metabase Cloud customers, confirmed customer data theft after Metabase notified them on 6 August that their instances had been accessed. Metabase disclosed the zero-day on 6 August with a CVSS 10.0 rating and confirmed active exploitation — before any CVE was assigned (the advisory ID is GHSA-vwf4-m7j8-wcjf).
The vulnerability
- Advisory: GHSA-vwf4-m7j8-wcjf (GitHub Security Advisory). No CVE at disclosure — scanners that only track the CVE/NVD feed won't flag an exposed instance until one is assigned.
-
Type: unauthenticated SQL injection, reachable through the password reset flow (
/api/session/reset_password) - Impact: arbitrary SQL into the Metabase application database → full administrator access → change application configuration, steal stored credentials for connected databases, read any data reachable through those connections, export data
- Affected: self-hosted branches 0.58 through 0.63; Metabase Cloud was patched automatically for all customers
Minimum safe releases:
| Branch | Minimum safe version |
|---|---|
| 0.58 | 0.58.24 |
| 0.59 | 0.59.21 |
| 0.60 | 0.60.17 |
| 0.61 | 0.61.11 |
| 0.62 | 0.62.9 |
| 0.63 | 0.63.5 |
Temporary workaround if you can't upgrade immediately: block access to /api/session/reset_password. Stopgap, not a fix.
Cloud vs. self-hosted: read this twice
The confirmed victims — Framework and Tally — were Metabase Cloud customers. The breach happened at the vendor's end: attackers got into Metabase's managed platform, then into customer instances. Nobody at Framework or Tally "forgot to patch" anything; Metabase patched every Cloud customer automatically.
That's the part that should worry self-hosted operators more, not less. The same flaw is present in every self-hosted install from 0.58 to 0.63 — and for those, you are the vendor. The fix shipped within days of disclosure; applying it is entirely on whoever runs the instance.
A word of caution on attribution: you may see other outlets mention LexisNexis alongside Framework and Tally as a third victim. LexisNexis did disclose a service disruption at a third-party vendor around the same time, affecting something it calls "Metabase API" — but that's LexisNexis's own news-aggregation product, a completely separate piece of software that happens to share the name. LexisNexis itself has not confirmed any link to this vulnerability. Worth flagging as a reminder to double-check attribution during a fast-moving incident, but not something to repeat as fact.
Compromise signature (check your logs)
Metabase published the attack indicator: a POST to /api/session/reset_password returning HTTP 400, followed by a successful GET to /api/user/current. If your logs show that pairing, treat the instance as compromised — patching alone is not enough.
Post-compromise cleanup per the advisory:
- Revoke all active sessions — delete every row in the
core_sessiontable - Review API keys; remove any you don't recognize
- Review administrator accounts for unexpected changes
- Rotate credentials for every connected database
- Review data-warehouse logs for unauthorized access
- Review Metabase activity and query history
The pattern to internalize
This is another incident where an unauthenticated, remotely reachable flaw in a tool — not the main application — became the entry point to a database the tool was allowed to reach. Cloud users got patched for them; self-hosted users had to move within days. If you run any self-hosted tool that holds database credentials, version-check it this week — and don't assume your scanner will tell you first, because until this one gets a CVE, CVE-feed scanners won't know it exists.
Sources: BleepingComputer · Metabase advisory · Metabase security update · SecureInSeconds
Full prevention-focused version: WardenBit
Top comments (0)