HomeAlerts & Advisories

Metabase SQL Injection Actively Exploited in the Wild (CVE-2026-70468)

Executive Summary

On August 10th, 2026, Metabase announced in a security advisory that they had been targeted in the wild with an undisclosed vulnerability. In the advisory, they identified a critical SQL injection vulnerability within their product and released patches, urging their users to upgrade. On August 11th, CISA confirmed active exploitation, adding the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog.

Tracked as CVE-2026-72898, the flaw allows a remote unauthenticated attacker to inject arbitrary SQL into Metabase’s internal application database via the password reset API endpoint, allowing full administrator access without any credentials.

Metabase is an open-source business intelligence platform where organizations connect directly to production databases and data warehouses to build dashboards and run analytics. Because Metabase instances hold credentials to these data stores, an attacker who exploits this endpoint has potential to pivot into an organization’s backend systems.

Metabase confirmed the vulnerability was exploited against its own Metabase Cloud service prior to public disclosure, and several self-hosted customers have since reported being impacted by the same flaw. Given the active exploitation and the sensitive data often accessible through Metabase deployments, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for signs of compromise.

Affected Systems and Products

 Product  Affected Version  Fixed Version

 Metabase Open-Source 58

 0.58.0-0.58.23

  0.58.24

 Metabase Open-Source 59

 0.59.0-0.59.20

  0.59.21

 Metabase Open-Source 60

 0.60.0-0.60.16

  0.60.17

 Metabase Open-Source 61

 0.61.0-0.61.10

  0.61.11

 Metabase Open-Source 62

 0.62.0-0.62.8

  0.62.9

 Metabase Open-Source 63

 0.63.0-0.63.4

  0.63.5

Mitigations and Workarounds

Upgrading to the release for your branch remediates this vulnerability; Metabase Cloud customers were patched automatically and do not need to take action. Given Metabase announced their Cloud instance was already attacked, users of this service should monitor communications from Metabase regarding whether their data was accessed. If the /api/session/reset_password endpoint on a self-hosted instance was publicly accessible, treat the instance as potentially compromised and take the following steps after upgrading:

  1. Remove the Metabase instance from publicly accessible networks.
  2. Revoke all active user sessions by deleting every row in the core_session table of the Metabase application database.
  3. Review API keys and delete any that are unrecognized.
  4. Review administrator accounts for unexpected changes.
  5. Rotate credentials for every database connected to the instance.
  6. Review data warehouse logs for signs of unauthorized access.
  7. Review Metabase activity and query history for unexpected activity.

Organizations that cannot upgrade immediately should consider blocking network access to their Metabase instance, and if possible, block the /api/session/reset_password endpoint at the reverse proxy or firewall as a temporary workaround until the update can be applied.

Patches

Metabase Cloud instances have already received the fix from the vendor. Metabase has released patched point releases for each affected self-hosted branch (58 through 63). Administrators can find the version numbers for affected products in the Affected Systems and Products section above. Update instructions and patches can be accessed within Metabase’s official security advisory.

Indicators of Compromise

Metabase has published the specific request sequence attackers used to exploit the flaw that defenders can watch for:

  • a POST request to /api/session/reset_password that returns a 400 http status code followed by
  • a GET request to /api/user/current which returns a 200 http status code.

Organizations that find this pattern in Metabase server ingress logs or application logs should look for signs of post exploitation activity and review Metabase for unexpected administrator accounts, unrecognized API keys, and unusual query activity against connected data warehouses. Regardless of exploitation activity, rotation of Metabase connection API keys should be considered if the organization had ran a publicly accessible Metabase instance before the vulnerability was disclosed.

Technical Details

The vulnerability stems from how Metabase's Clojure codebase handles undeclared fields in the password-reset API. The affected endpoint, POST /api/session/reset_password, is intended to accept only a token and password.

Metabase’s password reset endpoint builds a database query used to look up the account being reset but does not restrict which fields it accepts in the reset request body. An attacker could add additional unexpected fields alongside the expected parameters. Metabase’s query-building layer treated one of those fields as a structured query condition rather than an identifier. An attacker therefore could splice arbitrary SQL into the lookup query that would run against the Metabase application database before any authentication check occurs.

This internal database access allows an attacker to manipulate the reset flow, take over an administrator account, and gain full control of the instance. Metabase’s fix strictly limits the reset flow to its expected inputs, so extra fields can no longer reach the query.

Researchers at Bishop Fox, who published a technical analysis after the disclosure, described the root cause as a failure to restrict undeclared fields in the request body rather than a classic string-concatenation flaw.

At the time of publication, no proof-of-concept exploit code had been publicly released, potentially reducing exploitation of this vulnerability to a limited number of attackers. However, Framework and Tally have both confirmed attackers leveraged this vulnerability to exfiltrate customer records, password hashes, and API tokens beginning as early as August 3rd, 2026.

How Beazley Security is Responding

Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.

We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.

If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.

Sources

Download PDF

Aware of an incident impacting your industry? Let us know:

Report an incident