CVE-2026-72898: Unauthenticated SQL Injection Hands Over Metabase Admin

By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)

Read this in 30 seconds: CVE-2026-72898 is a maximum-severity (CVSS 10.0) unauthenticated SQL injection in Metabase, the open-source and enterprise analytics platform, reachable through the public password-reset endpoint. An attacker sends one crafted request with no credentials and no login, and Metabase’s own query builder treats part of that request as raw SQL instead of data, which is enough to forge admin access to the instance and, from there, to every database Metabase is connected to.

Metabase confirmed active exploitation before this went public, CISA added it to the Known Exploited Vulnerabilities catalog on August 11, and at least three companies (Framework, n8n, and Kilo Code) have already disclosed breaches tied to it. If you self-host Metabase on branch 58 through 63, patch today, then go check your logs, because “patched” and “not already compromised” are two different questions.

The password-reset form is supposed to be the most boring, most heavily scrutinized part of any application. It’s also, once again, exactly where the roof caved in.

Developers pour review effort into the login page and the payment flow, and treat the reset form as an afterthought, a place where “it just sends an email” feels safe enough to skip a second look. CVE-2026-72898 is what happens when that assumption meets a real attacker with ten minutes and a JSON body editor. No credentials, no social engineering. Just a request to an endpoint that never needed a login, sent with one extra field it should never have accepted.

What Actually Went Wrong

Metabase’s POST /api/session/reset_password endpoint is public by design, since a user has to reach it before they’re authenticated. The bug is in what happens after the request lands. Per Bishop Fox’s technical writeup, the reset flow failed to restrict the request body to the fields it actually expected. An attacker could add an extra `user-id` field built as a raw SQL expression, and Metabase’s HoneySQL-based query builder compiled that expression directly into the lookup query instead of treating it as a plain value.

That’s the entire vulnerability in one sentence: an input that should have been a validated identifier was instead trusted enough to become part of the query itself. Once an attacker can inject SQL into that lookup, they can manipulate Metabase’s own application database, including the tables that decide who counts as an administrator. OffSec’s advisory confirms the endgame: full admin access, meaning the attacker can read or export any data Metabase can see, pull credentials for every connected database, and change application settings at will.

Who’s Already Been Hit

This one didn’t stay theoretical. Metabase confirmed active exploitation in the wild before the CVE was even public, and CISA added CVE-2026-72898 to its Known Exploited Vulnerabilities catalog on August 11, 2026, giving U.S. federal agencies until August 14 to patch. That is a three-day window for a bug rated maximum severity, which tells you how seriously the government is treating it.

Named victims have already come forward. Framework, the PC maker, disclosed exposure of customer names, login IPs, addresses, phone numbers, and emails. The automation platform n8n confirmed 136 customer records exposed, including five bcrypt-hashed cloud passwords. Kilo Code reported Slack access tokens for its Slackbot users were taken. According to The Hacker News, roughly 13% of cloud environments run a self-hosted Metabase instance, about a quarter of those are directly reachable from the internet, and Wiz researchers estimate around 2,500 instances are exposed to the open internet right now.

If you’re running Metabase and haven’t checked your logs yet, that gap between “vulnerable” and “already exploited” is not hypothetical for you. It’s a live population of thousands of targets, and the attackers clearly already know where to look.

The One Log Line That Tells You If You Were Hit

Metabase’s own CEO, Sameer Al-Sakran, published the indicator of compromise directly: a POST /api/session/reset_password request that returns a 400 status code, immediately followed by a GET /api/user/current request that returns 200. “If you find that pattern in your application logs or in your Metabase server ingress logs, it is likely that your instance has been compromised,” he said.

Check for that pattern before you do anything else, patch included. If it’s there, treat this as a confirmed breach, not a near miss: rotate every credential Metabase had access to, revoke all active sessions, and review your admin user list for anything you didn’t create yourself.

What To Do Right Now

Patch immediately if you self-host Metabase on any of these branches. All Open Source 0.x and Enterprise 1.x releases on branches 58 through 63 are vulnerable prior to these fixed versions:

Branch	Vulnerable range	Fixed in
58	≥ 58.0, < 58.23	58.24
59	≥ 59.0, < 59.20	59.21
60	≥ 60.0, < 60.16	60.17
61	≥ 61.0, < 61.10	61.11
62	≥ 62.0, < 62.8	62.9
63	≥ 63.0, < 63.3	63.5

If you can’t patch this minute, block or rate-limit the reset endpoint at your WAF, and put Metabase behind a VPN so it isn’t sitting on the open internet at all. Either way, after you patch, rotate the credentials for every database connected to Metabase, revoke existing sessions, and manually review the admin account list. A patch fixes the hole. It does nothing about a door that was already walked through.

How XHack Catches Bugs Like This Before They’re a CVE

So yeah, here’s the quick brand note: this bug class, an unauthenticated endpoint trusting a field it never should have, is the same failure mode I keep writing about in broken authorization bugs like BOLA and IDOR, an input nobody scrutinized because the surrounding form “obviously” wasn’t the attack surface.

The XHack AI agent enumerates every endpoint and field on an application, including the boring ones, and tests what happens when an unexpected field shows up in a request body, exactly the category of bug that let this one through. For a full audit of authentication flows and everything connected to your application database, human-led VAPT ($2,500-$12,000, scoped, AI-assisted only if you authorize it) is what connects an injection point to real, provable admin takeover. And XHack doesn’t store your data: pentest chats and session data stay local to you, which matters more on a week when a BI tool’s own database access became the weak link.

FAQ: CVE-2026-72898 Questions Answered

What is CVE-2026-72898?

CVE-2026-72898 is a critical, maximum-severity (CVSS 10.0) unauthenticated SQL injection vulnerability in Metabase, the open-source and enterprise business intelligence platform. It’s reachable through the public password-reset API endpoint and allows an attacker with no credentials to inject SQL into Metabase’s application database and obtain full administrator access to the instance.

Is my Metabase instance affected?

Any self-hosted Metabase deployment on Open Source 0.x or Enterprise 1.x branches 58 through 63, running a version older than the fixed release listed for that branch, is vulnerable. Metabase Cloud-hosted instances were patched centrally by Metabase and are not affected. If you manage your own Metabase server, check your exact version against the fixed-version table above.

How do I know if I’ve already been compromised?

Check your Metabase application logs or ingress logs for a `POST /api/session/reset_password` request returning a 400 status code, immediately followed by a `GET /api/user/current` request returning 200. Metabase’s own CEO published this as the specific indicator of compromise. If you see that pattern, treat it as a confirmed breach and move straight to credential rotation and session revocation, not just patching.

Does patching alone fix this if I’ve already been exploited?

No. Patching closes the vulnerability going forward, but it does nothing to undo access an attacker already gained. If your logs show signs of exploitation, or you can’t rule it out, you need to rotate every credential connected to Metabase, revoke all active sessions, and manually audit your admin account list for anything added without your knowledge, in addition to patching.

The Bottom Line

An unauthenticated endpoint, an unvalidated field, and a query builder that trusted it: that’s the entire chain behind a maximum-severity CVE that’s already produced real, named breaches. Patch to the fixed version for your branch today, check your logs for the compromise pattern before you assume you’re clean, and treat every “it just resets a password” endpoint in your own stack with the same suspicion you’d give a login form. The boring fields are still where the damage happens.