TL;DR:
Immediate action is advised for all organizations running self-hosted Metabase. A critical, unauthenticated SQL injection vulnerability has been disclosed in Metabase's password reset functionality, and Metabase has confirmed active exploitation in the wild.
Overview
The vulnerability, tracked as GHSA-vwf4-m7j8-wcjf, affects the unauthenticated POST /api/session/reset_password endpoint in Metabase. CVE designation: CVE-2026-72898.
The flaw carries a CVSS v3.1 score of 10.0 (Critical) — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — meaning exploitation requires no authentication, no user interaction, and only low attack complexity. Any attacker who can reach the affected endpoint may be able to execute arbitrary SQL against the Metabase application database.
Technical Background
The root cause is a failure to restrict undeclared fields in the password-reset request body. Affected versions allow an unexpected value to reach the application-database user lookup as structured input rather than a validated identifier. Metabases’s query-building stack can interpret that input as a SQL expression, allowing an attacker to inject SQL into the application-database query used by the reset flow. Because the endpoint is unauthenticated by design, this gives an outside attacker a direct path to the Metabase application database with no credentials at all.
Metabase's patch closes this by strictly limiting the reset flow to the expected inputs, preventing undeclared request fields from influencing the application-database query.
Successful exploitation can let an attacker alter application-database records and obtain full administrative access to Metabase. From there, we'd expect an attacker to be able to change application settings, access or export data, obtain secrets available to the running application, and query any databases Metabase is connected to — using Metabase's own privileges to do it.
Depending on the underlying application-database engine and configuration, exploitation may also impact availability of the deployment itself.
It's worth underscoring why this goes beyond the Metabase instance itself: Metabase deployments commonly store or have access to credentials for the databases and data warehouses they connect to, so a compromised instance can be a springboard into far more sensitive systems.
Vulnerable Versions
Metabase has confirmed the following branches are affected, with fixes available in:
- Metabase 58: 58.24 or later
- Metabase 59: 59.21 or later
- Metabase 60: 60.17 or later
- Metabase 61: 61.11 or later
- Metabase 62: 62.9 or later
- Metabase 63: 63.5 or later
How Bishop Fox Responded to the Threat
After learning of the Emerging Threat Thursday after hours, Bishop Fox’s Threat Enablement and Analysis team began work first thing Friday morning responding to the threat:
Response Timeline:
- Friday, 6:15 a.m. MST: Reverse engineering and technical analysis began.
- 7:30–7:50 a.m.: Version-fingerprinting scans launched across relevant assets.
- 8:17–8:40 a.m.: Behavioral indicator testing and broader Cosmos validation began.
- 9:40–9:50 a.m.: Initial findings safely confirmed.
- 9:50 a.m.: Potentially affected customers notified and relevant assets added to exposure dashboards.
- 10:00–10:50 a.m.: Detection playbooks and controlled validation tooling finalized; cases handed off to Adversarial Operations for customer attribution, impact analysis, and findings delivered.
Within approximately 4.5 hours of beginning the investigation, Bishop Fox’s Cosmos platform had moved from reverse engineering to detection, customer notification, and coordinated response.
Immediate Actions
- Upgrade immediately to the patched release for your branch (listed above).
- Consult the official Metabase advisory for current release artifacts and any updated version guidance.
- Test the update in a non-production environment before deploying where feasible.
- After upgrading, confirm that undeclared fields sent to /api/session/reset_password are rejected and can no longer influence application-database queries.
- Audit administrator accounts for unexpected creation, privilege changes, email changes, or password resets.
- Review Metabase activity, query history, reverse-proxy logs, application-database logs, and data-warehouse logs for unauthorized activity.
Closing
Given the combination of no authentication required, a 10.0 CVSS score, and confirmed active exploitation, this is a patch-now situation for any organization running affected self-hosted Metabase versions.
If you need help assessing your exposure or prioritizing remediation across your environment, reach out. We’re happy to help.
Subscribe to our blog
Be first to learn about latest tools, advisories, and findings.
Thank You! You have been subscribed.
Recommended Posts