Framework and Trezor's Shipping Partner Both Got Breached Through Metabase

Two companies with nothing else in common, a laptop maker and a hardware wallet maker, both disclosed breaches within days of each other in early August, and both traced the root cause to the same place: Metabase, a business intelligence tool neither company’s own customers had ever heard of. We covered the underlying CVE on August 13, an unauthenticated SQL injection in Metabase’s password-reset endpoint that CISA confirmed was under active exploitation. What follows is what that exploitation actually looked like from the outside, at two real companies, in the same week.

What happened at Framework

Framework, the modular laptop and mini PC maker, emailed all of its customers on August 6 to say their personal data had been accessed: names, email addresses, phone numbers, and physical addresses. Payment details weren’t touched. The company traced the intrusion to Metabase, the BI tool used by Framework’s business database provider, which disclosed it had itself been compromised. Framework hasn’t published a customer count, but its spokesperson told TechCrunch the breach affected “all customers,” and the company has sold hundreds of thousands of devices over its history.

What happened at Trezor, by way of ShipMonk

Trezor, the hardware wallet maker, learned on August 10 that its shipping and fulfillment partner ShipMonk had been breached. ShipMonk’s own investigation pointed to the same vendor: an unauthorized party exploited a vulnerability in Metabase, the third-party analytics platform ShipMonk used, and pulled order data for Trezor customers who placed orders between May 10 and August 8. The exposure split into two tiers, 11,742 customers with full details exposed (name, email, phone, shipping address) and 1,947 with partial exposure (name, city, email), across the US, UK, Sweden, Colombia, Brazil, Italy, and Poland. Trezor was explicit that its own infrastructure, hardware wallets, private keys, and wallet backups were untouched, and warned customers to treat any message demanding urgent action as suspicious.

The timing lines up with the CVE, even without a confirmed name

Here’s what makes these two incidents worth reading together instead of as separate news items. CISA added CVE-2026-72898, an unauthenticated SQL injection in Metabase’s password-reset endpoint (CVSS 10.0, the maximum score), to its Known Exploited Vulnerabilities catalog on August 11, confirming attackers were already using it in the wild. ShipMonk’s breach notification to Metabase-related activity traces to around August 6. Framework’s disclosure lands the same week. Neither company’s public statement names CVE-2026-72898 directly, and we’re not claiming a confirmed one-to-one match here that hasn’t been publicly stated. What’s verifiable is the mechanism: an attacker with no account of their own reaching into a Metabase instance and pulling data connected to it, which is precisely the capability that CVE describes. Whether it’s that exact flaw or a closely related one, the operational lesson doesn’t change.

Company	What was breached	Root cause named	Data exposed
Framework	Framework’s own customer database, via its provider’s BI tool	Vulnerability in Metabase	Name, email, phone, address
Trezor (via ShipMonk)	ShipMonk’s shipping data, via its analytics tool	Vulnerability in Metabase	Name, email, phone, shipping address (full or partial)

Why a BI tool is worth this much attention

Metabase and tools like it exist to answer questions across your data, which means they typically hold live, working credentials to production databases, sometimes several of them, so a dashboard can query real numbers on demand. That convenience is exactly what makes a breached BI instance so much worse than a breached marketing site: an attacker with admin access to Metabase doesn’t just see aggregate charts, they can see the connection strings for whatever databases someone plugged in, and query those databases directly. We wrote about this exact gap when the CVE dropped: patching closes the hole for new attacks, but it doesn’t undo what an attacker already pulled through an existing connection, which is why the advice at the time was to rotate credentials for every data source connected to Metabase, not just the admin password.

Framework and ShipMonk are just the two incidents that became public in the same week the vulnerability class made headlines. If a BI tool with database credentials is running anywhere in your vendor chain, and it almost certainly is somewhere, this is the incident that should prompt asking your vendors directly whether they run one, whether it’s internet-facing, and whether it’s patched.

What to actually check

If you’re a Framework or Trezor customer, treat any unsolicited message referencing your recent order as suspicious and verify through the company’s official channels before clicking anything, exactly as Trezor advised. If you run infrastructure, the useful question isn’t “do we use Metabase,” it’s “does anything in our vendor chain use a BI tool wired into a database with our customers’ data in it,” because as both of these incidents show, that’s a question your own security review won’t answer unless you ask the vendor directly. Auditing subprocessors and demanding real breach-notification terms in vendor contracts, something we’ve written about before in the context of shipping-vendor breaches, is the unglamorous work that actually catches this category of exposure before a customer finds out from a data breach notification instead of from you.