CVE-2026-72898 let anyone reach full admin with zero credentials, then everything Metabase touched.
A single unauthenticated request to Metabase's password-reset endpoint was enough to inject arbitrary SQL into the application database—and from there, administrator access. No credentials, no user interaction. The CVE record carries a CVSS 10.0—the maximum on the scale—under both v3.1 and v4.0. CISA added it to the Known Exploited Vulnerabilities catalog on August 11, 2026, confirming active exploitation. The federal remediation deadline CISA set—August 14, 2026—has since passed.
A field the API wasn't supposed to accept
CVE-2026-72898 lives in POST /api/session/reset_password. Per Wiz's technical teardown, an attacker-supplied user-id field survives Metabase's request-merge logic on a failed-auth path, and HoneySQL's :raw keyword then treats that value as literal SQL instead of a bound parameter. One field, not stripped where it should have been, turns into unauthenticated SQL injection. The vulnerability lived one layer up, in how the framework decided which fields were safe to keep.
The bug reaches six version lines, 0.58 through 0.63, open source and Enterprise/Cloud alike. Metabase patched it in 0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5 (and the parallel 1.x Enterprise line), disclosing on August 6, 2026 that Metabase Cloud itself had already been hit by the same flaw as a zero-day. Public proof-of-concept code was circulating by noon UTC on August 10, four days after disclosure. The window between "here's the advisory" and "here's a working exploit anyone can run" was days, not weeks.
Metabase's advisory also published a detection signature for the exploitation window: a POST /api/session/reset_password returning HTTP 400, followed by a GET /api/user/current returning HTTP 200. That two-request pattern is what to check server logs for, back to whenever an instance last ran an unpatched version. Metabase's own read on a match: if you find that pattern, it says, your instance has likely been compromised—and it lists the cleanup, starting with deleting every row in the core_session table and rotating your database credentials.
Admin already meant everything it was connected to
Nothing after the SQL injection is exotic—an attacker with admin access does exactly what a legitimate Metabase admin can do. Metabase's own advisory names the reach directly: "change your application configuration, steal stored credentials for your connected databases, read any data accessible through those connections, and export data."
Metabase is a business intelligence (BI) tool. Its entire job is sitting on top of every warehouse, production replica, and analytics data source a company has wired it to. The password-reset bug wasn't the dangerous part by itself—it was the door. What made the breach total was that the room behind the door was the same room every admin already had the keys to.
n8n's own disclosure puts the unauthorized access on August 3, three days before the patch, and names 136 records accessed, five of them carrying bcrypt-hashed passwords. Framework and Tally each disclosed their own breaches: Framework's stolen data included customer names, IP addresses, billing and shipping addresses, and phone numbers; Tally's included email addresses and password hashes. Kilo Code disclosed that a subset of users had Slack access tokens exposed, since invalidated. Four companies, four different kinds of data—names, IPs, physical addresses, phone numbers, email addresses, password hashes, and access tokens to a separate SaaS product entirely—and all of it traces back to the same admin session.
What this argues for
A BI tool's admin role is a credential vault as well as a query surface. That's the specific shape of this incident: every warehouse connection an analyst ever configured in Metabase becomes a connection string sitting inside the same application database the SQL injection just reached—no separate hop through a secrets manager, no second credential to steal. Compare that to a stolen identity chaining through a vault to reach a resource elsewhere: here, reaching the app is reaching the vault.
A login form failing doesn't just cost you the login form—it costs you whatever that account was ever allowed to do. That's the general rule; Metabase is just where it happened this time, and where it happened to mean every warehouse behind it. An access review that only asks "who has admin on the BI tool" misses this—the real question is what that admin role can quietly hand over once someone's inside it, and a warehouse credential doesn't announce itself the way a stolen password does.
Patch now if you haven't—the federal deadline already passed and a public proof of concept has been circulating for weeks. Then grep your server logs for that detection pattern, regardless of whether you've already patched; the disclosure timeline means an unpatched window existed even before most teams knew to look. The room behind the login form is where the actual damage happens, and admin was never supposed to mean every warehouse it was ever pointed at.
That's not a lesson specific to Metabase, and it's not one an identity provider closes either. An SSO front door such as Okta confirms who gets into the BI tool—it says nothing about what a stolen warehouse credential can do once someone uses it directly against the infrastructure it connects to. That's a separate layer: what an operator or agent can then run on the machines those credentials sit on.
