Your dashboard has the keys to the database.

The dashboard looked like the safe part of the stack. It was there to read data, draw charts, and keep people from running SQL by hand.

Then one unauthenticated request turned it into an administrator account with a map to every connected database.

That is the useful lesson in the Metabase zero-day disclosed last week. An analytics tool is not a window into your data. It is a privileged bridge to it, and the attacker only needs the bridge to be weaker than everything behind it.

What happened

On August 6, Metabase disclosed that its cloud service had been attacked through a previously unknown vulnerability in versions 1.58 and later. Metabase blocked the affected endpoint and patched its hosted customers. Self-hosted instances need to be upgraded by their operators.

The flaw, tracked as GHSA-vwf4-m7j8-wcjf, is an unauthenticated SQL injection in the password-reset API. The security advisory gives it the maximum CVSS score of 10.0 and says exploitation has been confirmed. It did not have a CVE assigned when the advisory was published.

The attack begins against Metabase's own application database. That may sound contained. It is not. Metabase says successful exploitation can give an attacker administrator access, let them change application configuration, steal stored credentials for connected databases, and read or export anything those connections can reach.

The jump from "reporting tool" to "database compromise" is one trust relationship.

BleepingComputer reported that Framework and Tally both disclosed data theft after their Metabase environments were accessed on August 3. This was not a lab result waiting for somebody to build an exploit. Customers were already dealing with the consequence before the patch was public.

A read-only dashboard can still be a high-privilege credential store.

The dashboard is part of the security boundary

Business-intelligence tools accumulate access quietly. One connection starts with product metrics. Then finance needs a chart, support wants customer history, and leadership asks for a single view across billing, CRM, and operations.

The dashboard gets broader visibility because broad visibility is the product.

Teams often compensate by making the database accounts read-only. Do that. It limits tampering and gives you a smaller incident than a connection that can change production records. But read-only access to customer data, revenue, internal operations, and authentication tables can still be a serious breach. "The attacker could only read it" is not much comfort when reading it was the objective.

Network placement creates the same false confidence. A database may be private and correctly unreachable from the internet while Metabase is public and allowed through the firewall. Compromise the approved intermediary and the private database behaves exactly as designed.

This is why patching the visible bug is necessary but incomplete. The incident should make you inspect the authority you gave the tool before the bug existed.

What I'd actually do today

1. Find the instance and establish exposure. Identify every self-hosted Metabase deployment, its exact version, who operates it, and whether /api/session/reset_password was reachable from the internet. Do not assume the instance in the infrastructure repository is the only one; check cloud accounts, old analytics hosts, and departmental deployments.
2. Upgrade before doing anything clever. Metabase lists 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5 as the minimum safe releases for their respective branches. If you cannot patch immediately, block /api/session/reset_password at the reverse proxy or firewall. That is a temporary containment measure, not a maintenance plan.
3. Hunt for the published attack pattern. Check application and ingress logs for a POST /api/session/reset_password returning 400, followed by a GET /api/user/current returning 200. Metabase says finding that sequence likely means the instance was compromised. Preserve the logs before routine cleanup or redeployment destroys them.
4. Treat a reachable vulnerable instance as an incident, not a completed patch ticket. Revoke active Metabase sessions, review administrator accounts and API keys, and inspect Metabase activity, query history, and warehouse logs. If you find the pattern or cannot rule out access, rotate credentials for every connected database after containing the instance.
5. Shrink each connection. Give Metabase a separate account for each data source, make it read-only unless a documented feature truly requires writes, and restrict it to the schemas and tables needed for reporting. A dashboard for sales metrics does not need the authentication database because somebody may want that chart later.
6. Reduce who can reach the bridge. Put administrative functions behind SSO and a private network or authenticated access proxy. Separate public embeds from the administration plane where the architecture allows it. Record the owner, patch path, logs, and credential-rotation procedure in the service inventory.
7. Choose hosted software deliberately. Metabase Cloud customers were patched by the vendor; self-hosted customers own the upgrade and investigation. Self-hosting can be the right choice for control, cost, or data residency. It is not the cheaper option if nobody is funded to operate it.

The bottom line

The database was private. The trusted dashboard was the public path to it.

Treat every tool that can see across your business as infrastructure with keys, because that is what an attacker sees too.