Metabase SQLi zero-day: how password reset exposed a path to data

Metabase has published emergency fixes for a critical SQL injection vulnerability that was already being exploited as a zero-day. The flaw affected an unauthenticated password-reset endpoint and allowed an attacker to manipulate a query against the Metabase application database. That database holds platform configuration, user accounts and connections to data sources, so the impact was not limited to a login failure: the entire analytics layer could be exposed.

Incidents disclosed by Framework and Tally illustrate the architectural risk. A public BI panel frequently sits between the internet and multiple internal databases. Once an attacker controls Metabase itself, they inherit its position as a trusted intermediary, its stored connection material and the privileges assigned to service accounts.

How the attack chain worked

The vulnerable path was POST /api/session/reset_password. Client-controlled data reached a SQL query against the application database without a safe separation between query code and values. The Metabase project advisory assigns the issue the highest severity and says prior authentication was not required.

The practical chain did not stop at reading one table. Access to the application database could expose settings, administrative accounts, and encrypted or stored connection secrets. An attacker could then use Metabase features to query connected warehouses, subject to the privileges of each database account. Least privilege for BI connectors is therefore an impact-limiting security control, not merely administrative tidiness.

Reported traces included a password-reset request that returned HTTP 400, followed by a successful GET /api/user/current. A 400 response alone does not prove that the attempt failed. Detection has to correlate requests into sessions and identify a change in authentication state.

Versions that must be upgraded

Metabase says releases from the 0.58 line are affected, together with corresponding Enterprise 1.x releases. Fixed community versions are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5; Enterprise users should install the matching 1.x release. The live list remains in the Metabase security update.

Framework reported attacker access on August 3 and said it learned of the vulnerability on August 6. Tally described a separate incident involving email addresses and password hashes. These are public examples involving the same class of flaw, not evidence that every Metabase installation was breached.

Technical response plan

1. Upgrade Metabase to the fixed release in your current branch and verify the running version in every environment, not only the container registry.
2. Remove public access to the panel where it is unnecessary; a WAF rule may reduce exposure but cannot replace the patch.
3. Search proxy and application logs for requests to /api/session/reset_password, especially 400 responses correlated with a later /api/user/current call.
4. Invalidate administrator sessions and rotate the application encryption secret according to vendor guidance.
5. Rotate passwords, tokens and keys for every database reachable through Metabase. Changing only the BI administrator password does not revoke stolen connector credentials.
6. Review query history, new users, role changes, data exports and unusual connections from Metabase server addresses to source systems.
7. Build a timeline from the first suspicious request and expand incident scope if the available logs cannot rule out use of stored connections.

Limiting the next application’s blast radius

Each connector account should have read-only access to the necessary views and no permission to create functions, write files or administer the database. Separate accounts per environment and dataset make rotation and scope analysis practical. Metabase logs should also be exported outside the instance because a compromised application is not a trustworthy evidence store.

Facts and Breachroad analysis

Metabase confirmed the vulnerability, fixed versions and exploitation before disclosure; Framework and Tally described the effects on their own environments. Those notices do not establish compromise of every public instance. Rotating all connector secrets after a confirmed takeover is Breachroad’s conclusion based on the application database’s role in the attack chain.

Technical training for IT teams teaches analysts to combine application, proxy and database logs into one incident timeline. When actual scope needs confirmation, an application security assessment can cover configuration, connector permissions and administrative-panel exposure as well as code-level flaws.