CVE-2026-72898SQL InjectionMetabaseBusiness Intelligence

CVE-2026-72898: a perfect 10.0 in the dashboard that holds every database password you own

One HTTP request with no credentials at all turns into administrator access. And a Metabase administrator does not just see reports: they see the connection credentials for every database wired into the tool.

By Equipe VorvexPublished on August 21, 20268 min read

A 10.0 is rare. On the CVSS 3.1 scale it only shows up when the flaw is exploitable over the network, without authentication, without user interaction, and on top of that escapes the compromised component to hit other systems. CVE-2026-72898 scores 10.0 on both scales, 3.1 and 4.0, and the reason becomes obvious once you remember what a Metabase server tends to hold: the connection credentials for every database the company ever wanted to put on a chart.

Technical diagram of a business intelligence server standing between the public internet on the left and a group of production database cylinders on the right. One arrow from an anonymous attacker figure on the internet side reaches the BI server, and from the BI server several arrows fan out to every database cylinder, showing a single entry point reaching many separate data stores. — By design, Metabase is the point on the network with open connections to the largest number of databases at once.

The flaw in one sentence

CVE-2026-72898 is a SQL injection (CWE-89) in Metabase's password reset endpoint. A remote, unauthenticated attacker injects arbitrary SQL into the query the reset flow runs against Metabase's own application database, and from there obtains administrator access to the instance. NVD assigns CVSS 3.1 of 10.0 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, and CVSS 4.0 of 10.0 with CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H.

Vulnerable endpoint: POST /api/session/reset_password, no authentication required
Affected: self-hosted installs from the 0.58 / 1.58 line onward; versions below 58 are not affected
Fixed in: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5, plus the equivalent Enterprise releases (1.58.24 and up)
Disclosed by Metabase on August 6, 2026, with exploitation in production already confirmed before that date
Published on NVD on August 10, 2026 and added to the CISA KEV catalog on August 11, 2026, with an August 14, 2026 remediation deadline for US federal agencies
Temporary mitigation for anyone who could not patch right away: block the /api/session/reset_password endpoint at the edge

Why 10.0 and not 9.8

The difference between 9.8 and 10.0 on CVSS 3.1 comes down to a single field in the vector: scope. Almost every critical remote code execution flaw sits at S:U, scope unchanged, because the damage stays inside the vulnerable component. Here the scope is S:C, changed, and that single choice in the score already tells the story of the bug.

What the attacker compromises is not just Metabase. It is Metabase's application database, and inside it live the credentials the tool uses to query the business databases. Taking the dashboard gives you the data warehouse, the transactional database, the read replica, everything somebody once connected in order to build a chart. The systems that get hit belong to other teams, under other administration, and the score reflects that.

The mechanism: a field that should never have been accepted in the request body

Password reset is one of the few flows that has to be unauthenticated by nature: someone who forgot their password cannot prove who they are before changing it. The expected request body is small, a token and the new password, and the server uses that token to look the user up in the application database.

http

POST /api/session/reset_password HTTP/1.1
Host: metabase.example.internal
Content-Type: application/json

{"token": "<token-from-the-reset-email>", "password": "<new-password>"}

# That is the expected body. The flaw is in neither of those two fields.
# The endpoint accepted UNDECLARED fields in the body and passed them down to
# the query-building layer, which interpreted the value as query structure
# instead of treating it as an already-validated identifier. Result: an extra
# field becomes a SQL expression inside the reset flow's query.
#
# We are not publishing the injection payload. The point here is the bug class,
# not the recipe: input accepted without an allowlist of fields, arriving alive
# at the SQL builder.

The legitimate reset request. The attack changes none of the fields above, it adds a field the server should never have accepted in the first place.

Metabase's fix follows exactly that reading: the reset flow now strictly accepts only the expected inputs, so no undeclared field in the body can influence the application database query. That is the difference between validating what you receive and listing what you accept. The first approach tries to guess what is dangerous; the second discards anything that was not planned for, and therefore does not depend on a developer having imagined the attack in advance.

Worth noting that this is not textbook SQL injection, the string concatenation in a login form. Metabase uses a query-building layer that, under normal conditions, parameterizes values correctly. The gap showed up on the boundary between deserializing the incoming JSON and feeding that layer: a user-supplied map treated as a query fragment instead of a value. It is a pattern we keep running into in modern stacks, and one that slips through code review precisely because there is no concatenation anywhere in the code.

Blast radius: BI is the map of the company's data

Technical illustration of an application server drawn as a box containing a small vault with a row of key icons, each key connected by a line to a different database cylinder outside the box, and a broken padlock at the entrance of the server box. — Every connection configured in the dashboard is a stored credential. Whoever becomes administrator inherits the whole keyring.

In plenty of attack surface inventories, the BI tool gets filed as internal and low risk. It is an easy misreading, because the product looks passive: all it does is draw charts. Except that in order to draw a chart it needs a persistent connection, a stored credential and, almost always, broad read permission across production databases. No other application in the company usually concentrates that kind of reach.

