Metabase CVE-2026-72898: the SQL injection that hands over your database without credentials

On August 3, 2026, Metabase detected malicious activity against its Cloud service that exploited an unknown vulnerability. Three days later, on August 6, the company published a security advisory confirming an unauthenticated SQL injection with CVSS 10.0 — the highest possible score. On August 11, CISA added identifier CVE-2026-72898 to its Known Exploited Vulnerabilities catalog with a federal remediation deadline of August 14. For any team running Metabase on-premises, that same 72-hour window applies to their operational reality.

What the vulnerability actually is

CVE-2026-72898 is a SQL injection flaw (CWE-89) in Metabase's password reset endpoint (/reset_password). A remote attacker, unauthenticated and without user interaction, can inject arbitrary SQL against Metabase's internal application database. That database does not contain the customer's business data — it holds Metabase configuration, stored credentials for every connection to downstream data sources, and per-group permission mappings.

What makes this flaw devastating is not the SQL injection itself but what it unlocks. Once the attacker successfully executes SQL inside the application process, they can create or modify administrator accounts. With admin access to Metabase, they inherit the ability to query any connected data source — Snowflake warehouses, BigQuery data warehouses, internal Postgres clusters, connections to S3 services — and to execute native SQL against them. In deployments where Metabase's connections use accounts with elevated permissions, that means direct read access to production.

The vulnerability also allows exfiltration of stored credentials. Metabase stores the connection password for each database in its own internal schema; an attacker with read access can extract them in plaintext and reuse them outside Metabase, against the actual databases, extending the blast radius far beyond the BI dashboard.

Affected versions and exploitation vector

The range of affected versions is wide: any Metabase between x.58.0 and x.63.4 is at risk. That spans six major release branches, atypical for a vulnerability of this severity. The reason is that the vulnerable endpoint — the password reset logic that writes to the user table — has maintained the same flawed structure across multiple releases. Patches shipped August 6 for all affected branches (x.58, x.59, x.60, x.61, x.62, x.63), and administrators must update to the latest version of their branch.

The attack vector is HTTP(S). The attacker sends a crafted request to the reset endpoint with a payload that breaks the SQL query construction. Attack complexity is low, no credentials or interaction required, and EPSS assigns a 10.4% exploitation probability. CISA does not add CVEs to KEV on suspicion — it adds them on confirmation, and the August 11 inclusion confirms active exploitation in real production, not just proof-of-concept in a lab.

Why it matters to data teams

Metabase is one of the most deployed open-source BI platforms in the world. Its typical use case is serving as a self-service layer on top of a data warehouse: business analysts run ad-hoc queries, product teams build dashboards, and the organization exposes metrics to stakeholders without going through the central analytics team. That same accessibility that makes it useful amplifies the risk: a vulnerability in Metabase compromises the entire connected data surface.

Unlike a traditional application server, where a SQL injection might expose data for a single service, Metabase is an aggregator by design. A single instance typically has between 5 and 50 active connections to downstream systems — a mix of Postgres, MySQL, BigQuery, Snowflake, Redshift, MongoDB, and external APIs via connectors. If your instance has production connections, an attacker with admin on Metabase has visibility over all of them. If those connections use service accounts with broad permissions (a common anti-pattern in Metabase because the admin panel does not enforce fine-grained scoping), the attacker also has write capability.

The Horizon3 team that discovered the vulnerability documented the vector in detail and published a technical analysis with the remediation timeline. Metabase responded in 72 hours — a reasonable response cycle for a critical zero-day — but the operational reality is that many organizations run Metabase with weeks-to-months of patch lag, especially in self-managed Kubernetes clusters where updates require coordination with Helm charts, persistent volumes, and CI pipelines.

Confirmed timeline

August 3, 2026: Metabase discovers attacks against Metabase Cloud involving a previously unknown vulnerability and begins investigation and containment.

August 6, 2026: Metabase publishes security advisory for CVE-2026-72898, confirming the vulnerability as a critical unauthenticated SQL injection with active exploitation. Patched releases available for all affected branches (x.58 through x.63).

August 11, 2026: CISA confirms active exploitation and adds CVE-2026-72898 to the KEV catalog with a federal remediation deadline of August 14.

