Metabase zero-day turns BI dashboards into a data-exposure path

Metabase has confirmed active exploitation of CVE-2026-72898, a critical unauthenticated SQL injection flaw in the open-source business intelligence platform. CISA added the bug to its Known Exploited Vulnerabilities catalog on August 11, 2026, giving federal agencies until August 14 to apply vendor guidance under its risk-based patching rules.

The issue is dangerous because Metabase often sits between users and high-value data warehouses. According to Metabase and the GitHub advisory, an unauthenticated remote attacker can inject arbitrary SQL into the Metabase application database. That can lead to administrator access to the Metabase instance, configuration changes, theft of stored credentials for connected databases, access to data available through those connections, and data export.

For defenders, this is not only a dashboard bug. It is a breach path into the analytics control plane.

What happened

Metabase disclosed the security issue on August 6, 2026, after identifying attacks against Metabase Cloud involving a previously unknown vulnerability. Metabase said Cloud was patched before public disclosure, but self-hosted instances may be vulnerable and should be upgraded immediately.

CISA's KEV entry followed on August 11, naming the issue as a Metabase SQL Injection Vulnerability and tracking it as CVE-2026-72898. CISA's description says the flaw allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, potentially giving them administrator access. The KEV entry lists CWE-89 and marks known ransomware campaign use as unknown.

The GitHub security advisory for GHSA-vwf4-m7j8-wcjf is explicit about impact. Once inside the application database, the attacker may be able to change application configuration, steal credentials for connected databases, read accessible data, and export data.

That combination makes this a full vulnerability response and a possible data-breach investigation.

Why Metabase is a high-value target

Business intelligence platforms concentrate trust. They connect to production databases, warehouses, dashboards, reports, and executive metrics. Even when the BI layer is not the source of record, it can hold saved database credentials, API keys, user sessions, cached query context, and access paths into systems that store sensitive information.

That is why administrator access to Metabase matters. An attacker does not need to compromise every underlying database directly if the analytics layer already has permission to query them. A single exposed Metabase instance can become a bridge from an internet-facing web application into internal data stores.

The risk is higher for self-hosted deployments that are reachable from the internet, deployed quickly for internal analytics, or managed outside the same security baseline as production applications. In many organizations, BI tools grow organically. Access expands, dashboards multiply, and connected database permissions become broader than intended.

When a zero-day hits that layer, the blast radius follows the data connections.

Who should prioritize this

Security teams should treat CVE-2026-72898 as urgent if any self-hosted Metabase instance is exposed to users or the internet and runs an affected release branch. Public reporting and third-party analysis describe exposure across Metabase versions in the x.58 through x.63 release families, with patched point releases available for those branches.

Priority should go to:

• Internet-facing Metabase servers
• Metabase instances connected to production databases or data warehouses
• Deployments with saved database credentials
• Instances used by finance, healthcare, government, telecom, aviation, energy, or executive reporting teams
• Environments where Metabase administrator access can change data connections or export data
• Any tenant or self-hosted instance that was reachable during the pre-patch window

The practical question is not only "are we vulnerable?" It is also "what could Metabase read if an attacker became admin?"

Immediate actions

Patch first. Metabase recommends upgrading self-hosted deployments to the latest point release for the version branch in use. Public guidance lists fixed releases across the affected branches, including patched versions for x.58, x.59, x.60, x.61, x.62, and x.63.

If a same-day upgrade is not possible, Metabase guidance includes temporarily blocking the affected password-reset API route as a stopgap. That mitigation should be treated as temporary. It reduces exposure to the known path but does not replace upgrading to a fixed build.

After patching, assume that an exposed instance may require incident response, not just vulnerability management:

• Revoke all active Metabase user sessions.
• Review API keys and delete any unrecognized keys.
• Review administrator accounts for unexpected changes.
• Rotate credentials for connected databases.
• Review data warehouse and database logs for suspicious access.
• Review Metabase activity and query history for unexpected or unauthorized queries.
• Check configuration changes, new data sources, changed permissions, and unusual exports.

Those steps matter because the attacker objective may be data access, not just application control.

What to hunt

Defenders should look for signs that an attacker reached the password-reset flow, touched the application database, or used newly obtained administrator access.

Useful places to check include:

• Web and reverse-proxy logs for unusual requests to /api/session/reset_password
• Metabase application logs around password reset, session, and admin activity
• New or modified Metabase administrator users
• Unrecognized API keys or recently created service credentials
• Changes to database connection settings
• New dashboards, questions, pulses, subscriptions, or exports outside normal patterns
• Large or unusual database queries from the Metabase service account
• Access to sensitive tables shortly after suspicious Metabase activity
• Data warehouse authentication from unexpected IP addresses, service contexts, or time windows

An example Splunk hunt:

index=web OR index=proxy OR index=app
("Metabase" OR "/api/session/reset_password")
| stats count min(_time) as firstSeen max(_time) as lastSeen values(status) as status by src_ip, host, uri, user_agent
| sort -count

That query is only a starting point. Teams should combine web telemetry with Metabase logs and database audit logs to understand whether the incident crossed from exploit attempt to data access.

Reduce the blast radius

This incident is a useful reminder that analytics platforms need production-grade controls. Metabase should not be treated as a low-risk reporting app if it has access to sensitive datasets.

Practical hardening steps include:

• Keep Metabase behind SSO, conditional access, and network controls.
• Avoid exposing self-hosted BI platforms directly to the internet.
• Use least-privilege database accounts for each connection.
• Separate read-only reporting credentials from administrative database accounts.
• Rotate saved credentials on a documented schedule.
• Enable database audit logging for BI service accounts.
• Restrict who can create, edit, export, and share dashboards.
• Monitor exports, new data sources, and admin changes as security events.
• Maintain an inventory of BI tools and their connected datasets.

The goal is simple: if a dashboard platform is compromised, it should not automatically become a master key to the data estate.

The takeaway

CVE-2026-72898 shows why defenders need to think beyond application severity scores. A critical unauthenticated SQL injection in a BI tool is not just a web-app bug. It can expose the credentials and data relationships that make analytics useful in the first place.

For self-hosted Metabase users, the response should be immediate: upgrade, block the affected route only as a temporary measure if needed, revoke sessions, review admins and API keys, rotate connected database credentials, and audit downstream data access. Once a BI control plane is exposed, the investigation must follow the data.

References

1. Security update available for Metabase - Please upgrade immediately
2. SQL injection using an unauthenticated endpoint leading to admin access
3. CISA Known Exploited Vulnerabilities Catalog entry for CVE-2026-72898
4. CVE-2026-72898 Detail
5. How to find Metabase installations on your network
6. Metabase SQL Injection CVE-2026-72898