CVE-2026-72898: Critical Metabase Unauthenticated SQL Injection Vulnerability

Overview

CVE-2026-72898 is a critical unauthenticated SQL injection vulnerability in Metabase. The issue affects the password-reset functionality and can be reached through the publicly accessible POST /api/session/reset_password endpoint.

The vulnerability allows a remote attacker to inject SQL into Metabase’s application database without first authenticating. A successful attack can be used to manipulate authentication-related data and obtain administrator access to the Metabase instance.

Metabase has confirmed that the vulnerability is being actively exploited in the wild, making it particularly important for exposed self-hosted installations to be patched as soon as possible.

**Important:** This document is intended for controlled security testing and lab environments. Do not test against systems you do not own or have explicit permission to assess.

The issue is in Metabase’s password-reset flow.

Under normal circumstances, the reset endpoint is expected to process information associated with a password reset and use it to identify the relevant user. In vulnerable versions, attacker-controlled input is not properly restricted before it reaches the query-building logic used by the application.

The important detail is that the value is handled as structured query input rather than being treated strictly as a simple user identifier. Specifically, an attacker can add an extra user-id key to the JSON request body and supply it as a HoneySQL {:raw “SQL”} object. As the value reaches the database query without type validation, it is compiled into raw SQL instead of being treated as data – giving the attacker control over the SQL expression generated for the lookup.

In practical terms, an attacker who can reach the endpoint can submit specially crafted input and cause SQL to be executed against Metabase’s application database.

Metabase’s application database is separate from the databases and warehouses that Metabase is configured to query. It stores information required to operate the Metabase application, including user accounts and other application data.

The SQL injection is particularly serious because the attacker does not need an existing Metabase account.

A successful attack can allow an attacker to manipulate authentication-related information in the application database. This can ultimately result in administrator access to the Metabase instance.

Once an attacker has administrator access, the impact can extend beyond Metabase itself. Depending on the instance configuration and the privileges assigned to connected data sources, an attacker may be able to:

• Change Metabase configuration and settings.
• Access data available through existing database connections.
• Access stored connection information and credentials available to the application.
• Create or modify Metabase users and permissions.
• Run queries against connected data sources using Metabase’s existing privileges.
• Access sensitive business intelligence data exposed through the compromised instance.

This is what makes the vulnerability much more serious than a typical SQL injection limited to a single application database. Metabase has confirmed active exploitation of this vulnerability. Public reporting has also described real-world exploitation and compromise associated with the flaw, highlighting that this is not merely a theoretical vulnerability.

The vulnerability affects releases across the Metabase 58 through 63 lines (both the Open Source 0.x and Enterprise 1.x builds). Cloud instances were patched by Metabase before disclosure.

Metabase has published security fixes across multiple release branches, so administrators should verify the exact affected range and corresponding fixed release against the current Metabase advisory before deciding whether their installation is vulnerable.

The vulnerable functionality is exposed through:

POST /api/session/reset_password

The endpoint does not require an authenticated Metabase session, which is a major part of the vulnerability’s impact.

A simplified representation of the request is:

POST /api/session/reset_password HTTP/1.1
Host: <metabase-host>:3000
Content-Type: application/json

{
  “token”: “<reset-token-value>”,
  “user-id”: { “raw”: “<crafted-SQL>” },
  “password”: “<new-password>”
}

The unexpected user-id field is the crux: because it is not restricted before reaching the query builder, and can be supplied as a HoneySQL {:raw “…”} object, its contents are compiled into the SQL statement rather than bound as a parameter. The exact malicious value and query structure should be treated as a lab-testing detail rather than tested on production systems.

At a high level, exploitation follows this path:

The important distinction is that the initial SQL injection targets the Metabase application database. Access to external databases is a consequence of gaining control of the Metabase instance and using the privileges already configured for its database connections.

Administrator access can significantly increase the attacker’s reach.

Metabase can be configured with connections to production databases, data warehouses, and other internal data sources. Those connections may contain credentials or have permissions that allow substantial access to organizational data.

As a result, the compromise of Metabase can become a stepping stone into other systems.

