Metabase zero-day: your BI tool holds every DB password

The dashboard tool nobody thinks about holds a working password for every database in your company. That is the whole story of the Metabase zero-day disclosed on August 7: an unauthenticated SQL injection rated CVSS 10.0 that hands an attacker administrator access to a Metabase instance — and from there, the connection strings to everything behind it.

What actually happened

Metabase's security advisory (GHSA-vwf4-m7j8-wcjf, no CVE assigned) describes a flaw that lets a remote attacker with no credentials inject arbitrary SQL into the Metabase application database. The company's own summary of the impact is the part to read slowly: an attacker can change application configuration, steal stored credentials for connected databases, read any data reachable through those connections, and export it.

Affected releases span the 1.58 through 1.63 branches. Fixed builds are 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9, and 1.63.5.

This was not found in a lab. Metabase says it identified the bug because Metabase Cloud was attacked with it on August 3, notified customers on August 6, and went public on August 7.

The downstream disclosures landed the same week. Laptop maker Framework told all customers their data was accessed through the breach of its business intelligence provider: names, email addresses, login IP addresses, billing and shipping addresses, phone numbers, and company names. Business accounts also exposed VAT and EIN numbers. Payment and order data was not included. Framework's spokesperson confirmed the scope as "all customers" and declined to give a number. Form builder Tally disclosed separately, per BleepingComputer.

Why a BI breach matters more than the CVSS score

Patch urgency is the easy lesson. The harder one is architectural: a BI tool is a credential vault that nobody classifies as one. You point it at production Postgres, the warehouse, Stripe, maybe a replica of your CRM. Every one of those connections is a stored secret sitting inside a web application you exposed so the ops team could look at charts.

So patching is step one of four, and steps two through four are the ones teams skip. Rotate every database credential Metabase held — the patch closes the door, it does not un-steal what already left. Revoke active sessions and audit API keys, because admin access means the attacker could mint their own. Pull access logs for the window starting before August 3 and look at what was queried, not just who logged in.

And then ask the question that outlives this bug: which of those connections needed write access, or production access, at all? A reporting tool should read a replica with a scoped, read-only role. Most don't, because the fastest path to a working dashboard is the admin credential someone already had.

Sources: Metabase security advisory, TechCrunch, BleepingComputer.