Metabase zero-day (CVSS 10.0): unauthenticated SQL injection hands attackers admin and data. Patch now.

The headline damage from the Metabase zero-day is the customer data attackers walked off with. The bigger problem is what a Metabase admin account can reach next. Metabase is the console that queries your databases, so it holds a stored credential for every one of them. An unauthenticated flaw that ends in admin does not just expose the dashboards. It exposes the keys to the systems behind them.

On August 7, Metabase disclosed that a maximum-severity vulnerability in its business-intelligence software, tracked as advisory GHSA-vwf4-m7j8-wcjf with a CVSS score of 10.0, had been exploited as a zero-day. Chief executive Sameer Al-Sakran described it as an unauthenticated SQL injection that ends in full administrator control of the instance for a remote attacker. Attacks were observed from August 3. PC maker Framework and form builder Tally have confirmed stolen data, and LexisNexis said it disconnected affected systems while it assesses exposure.

What the flaw is and who is exposed

This is not the classic read-one-table SQL injection. According to Metabase, the injected SQL runs against the application's own database, and from there an attacker can escalate to an administrator account inside the instance. Admin in Metabase means changing configuration, reading saved data, and pulling the connection credentials for every wired-in data source. No login is required to start the chain, which is what pushes the severity to the ceiling.

The flaw affects version 1.58 and later on the enterprise builds, and the matching 0.58 and later open-source releases. Each branch has its own fix, so match your branch to its build: a 1.58 install goes to 1.58.24, a 1.63 install to 1.63.5, and the branches in between as listed.

Metabase Cloud instances were patched by the vendor. Self-hosted deployments have to update themselves, and that is where the exposure concentrates.

The blast radius is your connected databases

Every data source you wire into Metabase leaves a credential behind so the tool can run queries for you. A production Postgres warehouse, a read replica of your billing database, a Snowflake account: whatever Metabase can query, it stores a way in. When SQL injection escalates to admin, those saved connections become readable, and the incident stops being about one analytics tool. It becomes a route into every system Metabase was trusted to reach.

That is why "rotate your database credentials" is the line that matters most here, and why it has to reach past Metabase's own application database to every source it connects to. We have watched this shape before, where the admin console for data is the real target rather than the data itself: a SQL injection in ERPNext that exposed stored passwords, and a database sidecar bundled with Splunk that handed attackers root. The tool that sees everything is worth more than any single table it queries. Treat the stolen-credential risk the way the Snowflake credential-theft campaign should have taught the industry to: assume the reused secret is already gone.

How do you tell if you were hit?

Metabase published a log signature for the exploitation, and it is specific enough to hunt directly. The pattern is a POST to /api/session/reset_password that returns a 400 status, immediately followed by a successful GET to /api/user/current returning 200, from the same source. Each request on its own is unremarkable; the sequence is the tell. Correlate the two by source address within a short window across your Metabase ingress and application logs, and treat any match on a vulnerable, internet-facing instance as a likely compromise rather than a coincidence.

Patching closes the hole. It does not tell you whether someone came through it first. Any self-hosted instance that was internet-reachable on a vulnerable version between August 3 and the day you patched should be handled as assume-breach, not simply updated and forgotten.

Patch, then hunt: what to do today

The order matters, because the second half is the part most teams will skip.

• Update now to the fixed release for your branch, listed above. If you cannot patch immediately, blocking the /api/session/reset_password endpoint at your proxy is a stopgap, but it only stops new attempts and does nothing for an instance already touched.

• Rotate every connected credential. Change the database passwords and API keys for every source Metabase queries, not just Metabase's own application database. Revoke active sessions and reset Metabase API keys after upgrading.

• Hunt the two-request signature in your logs back to August 3, and review admin activity, new user accounts, and configuration changes for anything you did not make.

Self-hosted analytics has an uncomfortable property: the instance least likely to be watched is often the one sitting inside the network with the richest connections. This zero-day rewards exactly that population. If you run Metabase where it can be reached, the clock started on August 3, and the useful question now is not whether you patched, but whether you assumed breach while you did.