Metabase Zero-Day Let Attackers Grab Admin, No Login

A perfect 10.0 severity bug in Metabase let anyone on the internet become an administrator of a Metabase instance without logging in, and attackers were using it before the company had a patch ready. The flaw, CVE-2026-72898, sits in the password reset endpoint of the open-source analytics tool and turns a routine JSON field into a path to full database access.

Metabase runs inside a lot of companies you've never heard of as the dashboard layer sitting on top of production databases. That's exactly why this one stings: the bug doesn't just expose Metabase itself, it exposes every database Metabase is plugged into.

RelatedGeoServer Zero-Day Exploited Hours After Disclosure

What actually happened?

Metabase disclosed on August 6, 2026 that its own Cloud environment had been hit by attackers using a vulnerability nobody had a name for yet. Researchers and Metabase's security team traced the intrusion back to the /api/session/reset_password endpoint, an unauthenticated route that exists so users can request a password reset without first logging in. That's normal design. What wasn't normal was what happened when you added an extra field to the request.

CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on August 11, 2026, which is the federal government's way of saying this isn't theoretical. The KEV listing gave federal civilian agencies until August 14 to patch under Binding Operational Directive 26-04, a three-day window that tells you how CISA rated the risk.

How does the Metabase exploit actually work?

The mechanics are almost embarrassingly simple once you see them. The reset-password endpoint expects a request body with the basics: an email address, maybe a token. Metabase's code builds a database query around whatever fields show up in that body using HoneySQL, a Clojure library for constructing SQL as data structures rather than raw strings.

HoneySQL is supposed to be safer than string concatenation because you're building a structured representation of a query instead of gluing text together. The problem is what happens when the application never checks the type of a value before handing it to HoneySQL. An attacker can add a user-id key to the JSON body and set its value to a HoneySQL object instead of a plain string or number. Metabase's backend doesn't validate that the value is the type it expects, so it passes straight through and gets compiled into raw SQL as part of the query. At that point you're not sending data anymore, you're sending code.

• The attack requires no login, no API key, no session token of any kind.
• It targets a single JSON field on a publicly reachable endpoint every Metabase instance exposes by design.
• Success grants full administrator rights inside Metabase, not read-only access.
• Every release from version 1.58 onward is affected, spanning the 0.58 through 0.63 branches.

Once an attacker has admin, the real damage starts. Metabase stores the credentials for every database connection an organization has configured, warehouse logins, production replicas, analytics databases, whatever teams hooked up so they could build dashboards. Admin access means reading those credentials outright, then reaching into any data those connections touch.

Who's been hit so far?

Metabase's own hosted Cloud service was the first confirmed victim, attacked with what was at the time an unknown zero-day before the company had identified the root cause. Two of Metabase's customers, Framework and Tally, separately came forward afterward to say attackers had used this flaw to get into their environments and pull customer data, including names, addresses, phone numbers, and emails, out of systems connected through Metabase. Those disclosures are what turned this from "critical CVE" into "actual data breach, more than once."

Because the bug covers every release from 1.58 through the entire 0.63 branch, the exposed population isn't a narrow slice of recent installs. It's most of what's currently running in production, including self-hosted deployments that companies stood up years ago and haven't touched since.

RelatedA Cisco Zero-Day Was Exploited for Two Months Before Anyone Knew

How did this play out?

1. Aug 6Metabase discloses its Cloud environment was attacked using what was then an unidentified zero-day
2. Aug 6-11Root cause traced to reset_password endpoint HoneySQL type-validation gap identified, patch developed
3. Aug 11CISA adds CVE-2026-72898 to the KEV catalog federal agencies given a hard deadline under BOD 26-04
4. Aug 14Federal civilian patch deadline mandatory for agencies covered by the directive
5. OngoingFramework and Tally disclose customer data exposure self-hosted orgs still patching in the wild

What should self-hosted users do right now?

If you're running Metabase yourself instead of on their Cloud tier, the fix isn't automatic and waiting is the wrong move. Metabase has shipped a patched release, and the company is telling every self-hosted operator the same thing: update now, then assume your database credentials may have already been seen.

What's next?

Expect more victim disclosures before this cycle closes. Framework and Tally came forward because they caught the intrusion and chose to say so, and a bug this easy to exploit against a tool this widely self-hosted rarely stops at two known victims. Security researchers, including the team at Resecurity who published a technical breakdown of the exploit chain, are still watching for scanning activity against unpatched instances, which tends to run for weeks after a KEV listing as slower-moving organizations catch up.

Our take

What makes this one worth remembering isn't the CVSS 10.0, plenty of bugs get that score and fade. It's that the vulnerable code path was a password reset endpoint, which by definition has to be reachable without authentication. That's not a mistake, that's the whole point of the feature. The mistake was trusting a value's type without checking it before letting a query builder touch it, and HoneySQL's flexibility, meant to make queries safer to construct, became the thing that made the injection possible once that check was skipped.

BI tools keep ending up in this spot because they sit at a uniquely dangerous intersection: public-facing enough to need auth-free endpoints for things like password resets, and privileged enough internally to hold credentials for every database a company cares about. An admin-reset flaw in a tool nobody thinks of as an attack surface is a pattern worth watching for elsewhere, not just filing away as one Metabase incident.

Original analysis by GenZTech, based on CISA's advisory and independent security research.