Metabase Cloud under attack: the unpatched SQL injection zero-day putting your entire organization at risk

An SQL injection zero-day vulnerability in Metabase Cloud, the AI-driven business analytics platform, is being actively exploited in production right now. What makes this incident particularly serious is not just the compromise of Metabase's direct customers: the true blast radius extends downstream to any organization whose credentials, data and internal configurations have ever passed through a connected instance. At the time of writing, the vulnerability still does not have an assigned CVE identifier, but Metabase gave it the maximum CVSS score of 10.0 and confirmed that exploitation allows a remote attacker to inject SQL statements into the application's internal database, which in practice is equivalent to obtaining full administrative access to the instance.

What we know about the attack

Metabase CEO Sameer Al-Sakran published a post confirming that the company's cloud platform was compromised by an attacker who used this flaw. The official timeline, according to the company's advisory on GitHub, shows that the security team immediately blocked the endpoints used during the attack, identified the vulnerability within hours and deployed a patch before most customers noticed any anomaly. The mitigation, as far as is known, was applied first to Metabase Cloud, and corrected binaries for self-hosted deployments are still in the process of being released for customers running the platform in their own data centers.

The vulnerable version is Metabase 1.58 and above. This means that any self-hosted deployment that has kept up with updates over the past year is potentially exposed, unless the operator has restricted access to the API on port 3000, which is where Metabase exposes its services by default in both the official Docker container and the standalone Java distribution.

Johannes Ullrich, principal researcher at the SANS Internet Storm Center, explained in statements to Dark Reading that the vulnerable endpoint must be reachable from the attacker's network for exploitation to work. Ullrich points out that Metabase can be deployed as a Docker container or as a standalone Java application, and that in both cases the API is exposed on port 3000. The critical question that every security team needs to ask itself right now is: who can access port 3000 on our Metabase instances? If the answer is anything other than a very limited set of internal IPs and a load balancer with additional authentication, the risk is elevated.

The blast radius: why this goes beyond Metabase

What turns this incident into something more serious than a typical SaaS platform vulnerability is the role Metabase plays in the enterprise data chain. Metabase is not just a visualization tool: in most deployments, it is the bridge between production data warehouses (Snowflake, BigQuery, Redshift, Postgres, MySQL) and the teams that need to query that data without writing complex SQL. Consequently, a compromised Metabase instance usually has elevated permissions over multiple databases containing sensitive information: customer records, financial data, production telemetry, business metrics, audit histories.

Metabase's advisory describes the exploitation chain with disquieting precision. Once the attacker manages to inject SQL into the application's internal database, the next steps are practically automatable. First, the attacker gains administrative access to the instance, which allows them to change the application configuration. Second, they can steal the credentials stored for connected databases, which Metabase keeps internally in order to execute queries on behalf of users. Third, they can read any data accessible through those connections, that is, everything that Metabase could legitimately query. And fourth, they can export that data en masse before any monitoring detects the anomaly.

The practical result is that an organization that never had any direct commercial relationship with Metabase can end up having its data exfiltrated if any of its providers, customers or partners uses Metabase to analyze shared information. This turns the incident into a full-fledged software supply chain problem.

Why most instances are overexposed

Ullrich added an observation that should concern any team that has deployed Metabase in production: most users, in his experience, have exposed their instances directly to the network without restricting individual API endpoints. The reason, he explains, is practical. Metabase exposes several endpoints that legitimately need to be reachable from the corporate network, such as the password reset endpoint. Configuring a granular proxy that allows only the necessary endpoints and blocks the rest adds operational complexity that many teams prefer to avoid.

That decision, perfectly understandable at the time of deployment, becomes a critical security debt today. If your Metabase instance has been listening on a network interface accessible from the Internet, from a VPC shared with third parties, or even from an office network without proper segmentation, you must assume it has been targeted by exploitation attempts over the past two weeks.

The Metabase advisory does not detail exactly which endpoint was exploited, which is reasonable from a defense perspective but makes building specific detection rules harder. What is clear is that the most effective temporary mitigation, pending the official patch for self-hosted deployments, is to restrict access to port 3000 to known networks only and monitor any connection attempts from external IPs.

Containment measures you must apply today

If you operate self-hosted Metabase on version 1.58 or above, the immediate priority is threefold. First, audit who has access to port 3000 on each instance. If it is exposed beyond your private VPC or a closed list of IPs, restrict access immediately using firewall rules or a reverse proxy with authentication. Second, review the instance logs looking for suspicious activity patterns from at least two weeks before the date of public disclosure of the incident. Look for unusual spikes in SQL errors, connections from unknown IPs, unscheduled configuration changes and massive data exports. Third, rotate all credentials that Metabase had stored for connected databases, assuming that any credential on the instance may be compromised.

If you operate Metabase Cloud, the Metabase team has already deployed the mitigation for you, but you should still rotate the credentials your instance had configured and review who had access to what data during the exposure window. Downstream credential rotation is particularly important: any API key, service token or database password that Metabase had stored should be considered compromised and must be revoked and replaced.

Beyond the immediate response, this incident is an opportunity to review your trust model for enterprise analytics tools. The underlying question is not just whether Metabase is secure, but whether your architecture allows the compromise of a single SaaS platform to translate into administrative access to multiple production databases. If the answer is yes, you have a security design problem that no patch is going to solve for you.

Detection and continuous monitoring

For security teams that need to build specific detections, the most useful signals following this kind of incident are the following. Abnormally high volume of SQL errors in the application logs, especially errors suggesting injection (presence of UNION, unescaped quotes, SQL comments in fields that should not contain them). API connections from IP ranges that do not correspond to legitimate users, in particular from hosting providers or residential VPNs. Changes to instance configuration that do not correspond to planned deployments, especially changes to database connections, user permissions or export settings. And finally, massive or unusual data exports, especially if they occur outside normal business hours or from accounts that do not normally move large volumes of information.

Standard SIEM tools such as Splunk, Elastic or Datadog can be configured to alert on these signals within minutes, provided Metabase logs are being centrally ingested. If you do not yet centralize the logs of your Metabase instances, this is a good time to start.

What comes next

Metabase confirmed that it will publish patches for self-hosted versions in the coming days. Until those patches are available and deployed in production, restricting access to port 3000 is the only effective mitigation. Once the patch is available, the update should be treated as a priority, with the same urgency as any other 10.0 severity vulnerability, regardless of whether Metabase has yet requested a CVE identifier.

This incident also highlights a structural limitation of the enterprise software ecosystem: the absence of a CVE does not mean the absence of risk. CVE assignment is a voluntary and slow process, and during the window between disclosure and assignment, organizations that rely exclusively on CVE-based vulnerability feeds are blind to the threat. Mature security teams maintain monitoring of vendor security advisories in addition to the CVE stream, and this incident is a timely reminder of why that practice is indispensable.