Metabase CVE-2026-72898: The CVSS 10.0 SQL Injection That Breached Multiple Production Environments

On August 6, 2026, Metabase — one of the most widely deployed open source business intelligence platforms in the world — disclosed a SQL injection vulnerability that has since proven to be one of the most consequential zero-day events of the year. Tracked as CVE-2026-72898, the flaw carries the maximum possible CVSS score of 10.0. Within days of the public disclosure, several high profile technology companies confirmed they had been compromised through the vulnerability, and the incident has exposed a class of risk that extends far beyond the list of named victims: every organization that runs an OEM version of Metabase inside a larger product may not even know they are exposed.

This article walks through what happened, who was affected, how the exploitation works at a technical level, and what every DevSecOps team should do right now to detect and contain exposure in their own environments.

The vulnerability in plain language

CVE-2026-72898 is a SQL injection flaw in the Metabase BI server, present in versions 1.58 and later. According to the vendor advisory and subsequent reporting from CSO Online, the bug allows an unauthenticated remote attacker to bypass normal application boundaries and issue arbitrary queries against the underlying application database. The result is what incident responders are calling "unmitigated, raw" database access — not a constrained read of pre-approved views, but the ability to read tables, dump credentials, and pivot into connected data sources.

"You don't see a perfect 10/10 on CVSS often, but when you do, be worried," noted David Shipley, CEO of Beauceron Security, in comments to CSO Online. Shipley's concern is well placed. SQL injection has been a known vulnerability class for more than two decades, and a CVSS 10.0 score on a SQL injection flaw implies that exploitation requires no authentication, no user interaction, and produces full compromise of the confidentiality, integrity, and availability of the affected component.

The flaw is particularly dangerous because Metabase is, by design, a system that sits close to an organization's most sensitive data warehouses. A BI platform exists to translate business questions into SQL. When that same platform can be coerced into running attacker-supplied SQL against the database that holds the answers, the consequences are immediate and severe.

Who has been confirmed as compromised

Within a week of disclosure, several named organizations publicly confirmed they had been impacted by exploitation of CVE-2026-72898. The list, as reported by CSO Online, includes:

- **Kilo Code**, a development tooling provider that was recently acquired by Anaconda. - **Tally**, a Y Combinator backed company building autonomous accounting agents. - **Framework**, the personal computer manufacturer known for modular laptops. - **n8n**, the workflow automation platform that hosts a large open source community. - **ChecklyHQ**, an AI testing and monitoring platform provider.

The impacted companies report that threat actors accessed records containing usernames, email addresses, cloud passwords, cryptographic hashes of OpenTelemetry (OTel) API keys used for trace collection, Slack access tokens, and other sensitive information. Each organization has stated publicly that it is directly contacting impacted customers and has taken mitigation actions including rotating potentially impacted credentials and API keys, resetting all user passwords, invalidating all Slackbot authentication tokens for impacted users, removing compromised admin accounts, and reviewing internal audit logs.

Checkly's public notice framed the responsibility clearly: "The vulnerability was in a vendor's product, but protecting your data is our job, and this incident put some of it at risk." That statement captures the core lesson — vendor zero-days are an operational risk that any customer must plan for, even when the underlying product is trusted and widely used.

The OEM risk: products you did not know used Metabase

One of the most important warnings to come out of this incident is about original equipment manufacturer (OEM) embedding. Many commercial products integrate Metabase under the hood to provide built-in dashboards, usage analytics, or audit reporting. When Metabase is embedded this way, the customer of the larger product is often unaware that they are running Metabase at all.

Industry observers have warned that affected users may not even know they are affected, because they are not aware that Metabase is part of the product they purchased. This means that the list of confirmed victims is almost certainly incomplete. Every DevSecOps team that uses a SaaS product with embedded analytics, internal dashboards, or out-of-the-box reporting should ask their vendors, in writing, whether their product embeds Metabase and whether it has been patched to a version that is not vulnerable.

How the exploitation works

