A perfect 10: the Metabase flaw that hands over every connected database

CVSS scores rarely reach 10.0. This one does, on both the version 3.1 and version 4.0 scales [2].

CVE-2026-72898 lets a remote, unauthenticated attacker inject SQL through a password-reset endpoint in Metabase and come out the other side with administrator access to the instance [1][2]. Metabase’s own advisory states the company has confirmed active exploitation [1]. CISA added it to the Known Exploited Vulnerabilities catalog on August 11, 2026, with a federal remediation deadline of August 14, 2026 [3].

If you run self-hosted Metabase, this is a today problem.

What happened

Metabase published advisory GHSA-vwf4-m7j8-wcjf on August 6, 2026, describing an SQL injection reachable through an unauthenticated endpoint that leads to administrator access [1]. NVD published the CVE record on August 10, 2026, rating it CVSS 10.0 [2].

The affected versions, from the vendor advisory [1]:

Enterprise builds use the same version numbers with a 1. prefix rather than 0. [1].

Metabase’s advice is to upgrade immediately. Where that is not possible in the moment, the advisory offers one temporary measure: block the /api/session/reset_password endpoint [1]. That is a stopgap to buy hours, not a fix.

Why this matters

The instinct with a business intelligence tool is to rank it below the systems it reports on. That instinct is backwards here.

Metabase works by holding connection credentials for every data source it queries: production replicas, warehouses, analytics databases. Administrator access to the Metabase instance is therefore access to that credential set, and to a query interface already wired into all of it. Metabase says as much: a compromised instance allows credential theft, database access and unauthorised data exfiltration [1].

So the impact is not “someone edited our dashboards.” It is that the attacker inherits, in one step, the access your analytics team spent two years configuring, and a legitimate-looking tool through which to use it.

Two properties make this worse than the average critical CVE. It needs no credentials, so there is no phishing step and no account to compromise first. And business intelligence tools are commonly exposed to the internet on purpose, because people need to reach dashboards from home and from phones. The population of internet-facing Metabase instances is not an accident of misconfiguration; it is the intended deployment.

Technical breakdown

The vulnerability is CWE-89, classical SQL injection, in a code path that runs before authentication [2]. Password-reset flows are a recurring source of this class of bug for a structural reason: they must accept input from someone who by definition cannot authenticate yet, and they must look that input up in the database. That places untrusted data into a query at exactly the point where the usual guard (“is this user allowed?”) has not run yet.

The injection targets the application’s own database, the one Metabase uses to store its users, sessions and data source configuration, rather than the warehouses it reports on [2]. That distinction is what makes the escalation to administrator possible.

The route is below. It is described so you can recognise and interrupt it; no payload or request is reproduced.

Three breaks, and they are worth understanding as a defence-in-depth stack rather than alternatives.

Removing internet exposure severs step one. Most organisations cannot do this outright (the tool exists to be reached), but putting it behind SSO at a reverse proxy, or requiring VPN, changes an unauthenticated internet attack into something much harder.

Upgrading, or blocking the reset endpoint severs step two, and upgrading is the real fix [1].

Scoping database credentials severs step five, and it is the control that determines how bad the day gets. If every connection in Metabase uses a read-only account limited to the specific schemas that instance reports on, then administrator access to Metabase is a serious incident with a bounded blast radius. If those connections use broadly privileged accounts, and in a lot of analytics stacks they do, because it was easier during setup, the attacker gets write access to production data stores.

The final step deserves attention from detection engineers. Once the attacker holds admin and is querying through Metabase, the database-side telemetry shows the Metabase service account doing what the Metabase service account always does. There is no anomalous source address and no unusual client. What is left to detect on is volume, timing and shape: query patterns that do not match any saved dashboard, bulk exports outside working hours, sudden interest in tables no dashboard references.

What defenders should do Monday morning

Immediate: today.

Identify every Metabase instance you run, including ones stood up by data teams outside central IT, and check each against the version table above [1]. Upgrade anything affected. For any instance you cannot upgrade in the next few hours, block /api/session/reset_password as the vendor’s interim measure and treat that as a countdown, not a resolution [1].

Near term: this week.

Work through Metabase’s post-upgrade list, because patching alone does not evict an attacker who was already in: revoke active sessions, audit API keys and administrator accounts for entries you do not recognise, rotate the credentials for every connected database, and review access logs [1]. If an instance was internet-reachable while running a vulnerable version, treat the connected database credentials as exposed rather than waiting for evidence.

Structural: this quarter.

Review what each Metabase data source connection is actually permitted to do. Read-only accounts, scoped to the schemas that instance genuinely needs, convert this class of compromise from a catastrophe into an incident. Put the tool behind SSO at the edge. Add BI and analytics platforms to whatever inventory drives your patching, because they are credential stores that happen to draw charts.

Checklist

• Find every Metabase instance, including shadow deployments by data teams.
• Compare each against the affected and fixed version lists in the vendor advisory.
• Upgrade to the fixed release for your line.
• If you cannot upgrade today, block /api/session/reset_password as a stopgap.
• Revoke active sessions after upgrading.
• Audit administrator accounts and API keys for unfamiliar entries.
• Rotate credentials for every connected database.
• Review access logs for the exposure window.
• Re-scope data source connections to read-only, least-privilege accounts.
• Put the instance behind SSO or VPN rather than open to the internet.

The lesson underneath the CVE

Patch this one quickly. It is unauthenticated, it is a 10.0, and the vendor says it is being exploited. But the durable question it raises is about privilege, not versions.

Analytics platforms accumulate the most permissive credentials in the organisation, because every new data source is added under time pressure by someone who just needs the connection to work. Nobody revisits it. The result is a single application, often deliberately internet-facing, holding keys to the warehouse.

The version numbers in this post will be irrelevant in a month. The question of what your BI tool’s database accounts are allowed to do will still be sitting there, and it is the one that decides whether the next flaw in this category is an outage or a breach.