Metabase's password-reset endpoint handed out admin, and Framework had to email every customer
A CVSS 10.0 SQL injection in Metabase was exploited from August 3. Framework told every customer their data was taken. Tally lost emails and password hashes.
Metabase patched a flaw on August 6 that attackers had already been using for three days. The bug scored a straight 10.0 on CVSS, the maximum, and it needed no account, no password and no clicking. One request to the password-reset endpoint was enough to become an administrator.
Two companies have said publicly what that cost them. Framework, the repairable-laptop maker, told its entire customer base their personal details were taken. Tally, a form builder, lost email addresses and password hashes. Both were customers of Metabase Cloud rather than victims of any bug in their own code, which is the part worth sitting with: the analytics dashboard your team barely thinks about holds live credentials to every database you connect to it.
What we know
The vulnerability carries a GHSA identifier, GHSA-vwf4-m7j8-wcjf, and no CVE number at all. It lives in the unauthenticated POST /api/session/reset_password endpoint, where an attacker can inject arbitrary SQL into Metabase’s own application database. From there they promote themselves to admin, and admin in Metabase means the stored connection strings for every warehouse the instance talks to.
- Severity. CVSS v3.1 base score 10.0. Network vector, low complexity, no privileges, no user interaction, and a changed scope, per the advisory.
- Affected. Versions 1.58.0 through 1.58.23, 1.59.0 to 1.59.20, 1.60.0 to 1.60.16, 1.61.0 to 1.61.10, 1.62.0 to 1.62.8 and 1.63.0 to 1.63.3.
- Fixed in. 58.24, 59.21, 60.17, 61.11, 62.9 and 63.5.
- Timeline. Exploitation began August 3, Metabase notified affected customers on August 6, and the advisory went public on August 7.
- Detection. A
POST /api/session/reset_passwordreturning 400, immediately followed by aGET /api/user/currentreturning 200, is the fingerprint to grep your logs for.
Metabase’s own language was unusually direct. “We recently identified that Metabase Cloud was attacked by someone utilizing an unknown (‘0-day’) security vulnerability in versions 1.58 and above,” the company wrote, adding that the flaw “can ultimately give a remote attacker administrator access to a customer’s instance.” Cloud tenants were upgraded automatically. Everyone running their own instance is doing this by hand.
Framework’s disclosure covers the whole database. Stolen fields include full names, email addresses, login IP addresses, billing and shipping addresses, phone numbers and company names, with VAT and EIN numbers added for business accounts, as BleepingComputer detailed. Payment data wasn’t touched. Framework hasn’t said how many people that represents, only that every customer is affected. Tally’s exposure was narrower: emails and one-way password hashes, with forms and submissions untouched.
A dashboard with the keys to everything
Business intelligence tools occupy an awkward spot in a threat model. Nobody classifies them as critical infrastructure, they usually get stood up by a data team rather than a platform team, and they end up holding read credentials for production replicas, warehouses, billing systems and CRM exports all at once. Compromise the BI layer and you skip every other control, because the tool is already authorized to read everything an analyst might want.
That’s why the blast radius here reaches companies that did nothing wrong. This follows the same shape as Atlassian’s Rovo bug leaking Jira tickets and the Hanwha camera login page that leaked a GitHub admin token: one integration point holding credentials for many systems, and a single unauthenticated request in front of it. The interesting difference is that Metabase is open source and self-hostable, so a large share of exposed instances have no vendor who can patch them on your behalf.
What’s still unclear
Metabase hasn’t said how many instances were hit, who is behind the attacks, or how the flaw was found. The August 6 advisory credits no researcher and assigns no CVE, which makes tracking harder for anyone running automated vulnerability feeds keyed on CVE IDs. Nobody has published a count of internet-exposed unpatched instances either, and that number is the one that tells you whether this is finished or just starting. Framework and Tally are also the only named victims so far, four days after disclosure, which is early for a bug this cheap to exploit.
What this means for you
If you self-host Metabase, treat this as an active incident rather than a patch. Upgrade to the fixed release for your branch today, and if you can’t get to it inside the hour, block /api/session/reset_password at your proxy first. Then assume admin was reached: revoke every active session, audit API keys and admin accounts for entries you don’t recognize, and rotate the credentials for every database the instance connects to. Those connection strings are the actual prize here, and they keep working long after you’ve patched the application. Finally, grep your access logs back to August 1 for that 400-then-200 pattern. Doing none of this and calling it done because the version number went up is the failure mode this vulnerability was built to exploit.
Share this article
Quick reference
Sources
- Metabase security advisory GHSA-vwf4-m7j8-wcjf — Metabase
- Metabase SQLi zero-day exploited in customer data-theft attacks — BleepingComputer
- Computer maker Framework notifies 'all customers' of a data breach — TechCrunch
- Metabase Zero-Day Exploited in Wild Allows Admin Access Without Authentication — The Hacker News
- Framework customer information was accessed as part of a data breach — Engadget