Metabase Zero-Day Hit Framework and Tally Before Anyone Had a Patch

A Metabase SQL injection vulnerability let attackers walk into customer databases with no login at all. Two companies have already confirmed data loss. Metabase disclosed the flaw on 7 August. It rates a maximum 10.0 on the CVSS scale. Attackers found and used it before the vendor even knew it existed.

The bug sits in the /api/session/reset_password endpoint. An unauthenticated attacker can inject SQL into Metabase’s own application database. That hands them admin access to the instance. From there they can change the configuration, pull out the credentials Metabase stores for every connected data source, and read or export whatever those connections can see.

What happened, in order

Metabase Cloud was breached on 3 August, before any patch existed. Tally, an online form builder, uses Metabase for analytics. Its environment was hit the same day. Metabase told Framework, the laptop maker, on 6 August once it traced the damage. The company went public with the advisory on 7 August, and coverage has continued since.

So this was not a flaw quietly patched after disclosure. It was live and being used against real customers first, then fixed. That sequencing matters for anyone deciding how urgently to act.

Who has lost data so far

Framework confirmed that customer names, email addresses, login IP addresses, billing and shipping addresses, phone numbers and company names were accessed. Business customers also had VAT numbers, EIN numbers and billing emails exposed.

Tally said attacker access covered user email addresses and password hashes. It described the hashes as one-way cryptographic, not plaintext. LexisNexis was also affected, through a third party that hosted its data on Metabase. It has not yet confirmed whether customer records were exposed, and the investigation continues.

None of these firms run small operations. If a Metabase SQL injection vulnerability this severe can reach their systems, it can reach a mid-sized business with fewer resources to notice.

Which Metabase versions carry the SQL injection vulnerability

Self-hosted Metabase releases in the 58 through 63 branches carry the flaw, across both the open-source and Enterprise editions. Metabase has shipped fixes at .58.24, .59.21, .60.17, .61.11, .62.9 and .63.5. Metabase Cloud customers were patched automatically. They do not need to act on the version itself, though the post-incident checks below still apply if an instance shows signs of compromise.

Metabase’s own advisory sets out how to spot an already-compromised instance. Look for a POST request to /api/session/reset_password that returns a 400 status code, followed by a GET request to /api/user/current that returns 200. Chief executive Sameer Al-Sakran put it plainly: “If you find that pattern in your application logs or in your Metabase server ingress logs, it is likely that your instance has been compromised.”

Not the first maximum-severity Metabase flaw

This is not Metabase’s first brush with a critical bug. In July 2023, Metabase had another maximum-severity flaw, tracked as CVE-2023-38646. It let attackers abuse a leftover setup token to run commands on the server with no login needed. Research published in March this year found the aftermath still lingering. A Shodan scan found more than 17,000 public Metabase instances. Many still ran versions from before that 2023 fix.

That gap between disclosure and actual remediation is the pattern worth noting. A patch existing does not mean a firm applied it. That gap took two and a half years to close last time. Expect this week’s fix to lag the same way, unless someone checks.

Why the Metabase SQL injection vulnerability matters

Business intelligence tools like Metabase sit behind the firewall at most firms. They connect directly to production databases so staff can build dashboards without asking IT for a data export. That convenience is exactly what makes a flaw like this so damaging once an attacker gets in. The tool already holds the keys to everything it reports on.

Many teams treat BI platforms as internal furniture. They forget these tools need the same patching discipline as a public-facing web application. This incident shows why that distinction does not hold. Metabase was reachable and valuable enough to be worth a zero-day.

What to do now

The Metabase SQL injection vulnerability is easy to act on. Anyone running self-hosted Metabase in the affected range should upgrade to the patched release now. Where an upgrade cannot happen straight away, block the /api/session/reset_password endpoint at the network or WAF level. Treat that as a stopgap, not a substitute for patching.

After upgrading, treat the instance as potentially compromised until proven otherwise. Clear the core_session table to revoke active sessions. Review and remove any API keys you do not recognise. Audit admin accounts for ones that should not exist. Rotate the credentials for every connected database, and check query history and access logs for the IOC pattern above.

It is worth widening the check beyond Metabase itself. Any internal analytics or reporting tool with database credentials baked in is a similar prize for an attacker. Few firms have an inventory of exactly what those tools can see, which is exactly why the Metabase SQL injection vulnerability is worth treating as a wake-up call rather than a one-off.