CVE-2026-72899: Metabase SQL Injection Bug - What It Means for Your Business and How to Respond

Introduction

CVE-2026-72899 is a critical vulnerability affecting Metabase, a widely used business intelligence and analytics platform. If your organization publishes Metabase dashboards or reports for customers, partners, employees, or the public, this issue deserves immediate attention. The weakness can allow an unauthenticated internet user to manipulate a vulnerable shared dashboard or card and potentially access or alter data without a valid account.

For organizations across the United States and Canada, the concern is not limited to a reporting application. Analytics platforms often connect to sensitive operational, financial, customer, health, or workforce data. A successful compromise can disrupt reporting, expose confidential information, damage trust, and create regulatory obligations.

This article explains the business impact of CVE-2026-72899, provides practical exposure checks and response priorities, and includes a technical appendix for security, infrastructure, and penetration-testing teams. The vulnerability has a critical CVSS score of 10.0.

Background & History

CVE-2026-72899 was published on August 10, 2026, and affects Metabase deployments that expose publicly shared cards or dashboards with a field-filter, also called a dimension parameter. The vulnerability allows an unauthenticated attacker to inject arbitrary database commands through that public-facing input. In plain language, a report filter that should accept ordinary values may be manipulated to make the system run unintended database queries.

The issue is categorized as SQL injection, formally CWE-89, meaning the application does not properly neutralize special database-language characters in externally influenced input. The CVE record identifies a critical CVSS 4.0 base score of 10.0, the highest severity rating.

The public CVE record was issued through the U.S. Cybersecurity and Infrastructure Security Agency as the assigning authority, while the NIST National Vulnerability Database published the record and later updated it on August 26, 2026. Metabase security updates address affected release lines 58 through 63.

What This Means for Your Business

If you operate an affected Metabase instance with a vulnerable public dashboard or card, your exposure can exist without an attacker needing an employee account, password, or approved connection. That lowers the barrier to attack and makes external-facing analytics especially important to review.

Your immediate business risk depends on what the affected Metabase instance can reach. Many organizations connect business intelligence systems to databases containing customer records, revenue figures, employee information, supply-chain data, product activity, or internal performance metrics. A compromise could expose information that was never intended for public reporting, corrupt application data, or interrupt the dashboards decision-makers rely on.

The operational effects can spread quickly. Sales, finance, support, executive, and operations teams may lose confidence in reports if data is changed or dashboards are taken offline for investigation. Customer-facing analytics may become unavailable during remediation. If sensitive personal information is involved, you may need legal review, notification analysis, forensic support, and communications planning under applicable U.S. state, Canadian federal, provincial, contractual, or sector-specific requirements.

Reputational damage can be significant because reporting portals often represent your organization directly to customers and partners. Treat this as a potential business-data exposure, not simply a routine software update. The unauthenticated nature of the vulnerability and its critical rating warrant a prompt, documented response.

Real-World Examples

Regional Bank: A regional bank uses public-facing dashboards to share community lending and branch-service trends. A vulnerable filter on a shared dashboard could provide an attacker a path to query the Metabase application database, creating concern that internal reporting configuration, connected-data metadata, or accessible business records could be exposed. The bank may need to suspend public dashboards while it assesses the scope, potentially affecting customer communications and regulatory reporting workflows.

Mid-Market Manufacturer: A manufacturer provides selected distributors with dashboards showing inventory availability, order fulfillment, and product demand. If a public dashboard is vulnerable, an attacker could attempt to access data beyond the intended distributor view. This could expose pricing intelligence, supply-chain information, or operational details that weaken the company’s competitive position and strain partner relationships.

Healthcare Services Provider: A healthcare services organization uses Metabase to publish limited operational reporting for affiliates. An exposed dashboard could create a pathway into systems connected to sensitive service, scheduling, billing, or workforce information. Even if the public report contains no personal information, the organization must investigate whether the analytics platform’s database connections could make protected information accessible.

Software-as-a-Service Provider: A growing software company embeds analytics in a customer portal through publicly available reporting links. A compromise could affect multiple customers at once, leading to service interruption, contract notifications, incident-response costs, and difficult questions about tenant separation. The organization must verify both the platform version and every public sharing configuration rather than assuming user login protections are sufficient.

Am I Affected?

• You are running Metabase versions 58.0 through 58.23, 59.0 through 59.20, 60.0 through 60.16, 61.0 through 61.10, 62.0 through 62.8, or 63.0 through 63.4.
• You use self-hosted Metabase or an enterprise deployment that includes publicly shared cards, dashboards, guest embeds, or unauthenticated report links.
• You have shared dashboards that expose field-filter or dimension parameters to external users.
• Your Metabase environment connects to databases containing customer, employee, financial, operational, or otherwise sensitive business data.
• You do not have a complete inventory of public Metabase links, embedded dashboards, and data-source permissions.
• You are not affected by this specific exposure if you are on patched versions 58.24, 59.21, 60.17, 61.11, 62.9, or 63.5 or later, and have confirmed that the upgrade completed successfully.
• You may have lower immediate exposure if public sharing is disabled, but you should still patch because configurations can change and exposure assessments can be incomplete.

Key Takeaways

