A business intelligence tool is only as trustworthy as the database credentials it holds, and this week attackers found that Metabase would hand those credentials to anyone who asked the right way, no password required.
An unauthenticated request straight into the application database
The flaw, tracked as GHSA-vwf4-m7j8-wcjf, lives in the public POST /api/session/reset_password endpoint and allows an unauthenticated attacker to inject arbitrary SQL into Metabase’s own application database. From there, an attacker can grant themselves administrator access to the instance, at which point they can change the application configuration, read the stored credentials for every connected data source, and pull whatever data those connections expose. It affects self-hosted and cloud deployments across the 0.58 through 0.63 release lines, and it carries the maximum possible CVSS score of 10.0.
Exploited before most teams had heard of it
Metabase’s own cloud infrastructure was targeted from around August 3, and the company only notified affected customers once it identified the pattern. Framework, a Metabase customer, confirmed its installation was accessed on August 3 and that it learned of the breach from Metabase on August 6, three days later, with names, email addresses, billing and shipping addresses, phone numbers, company details and connection IP addresses exposed. Tally, a separate customer, confirmed its analytics environment was breached the same day, exposing email addresses and hashed passwords, though not form entries or responses.
What the attack looks like in your logs
The exploitation pattern leaves a distinctive trace: a POST to /api/session/reset_password that returns a 400 error, immediately followed by a GET to /api/user/current that returns 200. Any team running self-hosted Metabase should be checking access logs for that sequence now, not after confirming they have patched. Fixed versions are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5; if immediate patching is not possible, blocking the reset-password endpoint at the network edge closes the immediate hole.
Why self-hosting doesn’t remove the risk, it relocates it
A large share of European teams run Metabase specifically because self-hosting keeps customer analytics data inside their own infrastructure rather than a US-owned SaaS platform, a reasonable response to data residency and Schrems II concerns. This incident is a reminder that self-hosting moves the responsibility for patching, logging and access control onto you as well, it does not remove it. A BI tool with live credentials into your production databases is a high-value target regardless of who operates the server it runs on.
If you need help auditing whether your self-hosted analytics and BI stack was exposed, checking logs for this exploitation pattern, or building a patch cadence that catches maximum-severity flaws before attackers do, contact Excello Digital. We help European teams run self-hosted infrastructure without trading data sovereignty for security.