Metabase's 0-Day Burned Framework. Self-Hosters Are Next

Framework emailed customers on August 6 to say their contact data had been stolen — not from Framework's own systems, but from Metabase, the business-intelligence platform the laptop maker uses for analytics. The attacker got full names, email addresses, phone numbers, billing and shipping addresses, and login IPs. No order history, no payment data. Framework hasn't said how many customers are affected, and it's still investigating whether business customers' VAT and EIN numbers were in scope.

As breaches go, that's a mild one. The vulnerability behind it is not. On August 3, Metabase Cloud was hit through a genuine 0-day: an unauthenticated SQL injection in the /api/session/reset_password endpoint. Metabase's advisory rates it CVSS 10.0 and confirms active exploitation. No CVE has been assigned yet; it's tracked as GHSA-vwf4-m7j8-wcjf. An attacker who can reach that endpoint can inject arbitrary SQL into Metabase's application database, grant themselves admin, and from there do the thing that makes this class of bug catastrophic: read the stored credentials for every database connected to the instance, then query and export anything those connections can see.

BI tools are credential vaults with a chart library on top

That last step is the whole story. A BI tool is a deliberate aggregation point — you wire in your warehouse, your production replicas, your billing exports, and the tool holds standing credentials for all of them. It's the same reason attackers love CI systems and secrets managers: the value isn't the application, it's the keyring. Pop the dashboard layer and you inherit the data layer.

Metabase has been through this before, which is what makes the self-hosted side of this disclosure worth taking seriously. In July 2023, CVE-2023-38646 — a pre-auth RCE via a leftover setup token and a crafted H2 JDBC string — went from disclosure to mass scanning in days. Then it never went away: OX Security's research this March found more than 17,000 publicly exposed Metabase instances, many still running versions vulnerable to that three-year-old bug. That's the base rate you should assume for this one too. Cloud customers were patched automatically before most of them knew anything happened. The self-hosted tail will be exploitable for years, and this time the exploit requires no account, no token, no setup artifact — just HTTP access to a password-reset endpoint.

What SaaS bought Framework, and what it didn't

The reflexive lesson — "patch your self-hosted BI tools" — is true but lands on the wrong actor here. Framework was on Metabase Cloud. There was nothing for Framework to patch, and its vendor's patch hygiene was irrelevant, because a 0-day beats patch hygiene by definition. The only lever Framework ever had was deciding what data Metabase could see, and its own notice admits it's pulling that lever only now: rotating credentials on all databases and "scoping down access to only the columns required for analysis."

That's the durable fix, and it's worth being blunt about the ordering. Column-level minimization after the breach protects you from the next breach, not this one. Every row you sync into a third-party analytics platform is a row you've decided can leak on someone else's worst day. Framework has now lived this twice — in January 2024 a phished accountant at its outside accounting firm handed over a customer spreadsheet. Different vendor, different attack, same shape: both breaches originated entirely outside Framework's perimeter. For a hardware company that outsources its back office, the real attack surface is the union of its vendors'.

Credit where it's due, though: the response on both sides is close to a model. Metabase blocked the attack endpoints, patched, shipped an advisory with concrete indicators of compromise, brought in law enforcement and a forensics firm. Framework notified customers the same day it learned of the breach — community members clocked the turnaround at about six hours, against US state notification laws that typically allow 30 to 90 days. And it still leaked PII. Response speed is table stakes; it can't substitute for exposure reduction.

If you self-host Metabase, this is a today problem

Versions 58 through 63 are affected in both the OSS and Enterprise lines (anything below 58 is not). Patched releases are 58.24, 59.21, 60.17, 61.11, 62.9, and 63.5 — upgrade to your line's point release now, not at the next sprint boundary. If you genuinely can't upgrade today, Metabase's stopgap is to block the vulnerable endpoint at your proxy:

location = /api/session/reset_password {
    deny all;
}

That breaks password resets until you patch, which is the correct trade.

Then check whether you're already owned. The indicator Metabase published is a POST /api/session/reset_password returning 400, followed shortly by a GET /api/user/current returning 200 from the same client — the injection followed by the attacker confirming their new session. If you find that pattern, treat every connected database as compromised: revoke all sessions (TRUNCATE TABLE core_session; on the app database), audit admin accounts and API keys for anything you don't recognize, rotate credentials on every connected data source, and go through your warehouse query logs for reads that don't match your usual workload.

The longer-term posture changes matter more than the fire drill. Metabase should never hold a superuser or read-write credential to anything — give it a read-only role scoped to marts and views, not your production OLTP schema. Don't expose the instance to the public internet; 17,000 teams have made that mistake and left it running. And copy Framework's after-the-fact move ahead of time: sync only the columns your analysts actually query. Your BI tool can't leak a phone number it never ingested.

The verdict

The breach is minor; the warning is not. An unauthenticated CVSS 10.0 SQL injection in a product with a documented multi-year tail of exposed, unpatched installs is about as close to a guarantee of mass exploitation as this industry offers — expect scanning for /api/session/reset_password to be background-radiation on the internet within the week, if it isn't already. The teams that come out of this fine are the ones that already treated their BI stack as tier-0 infrastructure: patched like an edge service, segmented like a secrets store, and fed the minimum data that answers the question. Everyone else is trusting that their dashboard tool's next 0-day lands on someone else.