Metabase, the open source analytics platform, disclosed on August 6 that an unauthenticated SQL injection vulnerability had been exploited in the wild since August 3 against customer instances. The Metabase zero-day, rated Critical with a CVSS score of 10.0, let attackers take over analytics servers before a patch was available. Laptop maker Framework, form builder Tally, and customers of some LexisNexis services have all confirmed impacts.

What Happened

Metabase said its Cloud platform was compromised through a previously unknown vulnerability affecting versions 0.58 and above. The company blocked the endpoints used in the attack and rolled out fixes for Cloud and every supported self-hosted branch. Its advisory confirms the flaw has been actively exploited.

The timeline is short. Attackers accessed the affected instances on August 3. Metabase notified Framework on August 6, and Framework emailed customers within six hours of getting the report. That speed stood out in the community discussion: Metabase took about three days from discovery to notifying business partners, and Framework turned its notice around in hours.

The Vulnerabilities

Two GitHub advisories describe the flaws:

Advisory	Vulnerability	CVSS	Access
GHSA-vwf4-m7j8-wcjf	SQL injection through an unauthenticated endpoint	10.0 (Critical)	Remote, no login
GHSA-r8h2-qpfx-mx59	SQL injection via a publicly shared dashboard field filter	9.6 (Critical)	Remote, shared link

The first one lets an unauthenticated remote attacker inject arbitrary SQL into the Metabase application database. From there an attacker can change the application configuration, steal stored credentials for the connected databases, read any data reachable through those connections, and export data.

The second one works through public sharing, which is enabled by default. A publicly shared card or dashboard that exposes a field-filter parameter can be abused with nothing more than the public link UUID, which is part of the shared URL by design.

Who Was Affected

Framework confirmed that customer information was accessed: full name, email address, login IP address, billing and shipping address, phone number, and company name. For Framework for Business accounts, the exposed set adds company name, phone number, VAT, EIN, and billing email. Framework said payment data was not exposed because payments run through Stripe.

Tally told users that its Metabase analytics environment was accessed on August 3. The exposed data includes email addresses and password hashes, which Tally described as one way and not reversible. It said forms and the answers people submitted are stored separately and were not reached.

LexisNexis warned customers that a disruption affecting its Diligence, Metabase API, and Newsdesk products traces back to unusual activity found at a third-party vendor. It disconnected the affected systems and is working with a forensic firm, but has not confirmed whether customer data was exposed.

What This Means for Developers

The pattern is familiar. A single analytics service holds connection credentials for many databases, so a SQL injection in that service reaches further than the tool itself. Legacy BI setups routinely grant the analytics platform broad read access to production data, which turns one vulnerable endpoint into a path to everything the account could query.

Metabase itself is not the only takeaway. Any platform that stores database credentials in its own application database, whether a BI tool, an internal dashboard, or a data pipeline, becomes a high value target the moment it is exposed on the network.

What Should You Do

Upgrade now. Metabase Cloud instances were patched automatically, but self-hosted installs need manual action:

• Upgrade to a fixed version on your release branch: v63.5, v62.9, v61.11, v60.17, v59.21, or v58.24.
• Until you can upgrade, block access to the /api/session/reset_password endpoint as a temporary workaround.
• After upgrading, revoke all active sessions by deleting all rows in the core_session table.
• Review API keys and administrator accounts for changes you did not make.
• Rotate credentials for every database the Metabase instance could reach.

If you publish shared dashboards with field-filter parameters, disable public sharing or unpublish those links until you have patched.

How to Tell If You Were Targeted

Metabase shared a specific log signature for this campaign. Look for a POST request to /api/session/reset_password that returns a 400 status, followed by a successful GET to /api/user/current. If that pair shows up in your logs, treat the instance as compromised and run through the steps above.

Why the Response Matters

The part of this story that caught attention on Hacker News is the disclosure speed. Framework notified customers in six hours, its email was detailed about what was and was not exposed, and it committed to scoping down what it shares with business intelligence platforms to only the columns required for analysis. Community reaction praised the transparency while noting the underlying problem: a third party held more customer data than it needed.

Frequently Asked Questions

Is Metabase Cloud affected? Metabase says Cloud customers were upgraded and patched. Self-hosted installations need a manual upgrade to a fixed version.

Which Metabase versions are patched? The minimum patched releases are v58.24, v59.21, v60.17, v61.11, v62.9, and v63.5.

Was payment information exposed at Framework? Framework says no. Payment processing runs through Stripe, and the stolen data was profile, order, and contact information.

Are Tally password hashes usable by attackers? Tally says the hashes are one way. Even so, if you have a Tally account, reset the password: cracking tools work against real world hashes, and Tally has not disclosed the algorithm or salt usage.

Is this a Metabase Cloud only issue? No. Metabase explicitly warned that self-hosted installations are also vulnerable and must be patched manually.

Key Takeaways

• An unauthenticated Metabase zero-day (CVSS 10.0) was exploited against customers from August 3.
• Framework, Tally, and LexisNexis services were impacted; payment data was not exposed at Framework.
• Patch minimums: v58.24, v59.21, v60.17, v61.11, v62.9, v63.5.
• Block /api/session/reset_password if you cannot upgrade immediately.
• The log signature to hunt: 400 on the reset password endpoint, then a successful GET to /api/user/current.
• Fast disclosure worked, and it is the model other vendors should copy.

Conclusion

The Metabase zero-day breach is a useful case study in third-party risk. You do not have to be the company under direct attack to lose data; you only need to store personal data in a piece of software that gets compromised. Check the fixed versions above, look for the telltale endpoint sequence in your logs, and then ask how much access your analytics platform really needs.

---

Sources: https://www.bleepingcomputer.com/news/security/framework-tally-disclose-metabase-data-theft-attacks/, https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf, https://github.com/metabase/metabase/security/advisories/GHSA-r8h2-qpfx-mx59, https://community.frame.work/t/framework-data-breach-discussion/83939