Metabase Confirms Maximum-Severity Zero-Day SQL Injection Exploited In The Wild; Self-Hosted Instances Told To Patch

What happened

Metabase, the maintainer of a widely deployed business intelligence and data visualization platform, warned on August 8, 2026 that a maximum-severity flaw had been exploited in the wild as a zero-day, with the company framing the event as a disclosure plus patch action. The reported behavior is an unauthenticated remote SQL injection against the Metabase application database that, on success, hands the attacker administrator access to the instance, an outcome the vendor tied to the vulnerability rather than to any secondary misconfiguration.

58 and above, and that Cloud tenants had already been moved to the latest version, so the live cloud attack vector is closed even though the underlying code path is shared with self-hosted builds. The self-hosted population is the open audience for this disclosure; the same vendor statement directs self-hosted operators to apply the security patches released by the project. That dual-track response, Cloud already remediated and self-hosted awaiting operator action, is the core shape of the event and the reason this advisory is being treated as urgent rather than routine.

Metabase's own framing in its advisory is the only place these facts are anchored, so the briefing relies on the maintainer's wording for the attack vector, the version floor, and the patch call to action, treating the report as the maintainer advisory it is rather than as an independent third-party confirmation.

The vulnerability and why it is maximum severity

0, the ceiling of the scale, and at the time of disclosure does not have a CVE identifier, a gap that complicates asset inventory and patch verification workflows because many scanners and governance dashboards key off CVE strings rather than vendor advisory IDs. The technical primitive is arbitrary SQL injection into the Metabase application database, executed by an unauthenticated remote attacker, meaning the attacker does not need valid credentials, an API token, or network position beyond reaching the application's HTTP surface.

From that primitive, the advisory enumerates a chain that escalates to administrator access on the instance and then pivots into the connected databases that the Metabase instance is configured to query. With administrator access, an attacker can change application configuration, read any data exposed through the configured connections, and export that data out of the environment, which together convert a single SQL injection sink into a data-exfiltration engine for every downstream warehouse the Metabase server is wired to.

For readers who handle data encoding, hashing, and cryptography in production, the operational concern is not the SQL grammar itself but the fact that the same administrator surface typically manages stored credentials for connected databases, so a takeover exposes both live query paths and the secrets used to authenticate to those databases, a pattern that historically turns a single BI-server compromise into a multi-system breach.

Confirmed facts about the actor, timing, and scope

The actor in this event is Metabase, acting in its capacity as the maintainer of the affected software, and the disclosure channel is a vendor advisory that the company itself issued, which means the words used here about attack vector, version range, and remediation status are Metabase's own characterization and not an independent third-party forensic finding. 58 and above, covering every supported self-hosted line that Metabase currently ships; the briefing does not narrow that further because the advisory does not.

Metabase Cloud has already been updated to the latest version, which the vendor presents as the remediation status for the hosted population; self-hosted operators are explicitly told to apply the security patches released by the project, a separate action that depends on each operator's deployment pipeline. 58 or newer self-hosted build should be treated as in scope until the operator has confirmation of an unaffected build from the project. The advisory does not name the attacker, does not provide an exploitation timeline, and does not state how Metabase Cloud was first detected as attacked, and the briefing does not invent those details.

Reader impact and what operators must do

58 and above is that an attacker reaching the application's HTTP surface can preconfigure administrator-level access and then exfiltrate the data of every connected database the Metabase server is configured to query, including changing application configuration and stealing stored credentials for those connections, which is why the advisory is framed as a patch-now event rather than a monitor-and-wait event. Two operational consequences follow from how the flaw is described. First, because the primitive is unauthenticated SQL injection and the result is full administrator access on the Metabase instance, network-level exposure of the Metabase admin and API ports is a meaningful risk multiplier; operators who have not placed Metabase behind SSO-aware reverse proxies or VPN-only ingress should treat that exposure as the highest-priority compensating control while patches are rolled out.

Second, because the compromised administrator surface can change application configuration and read connected databases, post-patch work is not limited to installing the binary: operators should plan to rotate stored credentials for every connected data source, audit Metabase application configuration for unauthorized changes made during any window of exposure, and review egress logs for bulk export activity, since the advisory lists export of data as an in-scope attacker capability. Cloud tenants are in a different posture because Metabase states that Cloud instances have already been updated, so the urgent action shifts from patching to verifying that any in-cloud data accessed during the pre-remediation window is intact and that connected credential stores were not exposed.

Uncertainty and what to watch next

The largest uncertainty is the absence of a CVE identifier at the time of disclosure, which makes asset-inventory matching harder and slows down scanner-driven ticketing; the briefing expects an identifier to be assigned as the advisory progresses, and operators should plan to remap their tracking once it lands. 58 and above deployment is in scope until the operator has applied a vendor-confirmed patched build and can prove it on the running host. A third uncertainty is forensic: the advisory does not name the attacker, does not describe the initial access vector beyond "attacked Metabase Cloud," and does not state whether any Cloud tenant data was read or exported before the update was deployed, so any attribution or blast-radius claim beyond what Metabase has said would be inference rather than evidence.

To watch next: the assignment of a CVE identifier and the publication of a named patched build string, both of which will convert this advisory from a directional warning into a verifiable patch event that operators can close out with a single ticket. In the interim, the maintainer's own framing, maximum severity, unauthenticated SQL injection, administrator access, Cloud already updated, and self-hosted told to patch, is the complete and only confirmed picture this briefing is willing to stand behind.