On August 3, 2026, an attacker didn't need a Metabase password, a stolen API key, or a phished login to become an administrator on a live Metabase Cloud instance. They needed one request to an endpoint called /api/session/reset_password — no authentication required — and from there, arbitrary SQL against the application database. Three days later, Metabase told its customer Framework, the repairable-laptop maker, that its instance had been hit. Framework's notice, which the company says went out to its entire customer base on August 7, listed names, emails, phone numbers, and home and billing addresses, all exposed.
How a password-reset box became a root shell
Metabase is the open-source dashboard tool a lot of startups point straight at their production database so a non-engineer can build a chart without touching SQL. That's exactly why this bug is bad: the application database it runs on isn't a throwaway config store, it's the thing holding every connection string, every cached credential, every saved question against a company's real data.
The flaw sat in the password-reset flow. /api/session/reset_password didn't require a session token to hit, and a specially crafted request let an attacker inject arbitrary SQL through that call. From there they could read and write to the application database directly — including creating themselves an admin session, at which point /api/user/current returns 200 and they're in, no credentials ever entered. Metabase's advisory lists the telltale sign in server logs: a POST to the reset endpoint returning 400, immediately followed by a 200 on /api/user/current.
Affected branches, patch now
1.58.x
Branch
1.58.0 – 1.58.23
Vulnerable versions
1.58.24
1.59.x
Branch
1.59.0 – 1.59.20
Vulnerable versions
1.59.21
1.60.x
Branch
1.60.0 – 1.60.16
Vulnerable versions
1.60.17
1.61.x
Branch
1.61.0 – 1.61.10
Vulnerable versions
1.61.11
1.62.x
Branch
1.62.0 – 1.62.8
Vulnerable versions
1.62.9
1.63.x
Branch
1.63.0 – 1.63.3
Vulnerable versions
1.63.5
Branch
Vulnerable versions
Fixed in
1.58.x
1.58.0 – 1.58.23
1.58.24
1.59.x
1.59.0 – 1.59.20
1.59.21
1.60.x
1.60.0 – 1.60.16
1.60.17
1.61.x
1.61.0 – 1.61.10
1.61.11
1.62.x
1.62.0 – 1.62.8
1.62.9
1.63.x
1.63.0 – 1.63.3
1.63.5
The Framework connection
Framework — the Bay Area company that's spent five years trying to convince the laptop industry a computer should be repairable — was using Metabase Cloud, which means it didn't even run the vulnerable code itself, it just trusted the vendor that did. Framework's own breach notice, which the company says went to its entire customer base, lists names, email addresses, login IP addresses, phone numbers, and billing and shipping addresses. Business-tier accounts also had VAT numbers, EINs, and billing emails exposed. Framework says payment information was not affected — Metabase Cloud apparently wasn't the system of record for card data, which is the one piece of good news here.
What to do if you self-host Metabase
Upgrade to the fixed version for your branch immediately — 1.58.24 through 1.63.5, see the table above.
If /api/session/reset_password was publicly reachable before you patched, treat every session as burned: go into the application database and delete every row in core_session.
3
Check server logs for the IOC pattern — a 400 on the reset endpoint immediately followed by a 200 on /api/user/current.
Rotate every credential Metabase had saved for connected databases, not just the Metabase admin password.
Metabase Cloud runs the same application database code as self-hosted instances — which is exactly why this bug reached so far. · Unsplash
Why this keeps happening
This is the fourth unauthenticated-RCE-or-equivalent story we've covered in three weeks — Gitea's file-read bug, JetBrains TeamCity's unauthenticated RCE, and Cisco FMC's static credential all share the same root shape: internal tooling that was never meant to face the open internet, reachable anyway, with an auth check someone forgot on one specific endpoint. Password-reset flows are a recurring offender because they have to work before a session exists — that's the entire point of them — which makes 'no authentication required' look like a feature right up until it's the bug.
Is there a CVE for this Metabase vulnerability?
No — as of publication, Metabase's advisory (GHSA-vwf4-m7j8-wcjf) hasn't been assigned a CVE identifier, though its CVSS score of 10.0 puts it at maximum severity regardless.
Do I need to patch if I only use Metabase Cloud?
No action needed — Metabase says Cloud customers were automatically upgraded once the fix shipped. Manual action is only required for self-hosted instances.
Was payment data exposed in the Framework breach?
Framework says no — the exposed data was names, contact and shipping details, and for business accounts VAT/EIN numbers, not payment card information.
How do I know if my instance was compromised, not just vulnerable?
Check server logs for a POST to /api/session/reset_password returning 400, immediately followed by a GET to /api/user/current returning 200 — that's the pattern Metabase's advisory flags as the attack signature.
Metabase blocked the vulnerable endpoint and shipped patches within days of discovery, which is the incident-response system working about as well as it can once a zero-day is already live. The uncomfortable part sits upstream of Metabase entirely: any tool you've pointed at your real data is now something you have to patch-manage like it faces the internet — because for one week in August, this one did. If you don't know which branch your self-hosted instance is on, that's this afternoon's task, not next sprint's.
