DEV Community

StarkMan
StarkMan

Posted on

Metabase CVE-2026-72898: an unauthenticated SQL injection that hands over the data warehouse

Metabase CVE-2026-72898: an unauthenticated SQL injection that hands over the data warehouse

Opening

Metabase is a business intelligence front end. People connect it to the warehouse, point it at tables, and build dashboards that executives read. To do that, it must hold database credentials, often with broad read access and frequently with write access. CVE-2026-72898 turned that design into a single unauthenticated request.
The flaw is an SQL injection rated 10.0 under CVSS 3.1, tracked as CWE-89, in the user-id field of the /api/session/reset_password endpoint. CISA added it to the Known Exploited Vulnerabilities catalog on 11 August 2026 with a federal remediation deadline of 14 August: three days. Fixed releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5 for the open-source line, with corresponding Enterprise 1.58.x through 1.63.x fixes. The advisory is GHSA-vwf4-m7j8-wcjf.

Technical context

What the injection actually does

The password-reset endpoint is unauthenticated by necessity: a user who has forgotten a password cannot present a session. The user-id parameter is passed into a query, and according to reporting on the flaw it reaches Metabase's HoneySQL layer without sufficient parameterisation. A crafted raw payload injects arbitrary SQL, and the published exploitation pattern is a stacked INSERT that creates a session row for an attacker-chosen administrator. The result is a forged administrator session rather than blind data extraction.

Why the endpoint choice matters

Password reset is a low-suspicion target. It is expected to receive unauthenticated POST requests, it is rarely the subject of the same scrutiny as login, and it frequently sits outside the specific rule sets tuned for authentication endpoints. An attacker does not need to find a session, guess a password or defeat multi-factor authentication. The injection produces the session directly.

Impact shape

The affected range runs across six minor release lines, which is a wide band of live deployments. Wiz estimated roughly 2,500 exposed Metabase instances through Shodan, a figure that describes internet-reachable deployments rather than confirmed victims. The version spread matters more than the count: 0.58 through 0.63 is roughly a two-year window of releases.

Explanation and walkthrough

The credential aggregation problem

The remediation many teams will want to skip is the credential rotation, because it is the expensive part. It is also the part that determines whether the incident is over.
A BI platform is a credential concentrator by design. Reporting on this event indicates that credentials recovered from affected Metabase deployments covered PostgreSQL, MySQL, SQL Server, Snowflake, BigQuery and Redshift. These are not the credentials of the BI tool; they are the keys to the systems the BI tool was permitted to read. An attacker who obtains them does not need to keep access to Metabase. The downstream warehouses are the objective, and the BI tool was simply the shortest path to them.

Who was affected

Public reporting named a set of organisations in connection with the campaign, described as the work of ShinyHunters: Framework, Tally, n8n, Kilo Code, ChecklyHQ, Scalingo and Mathspace. The Mathspace disclosure is the one that shows the shape of the harm clearly, with reporting of 1,079,819 students, parents and staff in Australia and New Zealand. Trezor was separately reported with around 81,000 people affected. A public proof of concept appeared at github.com/0xBlackash/CVE-2026-72898.

The three-day deadline

The KEV deadline of 14 August, three days after listing, reflects the combination of unauthenticated network reachability and an injection that produces administrative control. KEV deadlines are a remediation timer that starts once exploitation has already been observed elsewhere, not a ranking of how bad a bug is.

Defensive implications

  • Patch first, then rotate. Both parts are required. Patching closes the injection; rotating closes the access the injection may already have produced. A rotation that reuses the same credential values achieves nothing.
  • Inventory the BI layer as a credential holder. Any platform that stores warehouse connections should be classified by what those connections can reach, not by how internal it feels.
  • Do not stop at the dashboard. Review query history and database-side audit logs for reads against tables the reporting workload never touches.
  • Check for injected sessions. An administrator account created by stacked INSERT may look like a normal user record. Compare session and user tables against a known-good baseline.
  • Treat every affected version line as its own migration. Six lines were patched. An estate that skipped several minor releases cannot apply one fix and be done.
  • Reconsider whether the BI endpoint needs internet exposure at all. A reporting tool is used by staff. In most organisations, that places it behind a VPN or identity-aware proxy, not on a public address.

References

  • GitHub Security Advisory GHSA-vwf4-m7j8-wcjf
  • NVD: CVE-2026-72898
  • CISA Known Exploited Vulnerabilities catalog
  • Wiz research on exposed Metabase instances
  • Public proof of concept: https://github.com/0xBlackash/CVE-2026-72898
  • Metabase release notes for 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5

Top comments (0)