Metabase ships with a SQL editor and a query execution layer that translates user-facing questions into database queries. The vulnerability is in the way certain query parameters are constructed and passed through to the underlying database engine. While Metabase has not published a complete technical write-up, the pattern of behavior observed in incident response and the existence of working proof of concept exploit code indicate that an attacker can craft requests that are interpreted by the application as legitimate query instructions but are processed by the database as raw SQL.

The exploitation does not require valid credentials. It does not require user interaction. The attacker only needs network reachability to the Metabase service. In cloud deployments where Metabase is exposed to the public internet — a configuration that remains common in smaller organizations — this means the bar to entry is essentially zero. In on-premise deployments, the risk shifts to internal network exposure, lateral movement from compromised hosts, and any VPN or zero-trust misconfiguration that allows an attacker to reach internal services.

Working exploit code is now publicly available, which dramatically lowers the barrier for opportunistic attackers. Scanning for vulnerable Metabase instances began almost immediately after disclosure, and threat intelligence teams have reported widespread probing of common ports and paths associated with Metabase deployments.

Detection: what to look for right now

If you operate a Metabase instance, you should be hunting for indicators of compromise immediately. Specific signals to investigate include:

- Unusual database query patterns that reference system tables, credential tables, or tables outside the normal BI workload. - Connections to the Metabase database from IP addresses that do not match normal application or admin activity. - Outbound traffic from the Metabase host to destinations that do not match typical database client behavior, particularly DNS over HTTPS and encrypted C2 channels. - Changes to Metabase admin accounts, password hashes, or session secrets in the application database. - Connections from Metabase to data warehouses that the application is not configured to use. - New OAuth tokens, API keys, or personal access tokens issued by connected services shortly before or after the disclosure window.

Log sources that matter most here are the application database's audit log, the Metabase server's own application logs, the network egress logs from the host or subnet where Metabase runs, and any identity provider logs for the SaaS services that Metabase is connected to.

If you cannot produce a clean timeline of who accessed your Metabase instance between the August 6 disclosure and the moment you patched, you should assume that credential and token rotation is necessary across every downstream service that Metabase was permitted to authenticate to.

Mitigation and remediation

The vendor has shipped a patched version that closes the vulnerability. The first action item is to identify every Metabase instance in your environment, including OEM deployments, and confirm it is running a version that is not affected.

Beyond patching, the immediate operational checklist should include:

1. **Rotate all credentials and tokens stored in or accessible through Metabase.** This includes database passwords, OAuth refresh tokens, API keys, and any personal access tokens issued to users via the connected services. 2. **Reset all Metabase user passwords** and force a session invalidation across the deployment. 3. **Invalidate Slack, GitHub, Google Workspace, and any other third-party tokens** that Metabase was authorized to use. If your organization uses Slack, every Slack token issued through Metabase should be considered compromised. 4. **Review admin accounts** for any accounts that were created, modified, or granted elevated roles after the disclosure window without a matching change ticket. 5. **Audit downstream service logs** for unusual activity originating from the Metabase service account or from credentials stored in Metabase. 6. **Restrict network exposure** so that Metabase is no longer reachable from the public internet unless absolutely required. Where internet exposure is unavoidable, put Metabase behind a VPN, a zero-trust network access broker, or at minimum an authenticated reverse proxy.

The bigger lesson: BI platforms are tier zero

A recurring theme in incident response literature is that systems with privileged access to data are tier zero assets in the security model, regardless of how the organization classifies them in the asset inventory. Metabase, Looker, Tableau, Superset, Power BI, and similar BI tools all sit on a privileged path to an organization's most sensitive data. They hold credentials to data warehouses, they can read raw rows, and they can be used to issue queries that span the entire data estate.

Most organizations do not treat their BI platform with the same operational discipline they apply to a production database or an identity provider. This incident is a strong argument for changing that. Practical steps that follow from this mindset shift include:

