Metabase's Password-Reset Endpoint Gave Anyone Admin Access, No Login Required

An attacker who has never logged into your Metabase instance can send one unauthenticated request to its password-reset endpoint and walk away with full administrator access, the stored credentials for every database Metabase connects to, and everything those credentials can read. No exploit chain to assemble, no phishing step, no privilege escalation after the fact. The bug carries a CVSS score of 10.0, the maximum the scale allows, and it has already been used against at least three companies.

This is yours to check if you run self-hosted Metabase version 1.58 or later anywhere your organization builds dashboards against real data. Metabase's own Cloud offering was patched centrally on August 6 and cloud customers do not need to act. Versions before 1.58 do not contain the vulnerable code path. Everyone else running the affected range, self-hosted, on-premises or in your own cloud account, should treat the rest of this article as today's task, not next sprint's.

The myth: a BI dashboard is a low-value target

Ask most IT teams what a self-hosted analytics tool like Metabase is worth to an attacker and you will hear some version of the same answer: not much. It renders charts. It has no customer-facing checkout, no payment form, nothing that looks like a crown asset on a risk register. It usually sits behind the corporate VPN, or at worst behind a login page nobody outside the company knows exists. That reasoning is not unreasonable on its face, and it is exactly why analytics tools routinely miss the patch cadence and exposure scrutiny that customer-facing applications get by default.

The assumption breaks on one detail teams tend to skip past: a BI tool's entire job is to hold live, working credentials to the databases it visualizes. That is not a side effect of how Metabase works. It is the product. Metabase is also the kind of tool that accumulates without a clear owner: a data analyst spins up an instance to answer one question, it works well enough that three other teams start pointing dashboards at it, and two years later nobody on the current security team remembers approving it or scheduling it for patch review. Shadow BI is common enough that it deserves the same asset-inventory attention as shadow IT generally, and this bug is a demonstration of why.

The reality: the password-reset endpoint was an all-access key

"This is a CRITICAL vulnerability that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance," Metabase wrote in the advisory it published on August 6. The flaw is tracked as GHSA-vwf4-m7j8-wcjf; no CVE identifier has been assigned as of this writing. The vulnerable endpoint, POST /api/session/reset_password, answered unauthenticated requests in every release from 1.58.0 up through the versions Metabase shipped fixes for the same day: 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9, and 1.63.5.

A crafted request to that endpoint injects SQL into Metabase's own application database, not the customer database it dashboards. From there, an attacker grants themselves administrator rights inside the instance, changes its configuration, and reads the stored connection strings Metabase keeps for every data source it has been pointed at. Once an attacker holds those connection strings, the SQL injection stops mattering. They have a working login to whatever your dashboards were built on top of, and they can query or export it the same way an authorized analyst would, because as far as the downstream database is concerned, they are one.

A password-reset flow has to accept unauthenticated requests by design; that part is not the mistake. The mistake was building that pre-authentication code path so it touched the application database with attacker-controlled input and no parameterization standing in the way. That is a narrow, specific failure, and it is also exactly the kind of code path teams review least, because "unauthenticated" and "sensitive" rarely get flagged together in the same threat model.

Why "we're not internet-facing" does not fully cover you

The instinct after reading a bug like this is to check whether Metabase is reachable from the open internet and stop there if the answer is no. That check matters, but it is not the whole exposure. The vulnerable endpoint required no Metabase account, which means anyone who can route a packet to the instance can trigger it: a contractor on the corporate VPN, a compromised workstation two hops away, another internal application making a server-side request on an attacker's behalf. Metabase instances tend to live on flat internal networks specifically because they were assumed to be low-risk, which is the same assumption this bug just spent August disproving. Treat the internal network as the perimeter you actually need to check, not a reason to move this to next quarter's list.

Three self-hosted customers found out this was not a paper vulnerability

Metabase first caught the exploitation because its own Cloud platform was hit: an attack window of roughly four hours on August 2 before the company shut the campaign down and began notifying customers. Three self-hosted customers have since disclosed what the same technique cost them once it reached their own instances on August 3.

• Framework, the repairable-laptop maker, confirmed attackers pulled customer names, email addresses, login IP addresses, billing and shipping addresses, phone numbers, and, for business accounts, VAT and EIN details.
• Tally, a Belgian form-building platform, reported exposure of customer email addresses and password hashes, and said form submission data itself was not touched.
• Kilo Code, an AI coding-assistant platform owned by Anaconda, disclosed that attackers accessed customer names, emails, and Slack access tokens; the company said it invalidated the tokens immediately after discovery.

A laptop manufacturer, a forms SaaS company, and an AI coding tool share almost nothing except that each ran Metabase against real customer data, and each learned what "just a BI tool" means as an attack surface the same week. Kilo Code's disclosure is the one worth sitting with longest: the stolen Slack tokens belonged to a completely separate system, exposed only because someone had, reasonably, connected Slack data to a dashboard, putting that second system's access inside the first system's blast radius. Every integration a BI tool has becomes reachable the moment its own admin panel gives way, whether or not that integration was ever the intended target.

What to check right now

Patch first. A CVSS 10.0 with no authentication requirement, under confirmed active exploitation, does not wait for a maintenance window. Then work the exposure the same way you would after any admin-level compromise, because the version banner changing does not undo whatever happened while the endpoint was open.

In order

• Confirm your running build against the patched list: 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9, or 1.63.5, whichever branch you deploy. Anything below those is exposed.
• If you cannot patch immediately, block or firewall POST requests to /api/session/reset_password at the reverse proxy. Metabase suggests this itself as an interim measure.
• Run the log hunt below against every server that has fronted Metabase since August 2.
• Revoke every active session and force a fresh login for all users, including admins.
• Rotate the credentials for every database connection configured inside Metabase, not just the Metabase admin password.
• Review Metabase's own admin account list and API key list for anything nobody on the team can account for.
• Check Metabase's query history and audit log for exports or unusual queries run during the exposure window.

# Hunt for the attack signature Metabase published in your web/proxy access logs:
# an unauthenticated POST to the reset-password endpoint that fails (400),
# immediately followed by a GET to /api/user/current that succeeds (200).
awk '
  $7 ~ /\/api\/session\/reset_password/ && $9 == 400 { rp[$1] = $4 }
  $7 ~ /\/api\/user\/current/ && $9 == 200 && ($1 in rp) {
    print "Suspect:", $1, "reset_password at", rp[$1], "-> user/current at", $4
  }
' /var/log/nginx/metabase_access.log

# Force every existing session to re-authenticate after patching
# (Metabase's own recommended remediation step):
# DELETE FROM core_session;

Patch the endpoint, then rotate what it could reach

If Metabase 1.58 or later is running anywhere in your environment, self-hosted, patch it to the fixed build today. Then work the checklist above in order: log hunt, session revocation, credential rotation. The Metabase instance itself was never the actual target. It was the door to whatever data source you pointed it at, and that is the part worth checking even after the version number says you are safe.

Primary sources: Metabase's own security advisory, BleepingComputer's reporting on the Framework and Tally breaches, and Help Net Security's coverage of the Kilo Code disclosure.