Self-hosted Metabase exposure from unauthenticated SQL injection
Metabase instances running affected 1.58 and later releases have been used in active attacks. The flaw sits in the application layer, so the attacker does not need a valid account to start. Once the injection lands, the rest of the path is plain admin abuse.
Self-hosted analytics setups tend to hold more than dashboards. They often keep database connections, saved queries, exports, and admin settings in one place. That makes a single application flaw awkward in the way only a central admin panel can be.
How the unauthenticated bug turns into admin access on a live instance
The attacker targets the Metabase application database, not the data warehouse behind it. That matters because it turns the web app itself into the entry point. Arbitrary SQL can alter application state, create or change access, and expose whatever the Metabase instance can already see.
After that, admin-level changes follow the usual ugly route. Configuration can be changed, sessions can be abused, and stored connection secrets can be pulled back out. There is no neat boundary between “analytics tool” and “control plane” once the instance is owned.
Session reset and user lookup requests as a compromise signal
One useful compromise pattern is a POST to /api/session/reset_password that returns HTTP 400, followed by a successful GET to /api/user/current. That sequence is a strong sign that someone has hit the vulnerable path and moved on to authenticated access.
Logs showing that pair should not be waved away as noise. Check whether it appears around failed login activity, odd admin changes, or a burst of requests to export and query endpoints. If the pattern exists, assume the instance has been touched.
What attackers can pull once they are inside
The usual prize is not just dashboards. Once an attacker has admin access, Metabase can expose connected database credentials, readable data from those connections, and anything the instance can export.
Connected database credentials and stored secrets
Stored credentials for connected databases are the obvious target. If those secrets are recovered, the attacker may not need Metabase at all for the next step. They can pivot into the connected systems directly, which is far worse than losing the analytics box.
Admin access also opens the door to application changes. API keys, administrator accounts, connection settings, and other stored secrets need checking after compromise. If the instance held credentials for multiple sources, each one needs separate treatment.
Customer data, exports, and admin changes
Metabase can read and export any data reachable through its configured connections. That is enough for data theft even when the attacker never reaches the source systems themselves. Customer information, user records, and report exports can all leave through the analytics layer.
Public disclosures from compromised instances have also included email addresses and password hashes. In one case, forms and submitted answers were not reached because they were stored separately. That distinction is cold comfort if the analytics system already held enough to identify people and map activity.
Patch, contain, and check for fallout on self-hosted installs
Self-hosted instances need manual patching. Fixed releases are available across the affected branches, with minimum safe versions including 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5. If an upgrade is not immediate, block access to /api/session/reset_password until the instance is moved.
The cleanest step is a fixed Metabase release, then session and secret rotation. Revoke active sessions, rotate connected database credentials, review administrator accounts, and check API keys. After that, inspect query history and logs for signs of the reset_password then user/current request pattern.
Move to a fixed Metabase release and block the reset_password path if you cannot yet upgrade
Patching is the only durable fix. Self-hosted installs do not get the cloud-side blocking that Metabase used to cut off the attack path, so delay leaves the instance open. If the version is in the affected range, treat upgrade as urgent rather than scheduled maintenance.
If the upgrade has to wait, block access to the password reset endpoint at the front end or reverse proxy. That is a temporary barrier, not a fix. It buys time while the instance is moved onto a clean release.
Revoke sessions, rotate credentials, and review logs for the reset_password then user/current pattern
Active user sessions should be revoked after suspected exposure. Any stored credentials for connected databases need rotation, since those secrets may have been copied already. Administrator accounts and API keys also need a close look, because the attacker may have altered access before leaving.
Logs should be searched for the reset_password then user/current sequence, then checked around the same time window for exports, config changes, and odd admin activity. Query history can show whether data was read in bulk. If the instance was compromised, assume the attacker had time to copy more than one useful thing.