Administrative access to the instance, which includes creating accounts, changing permissions and turning controls off
The connection credentials for every configured database, and therefore direct access to them with whatever privileges the tool holds
Querying and exporting any data reachable through those connections, without ever touching the database over the network
The secrets available to the running process, including integrations configured on the instance
The history of questions and dashboards, which works as an annotated map of where the sensitive data lives

That last item is the one people underestimate. The query history of a corporate Metabase is ready-made documentation: it tells you which table holds customers, which one holds transactions, which column carries tax IDs and which join produces the complete base. An attacker who would otherwise spend days exploring the schema gets it pre-chewed, written by people who know the business.

What has already happened

The flaw was exploited before it existed as a CVE. Metabase disclosed the problem on August 6, 2026 after detecting a real attack against its own cloud infrastructure earlier that month, blocking the endpoint and shipping the fixed releases. The CVE identifier only came out on August 10, and CISA added the flaw to the KEV catalog on August 11, with a three-day deadline for US federal agencies under directive BOD 26-04. Three days is the window reserved for flaws that meet all four highest-risk criteria: internet-facing asset, KEV listing, automatable exploitation and full system control once exploited.

On the self-hosted side, Dataminr's August 8 assessment identified roughly 11,000 probable internet-reachable Metabase deployments, of which 4,309 appeared to be running a vulnerable version. More than 97% of the fingerprinted hosts on affected branches were still unpatched in that scan, two days after disclosure. The distribution spans government, healthcare, energy, finance, telecom and aviation.

At least three companies running the cloud version have publicly confirmed unauthorized access to customer data in the pre-patch window: Framework, Anaconda and n8n. In Anaconda's case, Kilo Code confirmed exposure of Slack access tokens belonging to users of its bot feature. A Metabase entry also appeared on an extortion blog attributed to ShinyHunters, but the attribution remains unconfirmed and we do not treat it as fact.

How to check whether your instance was used

Patching does not answer the question that matters after a flaw with active exploitation and a public endpoint: has somebody already been through here? In this case there is a fairly specific log pattern, pointed out by Metabase itself, that serves as a starting point for hunting through reverse proxy or load balancer history.

bash

# Pattern to look for in access logs, same session/IP, in sequence:

POST /api/session/reset_password   -> 400
GET  /api/user/current             -> 200

# How to read it: the reset attempt failed (400), yet right afterwards the
# request that only returns 200 for a valid session returned 200. In other
# words, a session was obtained with no valid authentication flow in between.
#
# Quick pass over a combined reverse proxy log:
grep -E 'reset_password|api/user/current' access.log \
  | awk '{print $1, $4, $7, $9}' \
  | sort -k1,1 -k2,2

The status pair is the most direct indicator: a 400 on reset followed by a 200 on /api/user/current from the same source.

If the endpoint was reachable from the internet at any point during the window, the official guidance goes well beyond patching. Sessions issued before the patch stay valid after it, and an API key created by a fake administrator keeps working even with the flaw fixed. Persistence does not disappear with the upgrade.

sql

-- Run against Metabase's APPLICATION database, after upgrading.
-- Invalidates every active session, including the ones the attacker created.
DELETE FROM core_session;

-- Then, inside the dashboard and outside it:
--   1. review and delete API keys you do not recognize
--   2. audit the administrator list and recent permission changes
--   3. rotate credentials for EVERY database connected to the instance
--   4. review data warehouse logs for unusual queries or exports
--   5. review activity and question history inside Metabase

The session cleanup comes from the official advisory. Without it, the upgrade closes the door but leaves whoever already got in inside the house.

Item 3 is the most expensive and the most frequently skipped. Rotating production database credentials takes a maintenance window, coordination and somebody willing to own the risk of breaking a report. That is exactly why it gets pushed to later, and exactly why it matters: the stolen credential is the part that survives the incident.

What changes in the pentest scope

In the scopes that reach us, BI tools rarely show up. When they do, they come in as supporting applications, at the bottom of the list, low priority. CVE-2026-72898 is a ready-made argument for flipping that order, and the flip does not depend on this specific flaw still being around: the tool's blast radius is structural, not the consequence of one bug.

Upgrade to 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 or 0.63.5, depending on your branch, and confirm the running version instead of trusting what is in the deploy repository
Take Metabase off the open internet: access through VPN or an authenticated proxy, with the reset endpoint never publicly exposed
Review the permissions of each configured connection; a BI dashboard rarely needs a write-capable user, and almost never needs a superuser
Treat the instance as a system that processes personal data for privacy compliance purposes, because that is what it does, and include it in the impact assessment
Run the retroactive hunt through access logs for the 400 followed by 200 pattern before closing the case, even if the instance is already patched
Put BI, data orchestrators and ETL tooling in the next pentest scope with the weight of a critical system, not as a low-risk internal application

This post is educational and defense-oriented. We are not publishing a working exploit or the injection payload: the snippets above reproduce the product's documented API format, the indicator of compromise released by the vendor itself, and the remediation steps from the official advisory. What we want on the record is the risk reading. If your BI tool falls, it is not a dashboard that falls with it, it is the contents of every database it can see.

← Back to blog