CVE-2026-72898: Metabase's Password-Reset Endpoint Lets Anyone Become Admin

If your company runs Metabase to let non-engineers poke at production data, stop and check the version number before you finish this paragraph. CVE-2026-72898 is an unauthenticated SQL injection in the password-reset flow, rated CVSS 10.0, the highest score the scale allows, and CISA confirmed active exploitation when it landed on the Known Exploited Vulnerabilities catalog on August 11.

What the bug actually is

Metabase’s password-reset flow accepts a POST request to /api/session/reset_password with a reset token and a new password. The endpoint is unauthenticated by design, because that’s the whole point of a password reset: you can’t require a login to reset a login you’re locked out of. The flaw is in how that request gets handled once it reaches the server.

Bishop Fox’s writeup traces the root cause to improper neutralization of special characters (CWE-89) in the reset-token handling: a value from the unauthenticated request flows into a SQL query against Metabase’s own application database without being properly sanitized first. An attacker doesn’t need a valid token, a valid email, or any prior account. A single crafted request lets them inject arbitrary SQL, and from there, alter records directly, including the tables that determine who’s an administrator.

The endpoint that exists to help a locked-out user regain access becomes the endpoint that hands a stranger the keys to everything.

Why this one travels further than a typical dashboard bug

Metabase isn’t a standalone app sitting off to the side. It’s usually wired into a company’s actual data: production Postgres, a data warehouse, sometimes multiple client databases if you’re running it for internal analytics across projects. Those connection strings, often including live credentials, live inside the Metabase application database itself.

An attacker with admin access through this bug can do more than deface a chart. They can read every stored connection string, export any dataset a connected source exposes, and quietly add themselves as a permanent admin so that patching the SQL injection later doesn’t remove their access. That’s the same shape of risk we’ve flagged in other business tools that sit closer to your data than their UI suggests: the tool itself might feel low-stakes, a reporting dashboard, a build server, but its blast radius is set by what it’s connected to, not by what it looks like it does.

Unauthenticated is also doing real work in the severity score here. There’s no phishing step, no credential to steal first, no social engineering. Anyone who can reach the Metabase instance over the network can run this today.

Who’s affected

Metabase line	Affected	Fixed
0.58 / 1.58	0.58.0–0.58.23	0.58.24 / 1.58.24
0.59 / 1.59	0.59.0–0.59.20	0.59.21 / 1.59.21
0.60 / 1.60	0.60.0–0.60.16	0.60.17 / 1.60.17
0.61 / 1.61	0.61.0–0.61.10	0.61.11 / 1.61.11
0.62 / 1.62	0.62.0–0.62.8	0.62.9 / 1.62.9
0.63 / 1.63	0.63.0–0.63.4	0.63.5 / 1.63.5

Every affected line has a fix on the same major version, so patching doesn’t force a broader upgrade. If you’re below 0.58, this specific flaw isn’t present, though that’s not a reason to skip patching for anything else.

How to patch it

Upgrade to the fixed release matching your current line: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5 (Enterprise mirrors the same numbers under the 1.x series). If you’re managing Metabase through Docker, that’s a matter of pulling the updated image tag and redeploying; if it’s a manual install, follow Metabase’s standard upgrade path for your line.

While you’re in there, two things worth doing beyond the version bump:

1. Audit existing admin accounts. If you can’t account for when and how every current admin was created, treat the ones you can’t explain as suspicious until proven otherwise.
2. Rotate connected data source credentials if the instance was internet-reachable at any point during the vulnerable window. The password-reset exploit doesn’t require the attacker to touch your production database directly, but if they gained admin, they could read every credential Metabase had stored for it.

If your Metabase instance sits behind a VPN or internal network only, your exposure window is smaller but not zero. Internal threats and lateral movement from an already-compromised host both still apply.

The broader lesson

Password-reset and account-recovery flows keep showing up as the soft underbelly of otherwise well-secured applications, precisely because they have to work for people who aren’t authenticated yet. That design requirement means less can be gated behind a login check, which means more of the request has to be trusted or carefully validated by hand. When that validation misses a case, as it did here, the flaw skips straight past every access control the rest of the app relies on.

If you run any internal tool with unauthenticated recovery flows, whether it’s Metabase, a homegrown admin panel, or a vendor product, put those specific endpoints on your next security review rather than assuming “it’s just for password resets” makes them low-risk. Our team has audited exactly this class of overlooked endpoint for clients running self-hosted BI and internal tooling, and it’s consistently one of the cheaper problems to catch before a CVE forces the conversation.