Notice: This article reconstructs the data breach that affected 13,689 Trezor customers, disclosed on August 13, 2026, with data verified as of August 18, 2026, against official statements from Trezor, Metabase, and public notifications from ShipMonk. It does not constitute financial or legal security advice. CleanSky does not receive commissions or referral payments from any company mentioned.
The mailing addresses of 11,742 Trezor buyers were leaked through a company none of them signed anything with: Metabase, the analytics platform used by ShipMonk, the logistics provider that ships the devices. Trezor reported the breach on August 13, 2026: 13,689 affected customers in total, with orders delivered between May 10 and August 8 across seven countries. Trezor devices, private keys, and proprietary systems were not touched — the exploited flaw was an SQL injection (a technique that sneaks malicious commands into a database via a form) in the Metabase software, cataloged as CVE-2026-72898 with a maximum severity score of 10.0. This article follows the data's journey in both directions: the two hops that distanced the buyer's address from the company they trusted, and the seven days it took for the warning to travel back up the chain to them. Along the way, the only control that worked appears: a 90-day contractual clause that explains why the figure is 13,689 and not several hundred thousand.
What Trezor customer data was leaked on August 13, 2026?
According to Trezor's official statement on August 13, 2026, the incident affects customers who received an order between May 10 and August 8, 2026, in the United States, United Kingdom, Sweden, Colombia, Brazil, Italy, and Portugal. The exposure has two levels:
| Group | Affected | Exposed Data |
|---|---|---|
| Full exposure | 11,742 | Name, email, phone, and physical shipping address |
| Partial exposure | 1,947 | Name, city, and email (without exact address) |
| Total | 13,689 | — |
The sum matches the total figure published by Trezor (11,742 + 1,947 = 13,689). What was not leaked matters as much as what was: according to the same statement, no Trezor device was compromised, no private keys or backups were exposed, and the company's own systems suffered no unauthorized access. Trezor individually notified each affected person by email and set the verification rule in the post itself: anyone who has not received a notification email is not on the list.
The most sensitive piece of data in the package is the physical address. A leaked email enables phishing; a shipping address associated with the verified purchase of a hardware wallet describes where someone who self-custodies their own cryptocurrency lives. That framework — from data leakage to physical risk, with the series of Ledger precedents since 2020 — was already detailed with its own table in our analysis of physical attacks on crypto holders in France; this breach adds a new row to that series, with 11,742 more addresses.
How did a Trezor buyer's address end up at Metabase?
The buyer provided their data to Trezor when placing the order. Trezor passed it to ShipMonk, its logistics provider for several markets, because without an address, there is no delivery. ShipMonk, in turn, connected its operational data to Metabase, a business intelligence platform (software that builds dashboards and queries over a company's databases). The customer's data ended up living two contractual hops away from the only company whose name they knew.
The link that broke was the third one. On August 6, 2026, Metabase published a security advisory: an attacker had exploited a zero-day vulnerability (a flaw unknown to the manufacturer until someone uses it) in their cloud that allowed for arbitrary SQL injection through an unauthenticated endpoint (API access point). The flaw, later registered as CVE-2026-72898 with a CVSS of 10.0 according to the report by The Hacker News on August 8, granted administrative access to the instance: configuration, credentials for connected databases, and the ability to export any data accessible from them. It affected versions 58 and above; Metabase patched its cloud and released corrected versions for self-hosted installations (six, from 0.58.24 to 0.63.5 depending on the branch).
ShipMonk was not the only customer affected. At least three more victims have been publicly disclosed with the same CVE in the first half of August 2026: Framework, the repairable laptop manufacturer, with names, emails, phones, addresses, and login IPs exposed; n8n, the automation platform, with 136 customer records; Tally, and Kilo Code, the AI programming assistant, with a four-hour incident on August 2 that exposed Slack access tokens. A Trezor buyer shares a root cause with a Framework laptop buyer: none of the companies they gave their data to wrote the code that failed.
It is worth noting the contrast in vectors. In July 2026, the entropy flaw in Coldcard firmware compromised the device itself — the object the user holds in their hand. Here, the opposite occurs at every point: the device is intact, and what is compromised is the administrative perimeter surrounding it, a perimeter the user did not contract and whose inventory — logistics, analytics, support — they only learn about when one of its links appears in a security advisory.
How long did it take for the warning to travel the chain to the Trezor customer?
The full chronology, reconstructed from the statements of the three companies and the CISA (U.S. Cybersecurity and Infrastructure Security Agency) catalog of exploited vulnerabilities:
| Date (2026) | Event | Source |
|---|---|---|
| August 2 | ~4-hour incident at Kilo Code, first disclosed victim of the same flaw | Kilo Code statement |
| August 6 | Metabase publishes security advisory and notifies affected customers; ShipMonk receives the notice the same day, according to its customer notification | Metabase blog; ShipMonk notification |
| August 8 | Last day of the affected Trezor order window | Trezor statement |
| August 10 | ShipMonk notifies Trezor of unauthorized access to its customers' data | Trezor statement |
| August 11 | CISA adds CVE-2026-72898 to its Known Exploited Vulnerabilities catalog | CISA alert |
| August 13 | Trezor publishes disclosure and notifies the 13,689 affected by email | Trezor blog |
| August 14 | CISA deadline for U.S. federal agencies to patch | CISA KEV catalog |
The transit arithmetic: from the Metabase notice to ShipMonk (August 6, according to the ShipMonk notification cited by BleepingComputer on August 13: "On August 6, 2026, Metabase informed us that an unauthorized party exploited a vulnerability in the Metabase software to access data related to your account and your customers") to the ShipMonk notice to Trezor, four days passed. From there to Trezor's public disclosure, three more. Seven days in total between the moment the first link knew of the problem and the moment the customer could know. None of the three companies has publicly explained what occupied each segment — forensic verification, counting the affected, and legal coordination are the usual steps — and the data that remains undisclosed is how long the attacker was inside before August 6.
Those seven days are not neutral for the affected: every day between exfiltration and notification is a day when data can circulate without its owner knowing they should distrust an email citing their actual order.
Why was the Trezor breach limited to 13,689 affected?
The affected window runs from May 10 to August 8, 2026: exactly 90 days, matching the company's retention policy. According to Trezor's August 13 statement, Trezor contractually requires its logistics partners to delete or anonymize order data 90 days after delivery. Everything prior to May 10 was no longer in the provider's systems when the attacker arrived — and that is why the number of affected was limited to the size of the retention window.
The contrast with the classic precedent is in the scale. In the Ledger e-commerce breach of June 2020, data accumulated without a retention limit ended up in a public dump in December 2020 with more than 270,000 physical addresses — the full series of consequences, including subsequent physical attacks, is in our analysis of the French case. Compared to that ceiling, 11,742 exposed addresses equal just over 4% of that figure, and the main difference is marked by a deletion policy that turned the historical archive into a non-existent target.
The control that contained the damage was not at the technical layer. Device encryption, the secure element, and audited firmware protect the keys; none of them reach a subcontractor's database. What did reach it was a contract clause — a paper control that operated as a firewall, limiting the blast radius to the last 90 days of orders.
Is this the first time Trezor customer data has been leaked through a third party?
It is the third documented time in four and a half years. All three through different providers, and none through the company's own systems:
| Date | Third Party Involved | What was exposed | Affected |
|---|---|---|---|
| April 2022 | Mailchimp (email marketing) | Newsletter list, used in phishing with a fake Trezor Suite from the trezor.us domain | 102 Mailchimp accounts compromised; Trezor's list among them |
| January 2024 | Third-party support portal | Names and emails of support contacts since December 2021 | Up to 66,000 |
| August 2026 | ShipMonk → Metabase (logistics → analytics) | Order data, including physical address in 11,742 cases | 13,689 |
All three cases share a second-phase mechanic. In April 2022, the attacker who accessed Mailchimp's internal tool via social engineering of its employees used the list to send Trezor users a link to a fake version of Trezor Suite that captured the recovery phrase. In January 2024, after access to the support portal was detected on the 17th, Trezor confirmed that 41 users received emails from the attacker directly asking for their recovery phrase. In all three cases, the stolen data served as raw material for subsequent impersonation.
The history also traces the progression of distance: in 2022, the third party was a direct provider with the mailing list; in 2024, a direct provider with support tickets; in 2026, the provider of a provider with the full order database: three incidents in four and a half years, and in each one, the data leaked through a company other than the one the customer knew.
What can a Trezor breach victim do, and what is no longer possible?
The operational distinction is which data is reversible. An email can be replaced, and a phone number can be changed with some friction. A physical address associated with the verified purchase of a hardware wallet is, barring a move, permanent data: the leaked list functions as a lasting census of where 11,742 people who bought a self-custody device in 2026 live. That is why Trezor's statement focuses its recommendations on phase two — the use of the data — and not on the data already lost.
The rules Trezor set on August 13 are three:
- Distrust any communication that demands immediate action.
- Verify everything through official channels.
- Never enter the wallet backup on a website.
The third is the real lock. The entire attack chain following a data leak — the email citing your real order, the call that knows your address, the physical letter with a QR code — converges at the same final point: getting the victim to type in their recovery words. The full anatomy of that phase, including the $282 million theft from a hardware wallet user in January 2026, is broken down in our analysis of wallet drainers, and the basic defensive principles in the security guide.
There is a structural detail the affected person must keep in mind: Trezor notified the breach by email — the same channel the attacker can now impersonate with more credibility than ever, because they possess the name, phone, address, and the certainty that the recipient bought a Trezor between May and August. Valid verification is not the appearance of the email — it is that no request for the 24 words, wherever it comes from, is legitimate. The January 2024 precedent, with 41 users contacted directly by the attacker after that leak, sets the expected pattern for the coming weeks.
What questions does the Trezor breach leave open?
Three, as of August 18, 2026. First: how many other ShipMonk customers were affected. ShipMonk provides logistics for many e-commerce brands, and its notification cited by BleepingComputer on August 13 speaks of data "from your account and your customers" without a global figure; only Trezor has disclosed its count in detail. Second: how many self-hosted Metabase instances remain unpatched. The August 6 advisory only automatically covers the Metabase cloud; self-hosted installations depend on each administrator updating, and the August 14 deadline imposed by CISA only mandates U.S. federal agencies. Third: the window prior to August 6 — how long the attacker had access before detection is not stated in any public communication from the three companies.
For the reader evaluating manufacturers, in addition to the usual questions — what chip the device uses, if the firmware is auditable (the Coldcard episode in July covered that vector), if the company has suffered intrusions in its own systems — this case adds another: how long do your providers retain your data and what does the contract require them to do with it afterward. In August 2026, that figure — 90 days — made the difference between 13,689 affected and the entire archive of Trezor buyers. It is a number that any manufacturer can publish and that almost none do.
Related articles: From data leak to physical attack: the French case. Wallet drainers: the anatomy of recovery phrase phishing. Privacy and security in crypto: fundamentals. Monitor your positions on CleanSky — wallet and portfolio tracking without giving up custody of your keys.