Threat feed
CVE-2026-72898 — Unauthenticated SQL Injection in Metabase Grants Admin (What to Do)
CVE-2026-72898 is an unauthenticated SQL injection (CWE-89) in the Metabase password-reset endpoint. CVSS 10.0, in CISA KEV, exploited in the wild. Fixed versions, the interim workaround, and why upgrading alone does not close it.
A fast briefing on a vulnerability confirmed to be exploited in the wild (listed in CISA KEV). What it does, who is affected, and how to respond — defensively, with no exploitation steps.
- CVE
- CVE-2026-72898
- Severity
- Critical — CVSS 10.0 (both v3.1 and v4.0)
- Class
- Unauthenticated SQL injection (CWE-89)
- Impact
- Administrator access to the Metabase instance, reaching connected-database credentials and data
- Affected
- Self-hosted Metabase on the x.58 line and later, below the fixed versions
- Exploitation
- In CISA KEV (added 11 Aug 2026, due date 14 Aug); the vendor states it was exploited as a 0-day
- Main fix
- Upgrade, plus session revocation and rotation of every connected database credential
Why leaving it is not an option
No authentication is required and the payoff is administrator access, which makes this a prime target for indiscriminate scanning — hence a KEV listing the day after publication. The vendor states it was actively exploited against its own cloud environment before patching, so "nobody has come for us yet" is not an assumption you can make.
What the flaw is
Metabase is a BI and analytics platform that connects to your databases and serves dashboards and queries on top of them. The defect is that the endpoint handling password resets builds SQL from a value supplied by the caller. That processing happens before authentication, so an attacker never needs an account (SQL injection, CWE-89).
The injection lands in Metabase's own application database — the one holding users, sessions, API keys and connection settings, i.e. control of the instance. CISA's KEV entry states that after gaining admin an attacker can change the application configuration, steal the stored credentials for connected databases, read anything reachable through those connections, and export it.
Unauthenticated attacker
↓ SQL injected via the password-reset endpoint
Metabase application DB → administrator
↓ stored connection settings and credentials
Every connected database
revenue, customers, logs — everything BI can read
Who is affected
| Item | Detail |
|---|---|
| Affected | Self-hosted Metabase; the vendor states Metabase Cloud is already patched |
| Vulnerable versions | The x.58 line and later, below the fixed versions |
| Fixed versions | 0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5 (Enterprise: 1.58.24 / 1.59.21 / 1.60.17 / 1.61.11 / 1.62.9 / 1.63.5) |
| Precondition | None — unauthenticated |
| Impact | Administrator access → connected-database credentials and data |
| Interim workaround | Block the /api/session/reset_password endpoint (temporary until you upgrade) |
What to do
Upgrade to the patched release (first priority, the only actual fix)
If you cannot upgrade yet, block the endpoint
/api/session/reset_password at your reverse proxy or WAF. Treat it strictly as a temporary measure.Revoke every session, then audit API keys and admins
core_session table of the application database to end every session, remove API keys you do not recognise, and check administrator accounts for changes you cannot account for. If someone held admin, upgrading alone leaves the accounts and keys they created in place.Rotate the credentials of every connected database (do not skip this)
Reduce reachability itself
A detection hint the vendor published
The vendor describes the exploitation pattern as a call to /api/session/reset_password returning 400, immediately followed by /api/user/current returning 200. If you still have access logs, it is worth looking for that sequence. If you have no logs, the answer is "unknown", not "clean". In that case assume compromise and carry out step 4.
This site's view: a BI tool holds every connected credential, so protect it like your most sensitive database
Organisations tend to file BI and analytics tools under "things that display data" and run them at a lower tier of care than the databases themselves. The reality is the opposite: the tool is a single place holding the credentials to everything it connects to. Our position is that it should be protected at the tier of the most sensitive database behind it. Which means: give BI a least-privilege connection user (read-only, only the schemas it needs), never expose it directly to the internet, and have a credential-rotation runbook ready before you need it. Do that, and even a worst case like a flaw in pre-authentication code costs you one connection instead of every database.
Sources
- NVD — CVE-2026-72898 (CWE-89; CVSS 10.0 in both v3.1 and v4.0)
- CISA KEV — Known Exploited Vulnerabilities Catalog (added 11 August 2026, due 14 August 2026)
- Vendor — GHSA-vwf4-m7j8-wcjf and Metabase security update
Read next
FAQ
QWhat does CVE-2026-72898 allow?
A remote, unauthenticated attacker can inject arbitrary SQL through the Metabase password-reset endpoint and gain administrator access to the instance. Per CISA, from there an attacker can change the application configuration, steal the stored credentials for connected databases, read any data reachable through those connections, and export it.
QWhat is the definitive fix?
Upgrade to the patch for your release line: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 or 0.63.5 (and the matching 1.x Enterprise builds). If you cannot upgrade immediately, the vendor's stated workaround is to block the /api/session/reset_password endpoint — but treat that as a temporary measure until you upgrade, not as a fix.
QIs upgrading enough?
No. The vendor's post-upgrade instructions include revoking every session by deleting all rows from the core_session table in the application database, removing API keys you do not recognise, auditing administrator accounts, and rotating the credentials of every connected database. If an attacker held admin, assume those database credentials are already theirs.
QWhat about Metabase Cloud?
The vendor states that Metabase Cloud instances were already upgraded and patched. The exposure is on self-hosted deployments.