Metabase CVSS 10.0 Zero-Day Exploited in the Wild — SQL Injection Grants Admin Access
Metabase says a maximum-severity flaw in its business-intelligence software was exploited as a zero-day. The CVSS 10.0 bug lets an unauthenticated attacker inject SQL into Metabase's application database and seize admin access. Self-hosted operators should patch and rotate credentials.
San Francisco — Metabase, maker of one of the most widely deployed open-source business-intelligence and data-visualization platforms, has confirmed that a maximum-severity flaw in its software was exploited in the wild as a zero-day before any patch existed. The company scores the vulnerability CVSS 10.0, the top of the scale, yet it carries no CVE identifier — an unusual gap for a flaw already under active attack.
The flaw is an unauthenticated SQL injection: a remote attacker who has never logged in can inject arbitrary SQL into the Metabase application database and, from there, gain administrator access to the instance. The Hacker News reported on August 8 that Metabase issued the disclosure after detecting exploitation, and the flaw still has no CVE assigned as of publication.
What Metabase Disclosed
Metabase titled its advisory bluntly: "Security update available for Metabase — Please upgrade now." The company says it identified an attack against Metabase Cloud on Monday, August 3, carried out with an unknown zero-day affecting versions 1.58 and above. It published fixed releases and a GitHub security advisory (GHSA-vwf4-m7j8-wcjf) — notably a GHSA identifier, not a CVE — while urging self-hosted operators to update immediately.
Per the advisory, the vulnerability sits in the unauthenticated /api/session/reset_password endpoint. Because that endpoint is reachable without a valid account, an attacker needs no credentials to reach the injection point. Metabase's stated stopgap for operators who cannot patch at once is to block external access to that endpoint at the network edge until the upgrade is applied.
The Detail That Matters: Which Database
Precision matters here. The SQL injection targets Metabase's application database — the internal metadata store that holds the instance's own configuration, user accounts, saved questions, and, critically, the stored credentials Metabase uses to connect to the data sources it queries. It is not, in the first instance, an injection into the customer data warehouses that Metabase visualizes.
That distinction is not reassuring. Admin access to the application database is a stepping stone, not the destination: with it, an attacker can read the stored connection credentials for every database wired into the instance, change configuration, and export data. BleepingComputer reported that at least two organizations, Framework and Tally, have disclosed data-theft incidents tied to the flaw — early evidence that the path from application-database access to real data loss is more than theoretical.
Business-intelligence platforms are a rich target precisely because they aggregate. A single Metabase instance often federates credentials to production databases, warehouses, and analytics stores across an organization, so one compromised console can translate into read access to many downstream systems at once.
Who Is Exposed, and What to Do
The flaw carries a maximum CVSS score of 10.0 and affects every release from version 1.58 onward, spanning the 0.58 through 0.63 branches (Metabase's enterprise 1.x and open-source 0.x lines share the same minor numbering). Metabase has published minimum safe releases for each branch: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5, with matching 1.x enterprise builds. Self-hosted deployments are the priority — Metabase Cloud instances are managed centrally, but organizations running their own servers must act themselves.
The verification sequence is worth doing in order. Inventory every deployment, check whether any are reachable from the internet, upgrade to the fixed release for your branch, then rotate the credentials an admin-level intruder could have read and revoke active sessions. If your /api/session/reset_password endpoint was publicly reachable before you patched, treat prior compromise as possible rather than hypothetical, and hunt accordingly.
The shape of this incident will feel familiar to anyone who tracked the recent unauthenticated admin-takeover flaw in the Kirki WordPress framework or the actively exploited authentication-bypass in N-able's N-central platform: no login required, full administrative control at the end, and a patch race against attackers who moved first.
What's Confirmed — and What Isn't
Several things remain open. Metabase has not published a count of how many instances were exploited, and no threat actor has been named. Whether CISA will add the flaw to its Known Exploited Vulnerabilities catalog is unresolved — and it cannot happen in the usual way until a CVE is actually assigned, because the KEV catalog is keyed to CVE identifiers. For now, the vendor's own confirmation of in-the-wild exploitation is the authoritative signal; a CVE, if one is issued later, would formalize what Metabase has already stated.
My read: the missing CVE is a bookkeeping gap, not a reason to wait. A vendor rating its own flaw 10.0 and confirming exploitation before a patch existed is about as strong a signal as this industry produces. The precise-sounding reassurance that this hits the "application database" rather than your warehouse should not slow anyone down — that application database holds the keys to the warehouse. If you run self-hosted Metabase, the only questions that matter today are whether you are on a fixed build and whether you have rotated the connection credentials an admin-level intruder could have read.