The actual impact depends heavily on how the Metabase instance and its database connections are configured. A Metabase account with administrator privileges does not automatically mean that every connected database can be fully compromised; the attacker inherits the permissions available to the Metabase application and its configured connections.

Where a connected data source is configured with an over-privileged account, the blast radius can be significantly larger. An attacker who can run queries using those privileges may be able to read or modify data beyond the intended dataset.

Defenders should pay particular attention to unusual requests involving the password-reset endpoint, especially requests containing unexpected query-like characters or structures.

Potential indicators include:

• Unexpected requests to /api/session/reset_password.
• Suspicious or malformed values submitted to the reset endpoint, including an unexpected user-id field.
• A POST /api/session/reset_password returning HTTP 400 followed shortly by a successful GET /api/user/current (HTTP 200) may indicate exploitation and should be investigated in context.
• Unexpected changes to Metabase administrator accounts, or new administrator accounts (is_superuser = true in core_user) that cannot be tied to legitimate activity.
• Unexpected changes to user authentication or password-hash data without a corresponding user-initiated reset.
• Suspicious access to connected databases after abnormal reset activity.
• Unusual API-key creation or configuration changes.

Web-server, reverse-proxy, Metabase, and database logs should be correlated when investigating suspected exploitation.

The primary remediation is to upgrade Metabase to a fixed release appropriate for the installed branch.

For exposed self-hosted deployments:

1. Upgrade to a patched version for your branch.
2. If you cannot upgrade immediately, block or restrict access to the POST /api/session/reset_password endpoint at the WAF or reverse proxy.
3. Avoid exposing Metabase directly to the public internet where possible; place it behind a VPN or authenticated proxy.
4. Restrict access to administrative interfaces and sensitive endpoints through appropriate network controls.
5. Review administrator accounts for unexpected additions or privilege changes.
6. Review API keys and application configuration for unauthorized changes.
7. Review database access logs for suspicious activity.
8. Rotate credentials for connected databases if compromise is suspected — even on patched instances, assume attackers may have had time to read stored connection secrets.
9. Revoke active sessions and force re-authentication.
10. Use least-privilege accounts for Metabase’s connected databases rather than superuser accounts.

Metabase also provides a Security Center for self-hosted Pro and Enterprise deployments that can help administrators identify security issues affecting their instance.

The vulnerability can be validated using the CVE-2026-72898 lab available in OffSec’s Offensive Cyber Range (OCR). The lab provides a vulnerable Metabase instance together with the supporting components required to reproduce the attack in a controlled environment.

The lab demonstrates the vulnerability at the application level, starting with an unauthenticated request to the password-reset endpoint and progressing through SQL injection and authentication-data manipulation to administrator access.

The lab also provides an opportunity to observe the impact of the compromise on Metabase and its connected data sources, allowing the vulnerability and its potential attack path to be examined without using real organizational credentials or production systems.

• Metabase Security Advisory — GHSA-vwf4-m7j8-wcjf
• Metabase Security Update — Please upgrade now
• NVD — CVE-2026-72898
• CISA Known Exploited Vulnerabilities Catalog
• Bishop Fox — Critical SQL Injection in Metabase via Password Reset (CVE-2026-72898)
• Resecurity — Metabase Zero-Day Exploited in the Wild: Unauthenticated SQL Injection Leading to Full Admin Access
• IONIX — CVE-2026-72898 Threat Center
• Cyber Security News — Metabase 0-Day Vulnerability Exploited in the Wild

CVE-2026-72898 is a critical unauthenticated SQL injection in Metabase’s password-reset functionality.

The vulnerability is dangerous because it does not stop at database access. Successful exploitation can allow an attacker to manipulate Metabase’s authentication data and obtain administrator access. From there, the attacker may be able to access sensitive information and connected databases using the privileges already configured within the Metabase instance.

Metabase has confirmed active exploitation, so vulnerable self-hosted deployments should be treated as a high-priority patching issue.

Administrators should identify affected versions, upgrade to the appropriate fixed release, review the instance for signs of compromise, and rotate connected credentials if exploitation is suspected.