- Mandatory MFA on every BI platform administrative account. - Just-in-time access for BI admin operations, with session recording and approval workflows. - Read-only service accounts wherever the BI workload does not require write access. - Network segmentation that places BI platforms on a dedicated subnet with tightly scoped egress controls. - An entry in the incident response runbook specifically for BI platform compromise, including which credentials to rotate and in what order.

How to talk to your executives about this

Boards and executive teams are rightly concerned about vendor concentration risk and supply chain security. CVE-2026-72898 is a useful case study because it is concrete, recent, and involves companies that the executive team has likely heard of. The framing should be straightforward: a vulnerability with the maximum possible severity score was disclosed in a product we use, working exploit code is public, and several well known technology companies have already confirmed compromise. The question for the executive team is not whether vendor zero-days will happen again — they will — but whether our detection and response capability is good enough to catch a compromise within hours rather than weeks.

A deeper look at the technical mechanism

For engineering teams that want to understand what is actually being exploited, it is worth describing the mechanics in more detail. Metabase operates as a three tier application: a web frontend, an application server written in Clojure, and one or more connected data sources — typically PostgreSQL, MySQL, BigQuery, Snowflake, or a comparable warehouse. When a user authors a dashboard or a native SQL question, the application server constructs a query plan, applies the configured data access permissions, and forwards the SQL to the target warehouse through a connection pool. The data access permissions layer is supposed to constrain what an authenticated user can see and what operations they can perform.

The vulnerability bypasses that permissions layer at the request handling boundary. In effect, an attacker who can reach the Metabase HTTP endpoint can submit a crafted request that the application server treats as legitimate input but the underlying database engine interprets as raw SQL. Because the request reaches the database before the permissions filter is fully applied, the attacker's query executes in a context that is closer to the application service account than to any specific user. That service account almost always has broader read access than any individual user, and in many deployments it has full read access to the entire warehouse schema. The result is that a single crafted request can return tables, credentials, and configuration data that no authenticated user would ever be allowed to see through the normal UI.

This pattern — privilege escalation through input that crosses a trust boundary — is the canonical SQL injection scenario, and it is why SQL injection has remained a top tier vulnerability class for more than two decades. The defensive lesson is that any system that constructs SQL from user input must use parameterized queries at every boundary and must never trust request bodies, headers, cookies, or URL parameters to contain only safe values. BI platforms are particularly exposed because their entire purpose is to translate user input into SQL, which means the surface area for injection is large and the temptation to use string concatenation in performance sensitive paths is real.

Response cadence: the first 24 hours

A useful operational pattern that emerged from the named victims' disclosures is the first 24 hour response cadence. Within the first hour, the immediate priorities are to identify every Metabase instance, confirm whether each one is exposed to any untrusted network, and apply the vendor patch or take the instance offline if patching is not possible. Within the first four hours, the focus shifts to credential and token rotation for every downstream service that Metabase was authorized to access, beginning with the highest privilege integrations and working down. Within the first twelve hours, internal communications should be drafted and sent to the customer base, and external counsel should be engaged if the rotation surfaces evidence of customer data exposure. Within twenty four hours, a clean timeline of activity on every affected Metabase instance should be ready for review, and the organization should have a defensible position on what was accessed, when, and by whom.

Teams that have rehearsed this cadence will move faster and with less panic than teams that are improvising. CVE-2026-72898 is a good opportunity to run a tabletop exercise against, regardless of whether your organization uses Metabase directly.

Closing thoughts

CVE-2026-72898 is not a sophisticated attack. It is a well known vulnerability class in a widely deployed product, weaponized within days of disclosure. The lesson is not new. What is new is the scale of the impact and the speed at which it materialized. DevSecOps teams that treat their BI platform as a tier zero asset, that maintain a current inventory of every embedded instance of every BI product they use, and that have a rehearsed playbook for credential and token rotation will weather this incident and the next one. Teams that do not will continue to learn the same lesson the hard way.

The full vendor advisory, including patched versions and migration notes, is the source of truth for any remediation work. This article is intended to provide the technical and operational context your team needs to act on that advisory with speed and confidence.