Framework, the maker of modular and repairable laptops, has told its entire customer base that their personal information was stolen in a breach that did not begin on Framework's own infrastructure. According to TechCrunch, which reviewed the customer notification and obtained comment from Framework spokesperson Eric Schumacher, the intrusion originated upstream at Metabase, the business intelligence provider Framework uses, where attackers exploited a previously unknown vulnerability to reach customer databases hosted on Metabase's cloud servers. Framework confirmed the scope as "all customers" but declined to give a number, and no source in this reporting set supplies one. TechCrunch notes only that outside estimates put Framework's lifetime device sales in the hundreds of thousands, a figure that is an approximation of units sold rather than a count of affected individuals.
A sourcing caveat up front: there is no regulator filing, national CERT advisory, or directly quoted primary statement in the material available for this brief. TechCrunch is the sole established security-press account, and several of the other items available (Tech Weekly, Wired24, Cryptonomist, Blogarama) are close restatements of that TechCrunch story rather than independent reporting. How-To Geek adds detail not present in the TechCrunch account, and the Framework community forum thread carries first-hand recipient accounts. Points that rest on a single lower-tier source are attributed as such below.
What Happened
The sequence, as best it can be reconstructed, runs upstream to downstream. How-To Geek dates the attack on Metabase to August 3, 2026, and describes it as the compromise of Framework's database provider. That date appears only in the How-To Geek account and is not corroborated by TechCrunch.
Metabase disclosed its own breach in a post on its official website, stating that an attacker used an unknown security flaw, a zero-day, to gain the ability to access customer databases stored on Metabase's cloud servers. Framework's notification email to customers included the message Metabase had sent to Framework, which stated that the attackers accessed Framework's cloud instance specifically. Framework then ran its own investigation and concluded that customer personal data had been taken.
Notification reached customers on the evening of August 6, 2026. The Framework community forum thread opens with a post timestamped August 6 at 10:37pm from a customer who had just received the email; How-To Geek likewise gives August 6 as the notification date. Social media reports of the email, and TechCrunch's story, followed on August 7.
Forum participants have circulated a tighter timeline than any outlet has confirmed. One commenter in the Framework community thread characterises it as a three-day turnaround from Metabase's initial discovery to partner notification, and roughly six hours from Framework receiving Metabase's notice to notifying its own customers. Those intervals come from a customer's reading of the disclosure, not from Framework or Metabase, and should be treated as unverified. What the sources do support is that the notification was fast by industry standards and that recipients broadly said so.
Metabase did not respond to TechCrunch's request for comment. How-To Geek reports that Metabase told Framework it is working with a third-party investigator to understand the full nature and scope of the attack, and that the vulnerability has since been fixed. Attribution is open: no source names an actor, and no source reports a ransom demand, extortion note, or public leak of the data.
What Was Taken
All sources agree on the core set. The stolen data comprises customer names, email addresses, phone numbers, and physical addresses.
How-To Geek adds login IP addresses to that list. That element appears in no other account here, including TechCrunch's, so treat it as reported rather than confirmed.
On what was not taken, the sources are consistent. Framework's notification states that payment information was not included. A participant in the community thread, responding to another customer asking specifically about credit card exposure, points to Framework's privacy policy indicating that Stripe handles payments, which would keep card data outside the Framework datasets exported to a BI tool. That is a plausible customer inference, not a Framework statement, though it is consistent with the company's own assurance. How-To Geek further reports that Framework found no evidence of access to systems beyond Metabase and no changes to administrator-level control, and that Framework rotated credentials after receiving Metabase's notice.
Volume remains the largest open question. Framework says all customers and gives no count. Reports do not offer competing record figures; they offer no figure at all, which is a different and in some ways more awkward gap. The hundreds-of-thousands estimate that TechCrunch cites and that Tech Weekly, Wired24, and Cryptonomist repeat is about devices sold, and should not be read as a victim count.
One detail from the community thread widens the population beyond buyers. A Hacker News commenter reports receiving the notification email despite never having completed a purchase, having only filled in an address to check final pricing including shipping. If abandoned-cart and quote records were inside the same BI dataset, the affected population is larger than Framework's customer list and includes people who never became customers.
Why It Matters
The interesting part of this incident is not the data, which is ordinary contact information, but the shape of the exposure. Framework was not breached. Framework's segmentation, credential hygiene, and patching posture were not what failed. The data left through an analytics pipeline the company had legitimately configured, at a vendor whose product exists precisely to hold copies of production data for querying.
Business intelligence platforms are a structurally attractive target for exactly this reason. They aggregate. A BI instance is where the customer table, the orders table, and the support table are joined into something convenient, and convenience for an analyst is convenience for an intruder. A single zero-day in a multi-tenant BI cloud yields not one company's records but a set of pre-joined, pre-cleaned customer datasets across every tenant. Downstream Framework customers had no relationship with Metabase, no ability to evaluate its security, and in most cases no idea it held their address. That point was made bluntly by customers in the Framework forum, one of whom noted the growing normalisation of having personal data exposed by a company they had never heard of or interacted with.
For defenders the practical lesson is that the vendor inventory that matters is not the one procurement maintains but the one your data actually flows through. Analytics, BI, CDP, and reverse-ETL tooling frequently sits outside the vendor risk process because it is adopted by data teams rather than IT, and because it is read-only from the perspective of the business, which quietly obscures that it is a full copy of the crown jewels.
There is also a disclosure benchmark here worth recording, with the caveat above about unverified intervals. A vendor notified its downstream customers within days of discovery, that customer confirmed impact and notified end users the same night, and the notification named the upstream provider and stated plainly what was and was not taken. Customer reaction in the community thread was notably positive on the handling even where it was negative on the underlying data-sharing practice. That is a template most incident response programmes do not currently meet.
The Attack Technique
Details are thin, which is expected at four days post-disclosure with an investigation still running.
Metabase's own account, as relayed through Framework's notification and reported by TechCrunch, is that the attacker exploited a previously unknown vulnerability, a zero-day, and used it to access customer databases stored on Metabase's cloud servers. How-To Geek characterises the flaw more specifically as an SQL-oriented zero-day that has since been patched. No CVE identifier, exploit detail, patch reference, or indicator of compromise appears in any source available for this brief.
What that description implies, if the SQL characterisation holds, is an injection or query-layer flaw allowing an attacker to escape the intended query scope and read tenant data directly. Framework's statement that the attackers accessed its cloud instance, and its finding of no lateral movement into Framework's own systems and no administrator-level changes, is consistent with data access confined to the BI platform rather than a broader compromise of Framework's environment.
Also unknown: dwell time, whether other Metabase tenants were affected, and whether the data has been sold, leaked, or held. Framework and Metabase customers should expect the picture to change as the third-party investigation reports.
What Organizations Should Do
Map your analytics data flows, not just your vendor list. Enumerate every BI, warehouse, ETL, reverse-ETL, and dashboarding tool that touches customer PII, including ones adopted directly by data or growth teams. For each, record what tables and columns it holds, whether the copy is live-synced or extracted, and who at the vendor can read it.
Minimise what reaches the BI layer. Full names, phone numbers, and street addresses rarely drive analytics. Tokenise or hash direct identifiers before export, ship geography at postcode or region granularity, and keep raw contact data in the transactional system. Framework's outcome was survivable largely because payments sit with Stripe rather than in the exported dataset; extend that same reasoning to the rest of the record.
Set and enforce retention inside analytics tools. The abandoned-cart case reported in the community thread is the archetype: records with no ongoing business value expanding the blast radius. Expire non-transacting and stale records from BI datasets on a schedule and verify the deletion actually propagates through the sync.
Contract for notification speed, not just notification. Require vendors to notify on discovery rather than on conclusion of investigation, with a defined maximum interval, and require them to identify which of your specific instances or datasets were touched. The value of Metabase's notice to Framework was that it named the affected cloud instance, which is what let Framework confirm and notify quickly.
Rehearse credential rotation across third parties. Framework's rotation of credentials after the notice is the correct reflex. Pre-stage it: know for every data vendor which API keys, service accounts, and OAuth grants must be rolled, who can roll them, and how to verify no stale token survives.
Brief customers and staff on the follow-on threat. Name, address, phone, and email is a high-quality phishing and voice-fraud kit, and, as one recipient in the forum thread anticipated, the practical consequence is a wave of targeted spam and phishing. Expect lures impersonating Framework support, order updates, and shipping notices, and warn customers that these will be more convincing than usual because the attacker knows what they bought and where it went.
Sources: Computer maker Framework notifies 'all customers' of a data breach | Framework customer data leaked in zero-day attack - How-To Geek | Framework discloses data breach via Metabase 0-day - Hacker News | Computer Manufacturer Framework Alerts All Customers About Data Bre... | Computer Manufacturer Notifies All Customers of Data Breach Warning... | Framework Data Breach Discussion - General Topics | Framework data breach hits all customers after Metabase zero-day ... | Framework Notifies 'All Customers' of a Data Breach Via Compromised...