Metabase zero-day exploited in the wild, with no CVE to track it by

Metabase, a widely deployed open-source business intelligence and data visualisation platform, disclosed on 6 August that an attacker used a previously unknown flaw to compromise instances on its hosted service. The vulnerability lets an unauthenticated remote attacker inject arbitrary database commands into the Metabase application database and obtain administrator access to the instance. The company has confirmed active exploitation and is urging self-hosted operators to upgrade immediately.

What happened

According to the advisory, the attack was identified against Metabase Cloud, the company’s managed service, using a flaw affecting versions 1.58 and above. Metabase blocked the endpoints used in the attack, produced a patch, and upgraded its hosted customers automatically. Self-hosted installations, which are a large share of the platform’s deployments, remain exposed until an administrator applies the fix.

The consequences described by the vendor go well beyond the tool itself. With administrator access, an attacker can change the application configuration, take the stored credentials for the databases the tool connects to, read anything reachable through those connections, and export it.

That is the structural point worth holding onto. A business intelligence platform exists to hold the keys to your data sources. Its whole function is to have standing credentials for the systems where your real information lives. A serious flaw in a tool like that is not confined to the tool.

At least two companies, Framework and Tally, have publicly disclosed unauthorised access to customer information linked to this flaw.

The number that is missing

The flaw carries a CVSS base score of 10.0, the maximum, with the vendor recording network attack vector, low complexity, no privileges required, no user interaction, and a changed scope. On the standard scoring system there is nothing worse.

What it does not have is a CVE identifier. At the time of writing the advisory records no known CVE and no weakness classification. It is tracked only by its GitHub advisory identifier.

For anyone running a vulnerability management process, that is the operationally interesting part. A great deal of tooling is built around CVE numbers: scanners match them, feeds distribute them, tickets reference them, and reports count them. A maximum-severity, actively exploited flaw with no CVE will pass silently through a process built that way. Our explainer on reading a CVE covers how those identifiers and scores relate to each other; this is a useful reminder that the identifier is a convenience of the ecosystem rather than a precondition for risk.

The practical correction is unglamorous. Vendor advisories and package ecosystem feeds for the software you actually run need to be a monitored source in their own right, not a fallback consulted after a scanner reports something.

What to do about it

Six release branches are affected, and each has its own patched release.

The vendor’s guidance is to upgrade to the patch matching your major version as soon as possible. Where an immediate upgrade is not possible, it suggests blocking the password reset endpoint as a temporary workaround, which can be done at a reverse proxy or firewall.

The part most likely to be skipped is what comes after. If that endpoint was reachable from the public internet, the vendor asks operators to revoke all active user sessions, review API keys and delete any that are not recognised, check administrator accounts for unexpected changes, rotate the credentials for every connected database, and review both data warehouse logs and Metabase query history for unauthorised activity.

Rotating the connected database credentials is the item that will be deferred, because it touches other systems and other teams. It is also the one that closes the actual exposure, since those credentials are what an attacker would have taken.

Why it matters

For anyone who does not run this software, the useful lesson is about a category rather than a product. Analytics and reporting tools, integration platforms and automation services all work by holding long-lived credentials to the systems they connect. They concentrate access by design, which makes any flaw in them disproportionately valuable. It is worth knowing which tools in your organisation hold standing credentials to your important systems, because that list is usually shorter than people expect and rarely written down.

For organisations running Metabase, the immediate decision is whether anyone owns this. Self-hosted deployments of open-source analytics tools are frequently installed by a data team rather than an IT function, sit outside the normal patching process, and have no named owner. The gap between a vendor publishing an advisory and an operator acting on it is exactly where this kind of incident lands, and it is a process question rather than a technical one.

For practitioners, two things follow. First, treat the absence of a CVE as a monitoring gap rather than a reason to deprioritise; severity and exploitation status are independent of whether an identifier has been assigned. Second, if you are triaging this, the exposure question is not only whether you patched but whether the affected endpoint was ever publicly reachable. If it was, assume the connected database credentials are compromised and rotate them, because the cost of doing that unnecessarily is far lower than the cost of not doing it when it was needed.

Last verified: 10 August 2026 against the vendor’s published advisory. This is a developing situation and the advisory may be updated, including with a CVE identifier assigned after publication.