• CVE-2026-72899 is a critical SQL injection vulnerability in Metabase that can be exploited remotely without authentication when vulnerable public dashboard or card filters are exposed.
• Your highest priority is to identify public Metabase links and determine whether they use vulnerable field-filter or dimension parameters.
• A successful attack can affect confidential data, reporting integrity, operational continuity, compliance obligations, and customer confidence.
• Apply the official Metabase security update for your release line as soon as possible, then validate that public sharing and database permissions remain appropriate.
• If you cannot patch immediately, reduce exposure by disabling public sharing or removing vulnerable public filters until the patched release is deployed.

Call to Action

CVE-2026-72899 is a reminder that externally accessible analytics platforms require the same disciplined security testing as customer portals and core applications. IntegSec can help you identify exploitable exposure paths, validate remediation, review public dashboard configurations, and test the controls surrounding your business data. Contact IntegSec to schedule a penetration test and strengthen your cybersecurity posture through targeted, evidence-based risk reduction.

Technical Appendix

A — Technical Analysis

CVE-2026-72899 is an unauthenticated SQL injection vulnerability in Metabase public sharing functionality. The affected attack surface is a publicly shared card or dashboard that exposes a field-filter, described in Metabase as a dimension parameter. An attacker can submit crafted parameter content through a publicly accessible endpoint and cause arbitrary SQL to be injected into database operations associated with the Metabase application database.

The weakness is classified as CWE-89, Improper Neutralization of Special Elements used in an SQL Command. The root cause is insufficient handling of externally influenced input before SQL construction or execution. No authenticated Metabase account, elevated application privilege, user interaction, or local network position is required for exploitation when the vulnerable public feature is exposed.

The CNA-provided CVSS 4.0 vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, producing a base score of 10.0, Critical. This reflects network reachability, low complexity, no required privileges or interaction, and high impact to confidentiality, integrity, and availability across the vulnerable and subsequent systems. The authoritative NVD entry remains the primary reference.

B — Detection & Verification

Confirm the deployed Metabase version before conducting deeper validation. Common containerized and standalone checks include:

Review versioning against the affected ranges: 58.0 through 58.23, 59.0 through 59.20, 60.0 through 60.16, 61.0 through 61.10, 62.0 through 62.8, and 63.0 through 63.4. Patched releases are 58.24, 59.21, 60.17, 61.11, 62.9, and 63.5 or later.

• Scanner signatures should identify Metabase instances in affected release ranges and flag publicly reachable instances where public cards, dashboards, guest embeds, or field-filter parameters are enabled.
• Review reverse-proxy, web application firewall, load-balancer, and Metabase logs for requests to public dashboard or card endpoints with unusually long, encoded, malformed, or SQL-like parameter values.
• Investigate database logs for failed query parsing, syntax errors, unexpected unions, comments, time-delay functions, metadata-table access, or queries originating from the Metabase service account outside normal report patterns.
• Monitor for unexplained database load, slow dashboards, altered report results, unexpected Metabase application errors, or outbound traffic from the Metabase host inconsistent with normal operations.
• Verify findings only in an authorized testing environment or under a defined rules-of-engagement process. Avoid using production payloads that could alter data or impair service.

C — Mitigation & Remediation

1. Immediate (0–24h): Identify all Metabase instances, their versions, and whether they expose public cards, dashboards, guest embeds, or field-filter parameters. Disable public sharing for affected content where business operations allow. If public reporting must remain available, remove or redesign exposed field-filter parameters until the instance is patched. Restrict internet access through network controls, allow lists, virtual private network access, or an authenticated reverse proxy where feasible.
2. Short-term (1–7d): Apply Metabase’s official patched release appropriate to your version line: 58.24, 59.21, 60.17, 61.11, 62.9, or 63.5 or later. Validate the upgrade in a staging environment, back up the Metabase application database and configuration, then deploy through normal change control. After deployment, confirm the running version, retest authorized public-sharing workflows, inventory remaining public links, and review the database credentials configured for Metabase.
3. Long-term (ongoing): Apply least privilege to the database identity used by Metabase. It should have only the schemas, tables, operations, and environments necessary for analytics. Separate public or embedded reporting data from sensitive production data where practical, use read-only accounts for reporting, rotate relevant credentials after a suspected compromise, and retain logs sufficient for investigation. Establish recurring external-attack-surface reviews and application penetration tests for public dashboards, embedded analytics, and changes to sharing features.

• Do not rely only on a web application firewall. Filtering may reduce opportunistic traffic, but it does not replace the vendor patch or safe parameter handling.
• If compromise is suspected, preserve relevant application, proxy, and database logs before rotation; initiate incident response; review Metabase service-account activity; and determine whether data access, changes, or extraction occurred.
• Confirm that upgrades do not silently restore public sharing settings or broaden service-account privileges. Remediation should include both the software patch and configuration assurance.

D — Best Practices

• Keep internet-facing analytics platforms on supported releases and prioritize critical vendor security updates through an established emergency patching process.
• Maintain an accurate inventory of every public dashboard, guest embed, share link, exposed parameter, data source, and responsible business owner.
• Apply least-privilege database access so a reporting platform cannot read or modify data beyond its defined reporting purpose.
• Use separate read-only reporting replicas, curated datasets, or limited database views for public and partner-facing analytics whenever practical.
• Send Metabase, web-proxy, and database logs to centralized monitoring, then alert on anomalous public-parameter requests and unexpected query behavior.