On 13 August, Trezor disclosed that one of its shipping providers, ShipMonk, had been breached, and that the names, email addresses, phone numbers and shipping addresses of 11,742 customers, together with the names, cities and email addresses of a further 1,947, had been taken. The affected orders were delivered between 10 May and 8 August 2026 to customers in the United States, the United Kingdom, Sweden, Colombia, Brazil, Italy and Portugal. It was, in Trezor's own words, the first time since Trezor was founded in 2013 that we have experienced a breach that exposed customer phone numbers and shipping addresses.
On 4 September the post was updated. ShipMonk had informed Trezor two days earlier that the breach was larger than first stated, and that the stolen data also contained order records from a prior cooperation between November 2019 and August 2021: approximately 67,000 further United States customers, with full exposure of name, email address, phone number, shipping address and order number. Trezor's statement on that point deserves quoting in full, because it is the sentence the whole incident turns on: Throughout our entire relationship with ShipMonk, we repeatedly requested and received written assurance confirming the deletion of the data, in line with our contract, data policy, and past communications. By 7 September, BleepingComputer was reporting the combined figure as 81,000. It had reported as early as 13 August that ShipMonk had received extortion emails from the ShinyHunters group.
The Trezor devices were not touched. Trezor's own systems were not touched. No recovery seed, private key or wallet backup was involved, because none of those things ever passes through a shipping provider. Everything that follows is about the part of the business that has nothing to do with cryptography, and that is rather the point.
How the data was reached
The path in runs through Metabase, the open-source business-intelligence tool that a great many companies use to build dashboards over their operational databases. On 3 August a Metabase Cloud customer reported that an API key had been created on their instance outside working hours. Metabase's engineers found that the same source address had created keys on two different customer instances, traced the activity back, and identified a zero-day: an unauthenticated SQL injection in the password-reset endpoint, POST /api/session/reset_password, which let an attacker write a row into the session table for user ID 1, the first user in any Metabase installation and always created as an administrator, and then simply use that session. From there the attacker could browse every data source connected to the instance, read the stored credentials for those sources, create further API keys, and download data in bulk.
Metabase pushed a fix to its cloud fleet as soon as it had one, and shipped fixed versions for self-hosted users on 6 August, with advisory GHSA-vwf4-m7j8-wcjf confirming active exploitation. The flaw became CVE-2026-72898, scored CVSS 10.0, and CISA added it to the Known Exploited Vulnerabilities catalogue on 11 August with a remediation deadline of 14 August. Every installation from version 58 onwards was affected; the fixes are 58.24, 59.21, 60.17, 61.11, 62.9 and 63.5. Metabase's own figure is that under three per cent of its cloud customers were compromised before the patch, along with an unknown number of self-hosted instances that were reachable from the internet.
Two details from Metabase's post-mortem are worth holding on to. The first is that the bug was not old. It was the product of four layers of code interacting: a validation schema that accepted undeclared keys, a November 2025 refactor that began passing the whole request body rather than the filtered fields, a user lookup without sanitisation, and a raw-key parameter in the SQL builder. Each was defensible on its own. Together they were a straight route to administrator. The second is that Metabase believes this attack required significant LLM capabilities, citing early user-agent strings such as metabase-postgres-admin-session-lab-verifier/1 before the actor rotated to ordinary-looking ones. That is Metabase's inference rather than an established fact, but it is consistent with the speed at which a nine-month-old bug in a Clojure codebase was found and weaponised by someone who was not the vendor.
ShipMonk was among the victims. Whether its instance was Metabase's hosted service or a server of its own has not been made public, and for what follows it does not much matter. According to BleepingComputer's first report, Metabase notified ShipMonk on 6 August that its instance had been exploited, and ShipMonk told Trezor on Monday 10 August. Framework, Tally, n8n, Kilo Code and Checkly all disclosed their own losses from the same campaign in the first fortnight of August, and on 11 August ShinyHunters listed Metabase itself on its leak site. The attribution of the ShipMonk intrusion to ShinyHunters rests on the extortion emails ShipMonk received rather than on published forensics, and BleepingComputer reported on 7 September that there was no evidence of the Trezor data having been sold or posted publicly. ShipMonk has made no public statement of its own.
The timeline
Dates are as disclosed by the parties. Where a time of day has been published I give it in UTC.
November 2025. A refactor in Metabase's password-reset handling begins passing the full request body into the user lookup. The vulnerability now exists in every release from version 58.
2 to 3 August 2026. Exploitation is under way. Kilo Code later places its intrusion in a window of roughly four hours on 2 August; Framework and Tally place theirs on 3 August. On 3 August a Metabase Cloud customer reports an API key created outside working hours, Metabase begins its investigation and, once it has identified the flaw, patches its cloud instances.
6 August 2026. Metabase releases fixed versions for self-hosted and open-source users, publishes its advisory confirming in-the-wild exploitation, and notifies affected customers, ShipMonk among them. Framework notifies its customers the same day.
7 to 8 August 2026. Public reporting of the Framework and Tally breaches; n8n discloses on 8 August. The last Trezor order in the initially affected range is delivered on 8 August.
10 August 2026. CVE-2026-72898 is published. ShipMonk informs Trezor that Trezor customer data was accessed.
11 August 2026. CISA adds the flaw to its KEV catalogue with a due date of 14 August. ShinyHunters lists Metabase on its leak site.
13 August 2026. Trezor publishes its disclosure and emails every affected customer: 11,742 fully exposed, 1,947 partially, orders delivered between 10 May and 8 August across seven countries. BleepingComputer reports that ShipMonk has received extortion emails from ShinyHunters.
14 August 2026. Trezor clarifies that the 1,947 partial-exposure records include some orders older than 10 May.
2 September 2026. ShipMonk informs Trezor that the stolen data also included records from Trezor's earlier engagement between November 2019 and August 2021.
4 September 2026. Trezor updates its post: approximately 67,000 additional United States customers, fully exposed, all emailed directly. Trezor states that it had repeatedly requested, and received in writing, confirmation that this data had been deleted.
7 September 2026. BleepingComputer reports the combined total as 81,000. Trezor's post still carries the line that its investigation is ongoing.
The interval that matters most in that sequence is not the four days between Metabase's patch and ShipMonk telling Trezor, nor the three days Trezor then took to notify customers. Both of those are respectable. It is the twenty-three days between ShipMonk's first notification and its second, and the five years between the end of the earlier engagement and the moment anyone discovered the data was still there.
The deletion that never happened
Trezor's retention rule is short and clear. Its own shop deletes or anonymises purchase data after ninety days, and its post says it was also able to negotiate the same terms with fulfillment partners, who follow the same policy; for a partner, under our policy they must delete or anonymize it 90 days after delivery. The rule was not the problem. What failed was the gap between a contractual requirement, a written assurance that the requirement had been met, and what was actually sitting in a database at the partner.
The numbers in Trezor's first disclosure suggest the rule was being applied, after a fashion, to the current engagement. The window of full exposure, 10 May to 8 August, is ninety days to the day. The 1,947 records that survived with only a name, a city and an email address, which Trezor says include older orders, look very much like the residue of a ninety-day process that strips the street address and the phone number and calls the result anonymised. It is not anonymised in any sense a data protection authority would recognise, since a name and an email address identify a person perfectly well, but it does at least show that a process existed. The 67,000 records from 2019 to 2021 sat outside that process entirely. That is an inference from the published field lists rather than anything either company has said, and I offer it as such.
I do not know how ShipMonk came to still hold five-year-old Trezor order data, and neither, from the wording of its post, does Trezor. But anyone who has run a data-deletion programme in a real company can name the usual suspects, and the fact that the data was reachable through a business-intelligence tool narrows the field. Operational systems get purged; the analytics warehouse those systems feed does not. A reporting database is refreshed from a snapshot that predates the purge. A backup is restored for an unrelated reason and never re-purged. A platform migration, and an engagement that ended in August 2021 and later resumed will have seen at least one, leaves the old tenant's data in a schema nobody owns any more. In each case the person who signs the deletion confirmation is telling the truth about the system they looked at. They are simply not looking at the system where the second copy lives.
This is the general lesson, and it is not specific to Trezor or ShipMonk. A written assurance of deletion is a statement of belief by the supplier about the systems the supplier thought to check. It is not evidence. Evidence looks like a query run against every data store the supplier operates, transactional, analytical, cache, backup and export, returning zero rows for your customer identifiers, with the query and the result retained. Most contracts ask for the assurance. Very few ask for the evidence, and fewer still exercise the audit right that would let them obtain it. Trezor, to its credit, asked more than once. That it asked, and was told yes, and was wrong to believe it, is the most instructive fact in this incident for anyone who has ever filed a supplier's deletion certificate and moved on.
There is a second, structural point about where the data was found. Metabase is not where data lives; it is where data becomes queryable across everything at once. A BI tool with connections to the order database, the warehouse and the customer-service platform is, by design, the single place from which all of those can be read with one set of credentials. Compromising it does not require compromising any of the underlying systems. Whether ShipMonk's instance was hosted by Metabase or by ShipMonk, it was reachable from the internet, because that is what these tools are for: Metabase, Grafana, Redash and their cousins are built to be logged into from a browser. That arrangement is worth revisiting in any organisation. The tool that lets the operations director see every customer on one dashboard lets an attacker do the same.
Why this data is different in Trezor's hands
For most online retailers, a leaked name, address and phone number is a phishing and fraud problem. For a hardware-wallet manufacturer it is something else, because the fact of the purchase is itself the sensitive datum. Every person on that list has told the world that they hold cryptocurrency in self-custody, and where they sleep.
The precedent is Ledger. In June 2020 an attacker used a third party's API key to read Ledger's e-commerce and marketing database, and on 20 December 2020 the contents, 1,075,382 email addresses and 272,853 records with names, postal addresses and phone numbers, were posted on RaidForums. What followed was years of phishing, fake Ledger Live downloads, tampered devices sent through the post, and, as The Block noted last week, scam calls and letters that Ledger customers still report receiving. Data of this kind does not expire when the news cycle moves on. Home addresses change slowly; phone numbers more slowly still.
The environment into which the Trezor data has now leaked is considerably more dangerous than the one Ledger's leaked into. Chainalysis puts the value stolen through physical coercion, the kidnappings and home invasions the industry calls wrench attacks, at a record $58 million in 2025, with 2026 on course to exceed it; home invasions have risen from 26 per cent of incidents in 2023 to 37 per cent by the middle of this year. France, which had few such cases before 2025, recorded 19 in that year and 30 publicly known cases in the first half of 2026, with the authorities documenting over 70. The kidnapping of Ledger co-founder David Balland in January 2025, during which a finger was severed to accompany the ransom demand, is the case everyone in the industry knows. TRM Labs' Phil Ariss described the shift as one from find a wallet to hunt a person, and Chainalysis names data breaches among the principal ways victims are selected.
None of this means the 81,000 people on the ShipMonk list are in imminent danger. Most will experience nothing worse than a plausible-looking email. But it does mean that Trezor's warning that the data could potentially expose affected individuals to physical security risks is a plain statement of the threat model rather than a lawyer's flourish, and that the ordinary breach-response playbook of resetting a password and watching a bank statement is not the right one. Trezor's own advice is more useful: never enter a wallet backup anywhere, treat any unexpected contact as hostile, and for future orders consider an email address not linked to your identity, payment in crypto rather than by card, and a PO box. I would add one thing. The passphrase feature on Trezor devices exists precisely so that the wallet a coerced owner opens need not be the wallet that holds the funds. It has always been a good idea. For anyone on this list it is now a considerably better one.
Trezor's record, and what it says about the perimeter
The August incident is the latest in a run that goes back four and a half years, and in none of them was the device the way in. In April 2022 an attacker who had social-engineered Mailchimp employees exported the newsletter audiences of 102 Mailchimp customers, most of them in crypto and finance, and Trezor's subscribers received a fake breach notice pushing a trojanised Trezor Suite. In February 2023 a mass SMS and email campaign claimed a breach that had not happened and harvested seeds from anyone who believed it. On 17 January 2024, unauthorised access to Trezor's third-party support ticketing portal exposed the names and email addresses of some 66,000 people who had contacted support since December 2021; access was cut at 19:20 UTC that day, and 41 of them subsequently received messages, posing as automated support replies, asking for their 24-word seed for firmware validation. In June 2025 the attackers did not need a breach at all: they abused the support contact form so that Trezor's own help desk auto-replied from help@trezor.io with a phishing subject line the attacker had written.
Set those alongside August 2026 and the pattern is exact. Marketing platform, impersonation campaign, support desk, support desk again, fulfilment partner. In every case the attacker went after the layer where Trezor's customers are just rows in somebody else's database, and in every case the objective was the same: put a convincing message in front of a person who holds a seed phrase, and get them to type it in. A company whose product is the strongest link in the chain has spent four years being attacked through the second-strongest, and the second-strongest is always a supplier.
That is not a criticism unique to Trezor. It is the standard shape of compromise now, and I wrote about it in January under the title the supplier underneath the supplier. Here the chain is one layer longer than usual: Trezor depends on ShipMonk, ShipMonk depends on Metabase, and Metabase had a bug introduced by a refactor nine months earlier. Trezor's security questionnaire to ShipMonk almost certainly did not ask which version of Metabase it ran, and there is no version of a questionnaire that would have caught a zero-day. What a questionnaire could have asked is which of the supplier's tools hold standing credentials to the customer data, who can reach them, and whether the deletion the contract required had ever been tested.
What Trezor got right, and what remains open
The disclosure was quick: three days from ShipMonk's notification to a public post and direct emails, with a clear statement that anyone who had not received an email was not affected. The post is specific about numbers, date ranges, fields and countries, and it has been kept current. It declines to sell fear. Those are things many larger companies fail to do, and they are worth acknowledging.
What is not yet public matters too. Trezor has said its investigation is ongoing. It has not said whether it will continue to use ShipMonk, whether it has gone back for the evidence of deletion it was previously given only in writing, or whether it has notified any supervisory authority. Given that the May-to-August tranche includes customers in the United Kingdom and three EU member states, and that Trezor is a Czech company, one would expect a notification to the Czech Office for Personal Data Protection as lead authority and to the ICO for the British customers; nothing has been reported either way. ShipMonk, whose systems were the ones compromised, has said nothing publicly at all. When a processor has held a controller's data for five years past its contractual deletion date and then lost it, silence is not a position that lasts. The questions, for a United States processor holding EU and UK residents' data, and under state breach-notification law for the 67,000 US residents, will be asked whether or not anyone is answering them now.
For boards
Three questions, none of which requires a technical answer.
Which of our suppliers hold personal data about our customers, and when did we last see evidence, rather than an assurance, that the data we told them to delete is gone? If the answer is a signed letter or a ticked box, that is what Trezor had.
Where in our own estate, and in our suppliers', is the one tool from which everything can be read at once? It is usually the reporting or analytics layer, it is usually reachable from the internet because that is convenient, and where it is self-hosted it is usually patched on a slower cycle than anything customer-facing.
If our customer list leaked tomorrow, what would it tell an attacker about our customers beyond their contact details? For a hardware-wallet vendor the answer is that they hold self-custodied crypto. For a private clinic, a security firm, a fertility service, a defence contractor or a law practice the answer is something equally specific. The half-life and the danger of a customer list come from what membership of it implies.
The closing observation
Trezor's post says that it chose ninety days because it is the shortest window that still covers the whole life of an order. That is the right instinct, and it is the instinct this incident vindicates. The 13,689 records from the current engagement were the unavoidable cost of shipping a physical product to a person. The 67,000 from 2019 to 2021 were not. They existed because a deletion was promised and never verified, and they are now in the hands of an extortion group whose fallback, when a victim declines to pay, is publication. The difference between the two numbers is the difference between a breach and a policy failure, and the policy that failed was not Trezor's. It was the industry's habit of accepting a supplier's word for what it no longer holds.