A flaw in Metabase gave administrator access without a sign-in

Metabase announced on 6 August that Metabase Cloud had been attacked through a vulnerability nobody knew about beforehand, and that the flaw has now been fixed. The vulnerability carries the number CVE-2026-72898, and the vendor's advisory sets the severity at 10 out of 10 under CVSS 3.1. Metabase confirms that the vulnerability is being actively exploited. It affects version 58 and later, up to and including branch 63. Metabase Cloud has already been upgraded, while self-hosted instances must be upgraded by whoever runs them.

What happens technically

Metabase is a tool for querying and visualising data, and it typically sits with access to the databases an organisation already runs. The tool also has an application database of its own, holding users, sessions, API keys and the logins for every connected database. The vulnerability sits in the /api/session/reset_password endpoint, which is reachable without signing in because anyone who has forgotten their password is by definition not signed in. According to the advisory, an unauthenticated attacker can inject arbitrary SQL into the application database through that endpoint. The CVSS vector the vendor publishes states that the attack happens over the network, that it requires no privileges, and that it requires no user interaction.

The consequence follows from what the application database holds. Metabase writes that from there the attacker can gain administrator access, change the application configuration, steal the stored credentials for the connected databases, read anything those credentials reach, and export data. The attack pattern is described concretely in the advisory: a POST call to /api/session/reset_password answering with status code 400, followed by a GET call to /api/user/current answering with 200. If that pattern appears in the application log or in the ingress log in front of the server, Metabase treats the instance as likely compromised. The vendor does not state how many instances were affected.

What this means for you if you run Metabase yourself

The most important thing here, in our assessment, is not Metabase itself, but what an analytics tool has access to. Your instance most likely sits connected to the data warehouse, the customer register and the finance database, and it keeps the logins for all of them. An attacker with administrator access in Metabase has therefore not merely taken one system. The attacker has been handed the keys to the databases Metabase queries, and a ready-made interface for extracting the contents.

The second point is where an upgrade like this tends to land in your queue. Metabase is often set up by an analytics team rather than by operations, and therefore falls outside the usual list of systems someone is named as responsible for updating. That is exactly the kind of system that gets left behind on an old version. Since the vulnerability is being actively exploited, your window is short. If your password reset endpoint is reachable from the Internet, the upgrade belongs now, and not in the next maintenance window.

Berigo recommends

• Upgrade to the fixed release in the branch your instance runs on, that is 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 or 0.63.5.
• If the upgrade cannot happen straight away, block the /api/session/reset_password endpoint in the meantime.
• If the endpoint is reachable from outside, search the application log and the ingress log for a POST call to that endpoint with status code 400, followed by a GET call to /api/user/current with status code 200.
• Revoke all active sessions after the upgrade, review API keys and administrator accounts, and remove anything nobody recognises.
• Rotate the credentials for every database Metabase connects to, and review the data warehouse logs for traces of unauthorised use.