Framework's Metabase Breach Wasn't a Patching Failure
A CVSS 10.0 zero-day hit Metabase Cloud, and every column piped into analytics became breach-notification surface.
On August 6, Framework emailed customers to say an attacker had accessed their names, email addresses, and mailing addresses. The vector wasn't Framework's store, a phished employee, or a stolen laptop (irony noted). It was Metabase, the business-intelligence tool Framework pipes customer data into — compromised through a genuine zero-day that Metabase confirms was actively exploited against its cloud service.
The vulnerability is about as bad as they come: an unauthenticated SQL injection in the public /api/session/reset_password endpoint, letting an attacker inject arbitrary SQL into the Metabase application database. It scores a perfect CVSS 10.0 and has no CVE yet — it's tracked as GHSA-vwf4-m7j8-wcjf. Every release branch from 58 through 63 is affected. Metabase shipped fixes across all six branches the same day it went public, and says it notified affected customers within days of discovering the exploitation. Framework, by its own account, went from receiving that notice to emailing customers in about six hours.
The lesson isn't "patch faster"
The reflexive takeaway — keep your self-hosted analytics patched — doesn't survive contact with the details. Framework wasn't running a neglected instance on a forgotten VM. By all indications in the disclosure discussion, its instance ran on Metabase Cloud: vendor-managed, automatically upgraded, exactly what the checklist says to do. Payments were properly isolated with Stripe, which is why card data wasn't touched. Framework followed the conventional playbook and still ended up writing a breach notification.
That's what a real zero-day means: there was no patch to apply. Once the exploit exists and the vendor doesn't know, your patching cadence is irrelevant. The only variable still under your control is what's sitting on the other side of the vulnerable endpoint. Framework's exposure was decided months earlier, when someone connected the customer table to the analytics stack — one commenter noted they got a breach notice having only ever joined a waitlist.
BI tools are structurally the soft target
This is Metabase's third serious security event in three years, and the pattern matters more than the count. CVE-2023-38646, the 2023 pre-auth remote code execution bug via a leaked setup token, was mass-exploited within days of disclosure and is still being found on thousands of internet-exposed instances — security firm OX Security published a survey to that effect just months ago. In February 2026, a separate flaw (GHSA-vcj8-rcm8-gfj9) let any authenticated user exfiltrate warehouse credentials through email notification templates. Now a pre-auth SQL injection in the password-reset path.
I don't think Metabase is unusually sloppy — its incident response this week was genuinely fast, with same-day patches and published indicators of compromise. The problem is what a BI tool is: a web application, usually internet-reachable, holding standing credentials to your data warehouse, whose entire job is executing queries over everything you've ever collected. It's the highest-value, lowest-scrutiny box in most data stacks. Apache Superset had the same lesson in 2023, when CVE-2023-27524 turned a default SECRET_KEY into admin access on thousands of deployments. Different products, same shape: maximum data gravity, ordinary web-app attack surface.
If you self-host Metabase, stop reading and patch
The zero-day advantage flipped on August 6. Metabase Cloud is patched; self-hosted operators are now racing a public advisory for an actively exploited pre-auth bug, and the 2023 episode tells us exactly how that goes for the long tail. Minimum safe versions are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5 (plus enterprise equivalents). If you can't upgrade this hour, block the endpoint at your proxy:
location = /api/session/reset_password { return 403; }
Then check your access logs for the compromise signature Metabase published:
POST /api/session/reset_password → 400
GET /api/user/current → 200 (same client, moments later)
If you find that pair, assume compromise: truncate the session tables, rotate every database credential Metabase holds, audit admin accounts and API keys, and go through your warehouse query logs — the prize here was never Metabase itself, it's the databases behind it.
Starve the dashboard
The most instructive sentence in Framework's notice isn't the apology. It's the remediation: the company says it's now "scoping down" BI platform access "to only the columns required for analysis." That's the fix that would have actually changed the outcome, and it's available to everyone today, no zero-day knowledge required.
Almost no dashboard needs raw PII. Signups by region needs a region code, not a mailing address. Cohort retention needs a stable user ID, not an email. The practical version: give your BI tool a dedicated read-only warehouse role, point it at curated views or marts instead of raw tables, and hash or drop direct identifiers before data crosses the analytics boundary. Then apply the test this incident makes concrete — every column granted to the BI layer is a column you may someday enumerate in a breach notification. Most teams do the opposite: connect the whole warehouse on day one because scoping is friction, then never revisit it.
The scorecard
Framework comes out of this bruised but credible — six hours from vendor notice to customer email, disclosure even where it says regulation arguably didn't demand it, and a remediation that names the real architectural mistake rather than promising vague vigilance. Metabase's handling was fast and transparent, but three credential-adjacent holes in three years should factor into anyone's vendor review, cloud or not.
The loser is the default posture this breach exposes: pipe everything into an internet-facing query engine, trust the vendor's patch pipeline, call it managed. Managed patching saves you from known bugs. Only data minimization saves you from unknown ones — and unknown ones are the kind that just hit a company doing most things right.
Sources & further reading
- Framework data breach discussion — community.frame.work
- Security update available for Metabase - Please upgrade now — metabase.com
- Metabase security advisory GHSA-vwf4-m7j8-wcjf — github.com
- February 2026 vulnerability: What happened? — metabase.com
- Framework discloses data breach via Metabase 0-day — news.ycombinator.com
Emeka has spent over a decade tracking threat actors, vulnerability disclosures, and the evolving landscape of application security, bringing a sharp continent-spanning perspective to his reporting. He's known for translating dense CVE advisories into clear, actionable context that developers and security teams alike actually read.
Discussion 1
zero-day in a customer-facing API endpoint. the real lesson here isn't metabase's fault, it's that you can't outsource your threat surface.