Metabase Critical SQL Injection: Affected Versions, Patches and Incident Response

By AiCybr Editorial · Published August 12, 2026 · Updated August 13, 2026

Metabase has disclosed a critical, actively exploited unauthenticated SQL-injection vulnerability tracked as CVE-2026-72898 / GHSA-vwf4-m7j8-wcjf. The flaw can let a remote attacker inject SQL into the Metabase application database, potentially obtain administrator access, alter configuration, steal credentials stored for connected databases, and access or export data available through those connections.

If you operate a self-hosted Metabase instance in an affected release line, the priority is straightforward: upgrade immediately. If the vulnerable reset-password endpoint was exposed to the internet, patching alone is not enough; Metabase also recommends invalidating sessions, checking administrative access and API keys, rotating downstream database credentials, and reviewing relevant logs.

What is affected?

GitHub's Metabase security advisory, published August 6, 2026 and updated August 11, lists the following affected and patched release ranges:

The advisory gives the issue a CVSS 3.1 score of 10.0 with network attack vector, low complexity, no required privileges and no required user interaction. The advisory now assigns CVE-2026-72898.

One detail deserves care: the affected-range notation and the fixed-version table in the advisory are not perfectly intuitive at every boundary. Operators should not try to infer that an unlisted intermediate build is safe. Use one of the explicitly listed fixed versions or a later supported release in that line.

Why this vulnerability is unusually serious

This is not merely an injection flaw against an isolated analytics database. Metabase often occupies a privileged position between users and multiple data systems.

According to the official advisory, successful exploitation can lead to administrator access to Metabase. From there, an attacker may be able to change application configuration, obtain credentials Metabase stores for connected databases, read data those connections can reach, and export it.

That creates a potentially larger blast radius than the Metabase host itself. A compromised analytics application can become a path into warehouses or databases whose credentials it holds.

Metabase also states that it has confirmed active exploitation. That changes the operational response: exposed affected systems should be treated as potentially compromised rather than simply as machines awaiting routine patching.

Immediate remediation

1. Upgrade to an explicitly fixed release

Upgrade to the fixed version for your current major release line, or to a later supported release that includes the fix. Metabase's advisory provides OSS and Enterprise Edition artifacts for each fixed branch.

Do not delay remediation merely to bundle it with a normal maintenance window. Active exploitation plus unauthenticated remote reachability makes this an emergency change for exposed affected systems.

2. If you cannot upgrade immediately, block the vulnerable endpoint

Metabase's temporary workaround is to block:

/api/session/reset_password

This is a temporary containment measure, not a substitute for upgrading. Apply the official patch as soon as possible.

If a reverse proxy, WAF or ingress controller performs the block, verify that alternate routing, path normalization or direct backend access cannot bypass it.

3. Do not stop at patching an exposed system

The official advisory specifically calls for additional response steps when /api/session/reset_password was publicly accessible.

Metabase recommends:

• revoking active user sessions by deleting rows from the core_session table in the Metabase application database;
• reviewing API keys and deleting unrecognized keys;
• reviewing administrator accounts for unexpected changes;
• rotating credentials for connected databases;
• reviewing data-warehouse logs for unauthorized access;
• reviewing Metabase activity and query history for unexpected activity.

These are compromise-response actions, not ordinary upgrade hygiene.

A practical incident-response order

For an internet-exposed affected deployment, a defensible sequence is:

1. Contain exposure. Upgrade immediately or temporarily block the affected endpoint while preparing the upgrade.
2. Preserve evidence. Retain application, proxy/WAF, authentication, database and infrastructure logs before normal retention or container replacement removes them.
3. Patch. Move to an explicitly fixed release.
4. Invalidate sessions. Follow Metabase's session-revocation guidance.
5. Audit identities and keys. Review administrators and API keys for unauthorized additions or changes.
6. Rotate connected-database credentials. Assume credentials accessible to a compromised Metabase administrator may have been exposed.
7. Review downstream databases. Look for unexpected queries, exports, authentication activity and changes during the possible exposure window.
8. Review Metabase history. Investigate unusual activity and query history.
9. Reduce the future blast radius. Revisit database-account privileges, network exposure and secret-management practices.

The exact forensic procedure depends on your environment. Large or regulated deployments should preserve evidence and involve their incident-response process before making destructive cleanup changes.

Why credential rotation matters

A common patching mistake is to treat the vulnerable application as the only asset at risk. The advisory explicitly warns that an attacker who reaches Metabase administrator access could steal stored credentials for connected databases.

That means rotating only Metabase user passwords may leave a durable path into downstream systems. Inventory every database connection configured in the affected instance and determine what each credential can access.

Where possible, use dedicated least-privilege service identities rather than broadly privileged shared database accounts. The goal is to ensure that compromise of an analytics layer cannot automatically become compromise of an entire warehouse.

What to look for in logs

The authoritative advisory should remain the source of truth for any subsequently published indicators. Even without relying on a single signature, defenders should correlate activity around the vulnerable reset-password path with signs of post-exploitation.

Useful evidence includes:

• requests to /api/session/reset_password, particularly unexpected internet-originating traffic;
• newly created or modified administrator accounts;
• unfamiliar API keys;
• unusual session creation or authentication patterns;
• unexpected queries or large exports from connected databases;
• database authentication from unusual hosts or at unusual times;
• configuration changes in Metabase;
• suspicious query-history entries around the suspected exposure period.

Absence of one log signature is not proof that an exposed vulnerable instance was not compromised.

Self-hosting lessons beyond this Metabase bug

The incident highlights a broader architecture problem in self-hosted analytics stacks: the application tier can be a credential concentration point.

A dashboard may look like a relatively low-risk internal service, yet its backend can hold credentials capable of querying production databases. Three controls substantially limit that blast radius:

Least-privilege database accounts. Give each analytics connection only the schemas and operations it actually needs. Read-only access is preferable where the workload permits it.

Restricted network exposure. An administrative analytics service rarely needs unrestricted public reachability. VPN, identity-aware proxy, private ingress or tightly scoped access controls can reduce attack surface, although none replaces patching.

Credential lifecycle discipline. Know which applications store which downstream credentials, and have a tested rotation process. Incident response becomes much slower when nobody can quickly enumerate the secrets held by a compromised service.

Cloud versus self-hosted deployments

The remediation burden described here is especially important for self-hosted operators because they control their own upgrade timing, exposure and downstream credentials. Managed-service customers should follow Metabase's service-specific communications rather than assuming that self-hosted upgrade instructions map directly to the managed environment.

Regardless of deployment model, organizations that receive a compromise notification should treat downstream credential and data-access review as part of the incident, not just the application patch.

Bottom line

CVE-2026-72898 / GHSA-vwf4-m7j8-wcjf deserves emergency treatment. It is remotely reachable without authentication, carries a CVSS 10.0 rating, and Metabase says exploitation has occurred in the wild.

For self-hosted operators, the minimum response is to move to an explicitly fixed release. For systems whose vulnerable reset-password endpoint was publicly accessible, the safer response is broader: patch, revoke sessions, audit administrators and API keys, rotate connected-database credentials, and review both Metabase and downstream data-system logs.

The most important architectural lesson is that an analytics server should be treated according to the value of the credentials and data it can reach, not merely according to the sensitivity of its own host.

Sources

• Metabase GitHub Security Advisory: CVE-2026-72898 / GHSA-vwf4-m7j8-wcjf
• Metabase security updates