A single API endpoint let anyone become an administrator on thousands of self-hosted Metabase servers, and Framework, n8n and Kilo Code already got hit before the patch even shipped.
Metabase disclosed CVE-2026-72898 on August 6, 2026: an unauthenticated SQL injection in the password-reset endpoint, /api/session/reset_password, that lets an attacker with no credentials and no user interaction inject arbitrary SQL against Metabase's own application database and walk away with a valid administrator session. It scores a flat 10.0 on CVSS. The disclosure date is almost beside the point — exploitation predates it. Between August 7 and August 10, three real companies confirmed attackers had already used this exact hole against their Metabase Cloud tenants before a patch existed: PC maker Framework had customer names, login IPs, addresses, phone numbers and emails accessed; workflow-automation company n8n had 136 customer records compromised, including five bcrypt-hashed cloud account passwords; and Kilo Code had Slack integration tokens exposed for a subset of its users, according to The Hacker News.
How a password-reset form becomes a full admin takeover
The root cause, per technical writeups from Horizon3.ai, is a failure to restrict undeclared fields in the password-reset request body — a gap that's existed since Metabase refactored its authentication modules starting with version 0.58. An attacker can smuggle extra, unvalidated fields into the reset-password call, and those fields get interpolated straight into a SQL query against the application database instead of being sanitized or rejected. From there, the attacker forges a valid password-reset flow for an administrator account and logs in with full privileges — no phishing, no stolen credentials, no multi-step chain. Just one request to one endpoint.
Affected and patched versions by branch
0.58 / 1.58
Branch
0.58.0 – 0.58.22
Vulnerable range
0.58.24
0.59 / 1.59
Branch
0.59.0 – 0.59.19
Vulnerable range
0.59.21
0.60 / 1.60
Branch
0.60.0 – 0.60.15
Vulnerable range
0.60.17
0.61 / 1.61
Branch
0.61.0 – 0.61.9
Vulnerable range
0.61.11
0.62 / 1.62
Branch
0.62.0 – 0.62.7
Vulnerable range
0.62.9
0.63 / 1.63
Branch
0.63.0 – 0.63.2
Vulnerable range
0.63.5
Branch
Vulnerable range
Patched version
0.58 / 1.58
0.58.0 – 0.58.22
0.58.24
0.59 / 1.59
0.59.0 – 0.59.19
0.59.21
0.60 / 1.60
0.60.0 – 0.60.15
0.60.17
0.61 / 1.61
0.61.0 – 0.61.9
0.61.11
0.62 / 1.62
0.62.0 – 0.62.7
0.62.9
0.63 / 1.63
0.63.0 – 0.63.2
0.63.5
Who's already been hit
Framework (confirmed Aug 7) — customer names, login IPs, physical addresses, phone numbers and email addresses accessed.
n8n (confirmed Aug 8) — 136 customer records compromised, including 5 bcrypt-hashed cloud account passwords.
Kilo Code (confirmed Aug 9) — Slack integration tokens exposed for a subset of users.
All three are Metabase Cloud tenants, meaning Metabase's own hosted infrastructure — not a customer misconfiguration — was in the exploitation path during the pre-patch window. Metabase has since patched its cloud environment; the exposure now is entirely on the self-hosted side. Internet-wide scans cited by Wiz found roughly 11,000 probable self-hosted Metabase instances, of which about 4,309 were still on a vulnerable version. At the time of scanning, over 97 percent of fingerprinted hosts on affected branches hadn't patched yet.
Check your Metabase version in the admin panel or via the /api/health endpoint.
Upgrade to the patched release for your branch — see the table above.
3
Rotate all user sessions and any API keys stored in Metabase after patching, since a pre-patch admin session could still be valid.
4
Audit the database credentials Metabase uses to connect to your actual data sources — an attacker with Metabase admin access can read and export through those connections.
5
Review your database logs for anomalous queries or errors around the reset_password window before you patched.
This is the same failure class as three other 2026 bugs
Metabase's password-reset endpoint isn't the first authentication workflow to turn into a pre-auth admin takeover this year. GeoServer's SQL injection zero-day hit CVSS 9.8 through a comparable injection path, SAP Commerce Cloud's CVE-2026-58231 went from disclosure to exploitation in 72 hours, and SharePoint's JWT-forgery proof-of-concept was weaponized within two days of a researcher posting it. The common thread across all four: attackers have stopped probing login pages and started targeting the auxiliary auth flows around them — password resets, token refreshes, session forging — because those endpoints get far less scrutiny than the front door, and a single missed validation there is worth more than any brute-force attempt against a login form.
10.0
CVSS score
Aug 6, 2026
Disclosed
Aug 10, 2026
PoC public
3 named
Confirmed victims
Common questions
Am I safe if I use Metabase Cloud instead of self-hosting?
Metabase's own cloud infrastructure has been patched since the disclosure, so cloud tenants are no longer exposed to this specific attack path. The confirmed victims — Framework, n8n and Kilo Code — were hit during the pre-patch window before the fix rolled out.
What exactly can an attacker do with the admin access this bug grants?
Full administrative control of the Metabase instance: reading and exporting any data accessible through its connected databases, changing application configuration, and harvesting stored database credentials for those connections.
Do I need to do anything besides upgrade?
Yes. Because exploitation can grant a valid admin session before you patch, rotating sessions and API keys afterward matters — simply upgrading doesn't invalidate a session an attacker already obtained.
How do I know if I've already been hit?
Check your database and application logs around the reset_password endpoint for unusual query patterns or errors in the window before you patched, and look for admin-account activity you don't recognize.
If you're on Metabase Cloud, you're covered — the vendor already closed this on its own infrastructure. If you self-host, the fixed version for your branch is the only real mitigation; there's no config flag that neutralizes an unvalidated field in a SQL query. And regardless of what tool you run, this is worth generalizing: any internal service with a password-reset, token-refresh, or account-recovery endpoint deserves the same scrutiny you'd give a login form, because attackers have clearly started giving it that scrutiny first.