The window between discovery and patch was three days. The window between patch and KEV entry was five days. Those two windows together define the maximum risk zone: the exploit worked in production, already existed in attacker hands before the advisory, and teams that did not patch within that first week were permanently exposed.

What to do now if you run Metabase

First, identify instances: any Metabase on-premises or self-hosted between x.58.0 and x.63.4 is at risk. Search your Docker registries, Helm repos, Kubernetes manifests, and any inventory documents. If you use Metabase Cloud, the vendor already applied the patch — but review your tenant's access logs for suspicious activity prior to August 6.

Second, patch immediately. Update to the latest version available for your branch (x.58.25+, x.59.22+, x.60.18+, x.61.12+, x.62.10+, x.63.5+ minimum, depending on your branch). If you run Metabase on Kubernetes, coordinate the update with your Helm or Kustomize pipeline — rolling restarts on deployments with StatefulSets and persistent volumes require specific ordering.

Third, assume compromise if you did not patch before August 6. Evidence of active exploitation existed since August 3, before the public advisory. Review Metabase application logs looking for:

- Anomalous requests to the /reset_password endpoint with extended payloads or special characters in expected parameters. - Creation or modification of administrator accounts outside your normal provisioning process. - Outbound connections from the Metabase pod to unexpected external IPs (indicator of credential exfiltration). - Changes in database connection configuration — modified connection strings, rotated credentials without corresponding ticket.

Fourth, rotate all credentials stored in Metabase. Do not assume only admin accounts could have been read. Any credential Metabase stored — for internal databases, data warehouses, external APIs — must be considered compromised and rotated on the destination system.

Fifth, review the permission scoping of your connections. This incident is an opportunity to stop using accounts with broad permissions and move to accounts with minimal permissions per dataset, per operation, and per lifetime. Metabase supports OAuth for many modern connections and short-expiration tokens for APIs; use them instead of static passwords.

Temporary mitigations if you cannot patch today

If there is an operational reason that delays patching — a cluster in migration, a regulated environment with strict change windows, a downstream dependency that requires testing — there are partial mitigations that reduce but do not eliminate the risk.

Block access to the /reset_password endpoint at your reverse proxy or API gateway. It is not a complete solution because the vector might have alternative paths, but it reduces the attackable surface to the documented pattern. Implement WAF rules that block suspicious payloads to the endpoint: requests with UNION SELECT, unescaped quotes in email fields, or anomalous lengths in URL parameters.

Place Metabase behind additional network authentication. If your Metabase does not need to be public, restrict it to a VPN or zero-trust network access. The vulnerability requires HTTP access to the vulnerable endpoint; removing non-public network access eliminates the vector.

Enable detailed logging on the endpoint and monitor aggressively. Any hit to /reset_password from an IP outside your known inventory should generate an alert.

None of these mitigations is a substitute for the patch. They are temporary defenses while you coordinate the update. The patch is the only complete solution.

Structural lessons

CVE-2026-72898 is not just a bug in Metabase. It is a pattern that repeats in every BI, dashboarding, and data aggregation tool: software that by design concentrates access to multiple downstream systems, with stored credentials, and with public endpoints. Tableau, Looker, Superset, Power BI Embedded — all share the same risk profile. The question is not whether another vulnerability of this type will appear in another platform, but when.

For data platform teams, this incident reinforces three practices that are not optional:

Principle of least privilege on stored credentials. Every Metabase connection to a downstream database must use an account with the minimum permissions necessary for the queries the panel runs. If your sales dashboard only reads from a specific view, the service account must only be able to read that view — not the whole database, not write, not create tables.

Regular credential rotation. Credentials in any aggregator system are only as secure as their last rotation. If Metabase holds a password you have not rotated in 18 months, that password is functionally public. Implement automatic rotation where possible (Vault with dynamic secrets, IAM roles for AWS, service accounts with short expiration).

Periodic exposure audit. Who has access to your Metabase instance? What connections does it have configured? When was the last time you reviewed administrator accounts? A 30-minute quarterly audit detects obsolete configurations and orphaned accounts before an attacker finds them.

The CVE-2026-72898 vulnerability is remediated, but the risk category it represents — public endpoints that expose access to internal credentials — will continue producing incidents. The difference between a contained incident and a massive breach will be whether your team already had these controls in place when the next case arrives.