CRITICAL: Metabase CVSS 10.0 Zero-Day Exploited to Breach Framework and Tally

There are bad weeks, and then there is learning about your own zero-day because somebody already used it on your customers.

That is roughly where Metabase found itself during the first week of August. The company behind one of the most widely deployed open source business intelligence platforms disclosed a maximum severity flaw that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database and come out the other side holding administrator access to the instance. The advisory rates it CVSS 10.0, which is the scoring system's way of admitting there is nothing left to deduct points for. No authentication, no user interaction, no elevated privileges, no local access. A network path to the login page is the entire prerequisite.

Metabase did not find this one in a code review. It found it because attackers were already running it against Metabase Cloud, and by the time the advisory went out at least two companies had confirmed customer data walking out the door.

The missing CVE

Here is the detail that deserves considerably more attention than it is getting. At the time of writing there is no CVE identifier for this vulnerability. The advisory is tracked as GitHub Security Advisory GHSA-vwf4-m7j8-wcjf and nothing else.

That sounds like bookkeeping trivia until you remember how most vulnerability management programs actually function, which is that a scanner ingests NVD data, matches CVE identifiers against a software inventory, and generates tickets. No CVE means no NVD entry, which means no scanner finding, which means no ticket, which means nobody patches. A CVSS 10.0 bug under confirmed active exploitation is currently invisible to the exact machinery most organizations rely on to tell them what to fix. If you are running Metabase, the thing that saves you here is a human being reading a vendor advisory, not a dashboard turning red.

What actually breaks

The flaw sits in the password reset flow. The endpoint at /api/session/reset_password mishandles input in a way that lets an attacker smuggle SQL into a query that runs against Metabase's own application database.

That is an important distinction and it is worth slowing down on. This is not SQL injection against the data warehouse Metabase happens to be pointed at. It is injection against the internal database Metabase uses to store users, permissions, saved questions, and, critically, the connection credentials for every single data source the instance talks to.

Once an attacker can write to that database, promoting themselves to administrator is trivial. From an admin session everything else follows naturally. They can change the application configuration, dump stored credentials for every connected database, query anything those credentials can reach, and export the results through Metabase's own entirely legitimate download functionality. The exfiltration tooling ships with the product. An attacker who owns a Metabase instance does not need to bring malware along, they just need to know where the export button lives.

That is what makes this class of compromise genuinely ugly for incident response. The malicious traffic looks like business intelligence, because it is business intelligence. Somebody running large queries and pulling down CSV files out of an analytics platform is not an anomaly, it is Tuesday.

Versions and patches

Everything from 1.58 onward is affected, across both the self-hosted distribution and Metabase Cloud. Anything below 1.58 is not vulnerable, which is a rare case of technical debt quietly paying a dividend.

Metabase shipped a patched point release on every supported branch rather than forcing anyone into a major version upgrade, so the fixed builds are 0.58.24 for the 58 line, 0.59.21 for 59, 0.60.17 for 60, 0.61.11 for 61, 0.62.9 for 62, and 0.63.5 for 63. Cloud customers were upgraded by Metabase directly and need to do nothing. Everyone running self-hosted is on their own, and that is the population that matters here, because Metabase's entire appeal is that you can stand it up yourself next to your own data.

If you cannot patch within the next few hours, block /api/session/reset_password at the reverse proxy or WAF. It costs you self service password resets and absolutely nothing else. That is a trade worth making for an afternoon.

Who got hit

Framework, the modular laptop manufacturer with an unusually devoted customer base, confirmed that attackers reached customer data through its Metabase instance on August 3. The exposed records included full names, email addresses, phone numbers, billing and shipping addresses, company names, and login IP addresses. No payment data, which is the one piece of good news in the paragraph, but that particular combination is a phishing kit assembled and gift wrapped. Framework customers are technical, they are enthusiastic, and they are now a verified list with confirmed shipping addresses. Fraudulent delivery notifications are the obvious next act.

Tally, the online form builder, disclosed a compromise on the same date involving email addresses and password hashes. LexisNexis has also been named in connection with the campaign as a third party impact and pulled systems offline while investigating.

Three organizations, one common denominator, all landing on the same day. That is not opportunistic internet scanning that happened to get lucky. That is somebody working a target list with a reliable exploit and a plan.

Detection and response

Metabase published a clean indicator, and it is refreshingly specific for once. Search your access logs for a POST request to /api/session/reset_password that returned a 400 status code, immediately followed by a successful GET request to /api/user/current returning 200. That sequence is the exploit signature. A failed password reset has no business producing a valid authenticated session half a second later. If you find that pattern, treat the instance as compromised and proceed on the assumption that every credential stored inside it is burned.

That last part is the piece people will want to skip, and they absolutely should not. Rotating the Metabase admin password accomplishes nothing if the attacker already dumped the connection strings for your production Postgres, your Snowflake warehouse, and whatever else the analytics team wired up over the past two years. Those credentials lived in the application database. Assume they left with everything else. Rotate every data source credential the instance held, then go review query logs on the connected systems for the window between the start of August and whenever you actually patched.

While you are in there, check whether new administrator accounts appeared, whether existing accounts were quietly elevated, and whether any SSO or authentication settings changed. An attacker holding configuration access has far better persistence options available than leaving a password behind and hoping nobody notices.

What to do today

Patch to the appropriate point release, and do it today rather than during the next maintenance window. Block the password reset endpoint in the meantime if patching genuinely has to wait for a change approval. Hunt the log signature across your full retention period rather than just the last week, because active exploitation predates disclosure by definition and nobody knows yet how far back this one goes. Rotate every credential the instance stored.

And if your Metabase is reachable from the open internet, this is a reasonable moment to ask why that is the case. Business intelligence platforms hold the keys to every database in the organization by design. They belong behind a VPN or an identity aware proxy, not sitting on a public IP address with a friendly login form and a password reset link.

The broader lesson is the one about CVE identifiers, and it will keep repeating until people internalize it. Vulnerability management that consumes only NVD feeds is going to keep missing the things most likely to hurt you, because the worst bugs get disclosed under emergency conditions where CVE assignment is the paperwork that happens after the fire is out. Vendor advisories, GitHub Security Advisories, and vendor mailing lists are not optional supplements to a scanner. They are the part that catches what a scanner structurally cannot.

The MSP angle

This one writes its own sales conversation. Any client running a self-hosted analytics platform exposed to the public internet is a live demonstration of why external attack surface review and credential rotation belong on a monthly retainer instead of a one time project quote. The stronger upsell is vulnerability intelligence that reaches past CVE feeds, because a client whose scanner reported a clean bill of health this week while a CVSS 10.0 zero-day sat unpatched in their stack now understands that gap in terms they can actually feel.