Trezor ShipMonk Data Breach Widens: 67,000 More US Customers Exposed as "Deleted" Records Resurface
Quick Answer: Trezor confirmed on September 4, 2026 that a breach at fulfillment partner ShipMonk exposed roughly 67,000 additional US customers' names, emails, phone numbers, and addresses — old 2019–2021 order data ShipMonk had assured Trezor was deleted. Total impact now exceeds 80,000 people. Trezor's devices and wallet backups were not affected.
Last verified: September 7, 2026
Picture this: you run incident response for a hardware wallet company whose entire brand promise is "your keys never touch our servers." Your systems are clean. Your cold storage architecture holds. And then your shipping vendor calls to say the breach you closed out three weeks ago just got six times bigger — because data they swore, in writing, was deleted, was still sitting in their database the whole time.
That's the position Trezor found itself in this week. And for SOC analysts and incident responders, this case is a textbook lesson in why "our systems weren't breached" is never the end of the story when a third-party vendor holds your customer data.
Table of Contents
- What Happened: Timeline of the Trezor-ShipMonk Breach
- Root Cause: The Metabase SQL Injection Zero-Day
- What Data Was Actually Exposed
- The Real Story: A Broken Data Retention Promise
- Why This Isn't Just a Phishing Risk
- Detection & Response Angle for SOC Teams
- Prevention: Third-Party Data Retention Controls
- Expert Tips
- FAQ
- Conclusion
What Happened: Timeline of the Trezor-ShipMonk Breach
The incident unfolded in two distinct waves, and the gap between them is where the real story lives.
Wave one (August 2026): On August 10, 2026, ShipMonk — a third-party logistics provider that stores and ships Trezor hardware wallets — notified Trezor of unauthorized access to its systems. Trezor disclosed the breach publicly on August 13, reporting that 11,742 customers had their full names, email addresses, phone numbers, and shipping addresses exposed, with another 1,947 customers partially exposed (name, city, email only). That put the initial total at approximately 13,689 affected customers, tied to orders placed between May 10 and August 8, 2026 across the US, UK, Sweden, Colombia, Brazil, Italy, and Portugal.
Wave two (September 2026): According to Trezor's update, the company was told on September 2 that the breach also included a separate, older dataset: order records from a prior ShipMonk partnership running November 2019 through August 2021. Those records — approximately 67,000 US customers — were fully exposed. Trezor confirmed this publicly on September 4, 2026, pushing the combined total past 80,000 affected customers.
That's not a rounding error in an incident report. That's a breach that grew roughly sixfold after the "final" scope had already been communicated to customers.
Root Cause: The Metabase SQL Injection Zero-Day
Per ShipMonk's notification to Trezor, the intrusion traces back to a critical SQL injection zero-day vulnerability in Metabase, the third-party analytics platform ShipMonk used to query its operational and customer data. According to public breach reporting, Metabase notified ShipMonk on August 6, 2026 that an unauthorized party had exploited the vulnerability to gain administrator-level access to the instance, from which customer order data was exfiltrated.
This wasn't an isolated event. Other companies — including laptop maker Framework and form-builder platform Tally — disclosed similar breaches tied to compromised Metabase instances around the same period, pointing to a broader campaign against Metabase deployments rather than a Trezor- or ShipMonk-specific attack. Public reporting has attributed extortion activity following the intrusions to the ShinyHunters group, though the direct link between ShinyHunters and the initial exploitation has not been independently confirmed in all reporting — worth flagging as attribution rather than settled fact.
From a MITRE ATT&CK lens, the attack chain maps cleanly to a familiar pattern for SOC analysts:
- Initial Access — Exploit Public-Facing Application (T1190), via the Metabase SQL injection flaw
- Privilege Escalation — Exploitation for Privilege Escalation (T1068), reaching administrator access on the Metabase instance
- Collection / Exfiltration — Direct querying and extraction of customer order records through the compromised analytics layer
Metabase reportedly patched the vulnerability and invalidated active sessions after disclosure, but for organizations that had already been breached, the damage was already done.
What Data Was Actually Exposed
Across both disclosures, the exposed fields are consistent: full name, email address, phone number, shipping address, and — in the newly disclosed 2019–2021 batch — order number. No payment card data, wallet seed phrases, private keys, or Trezor device data were part of either exposure. Trezor has been consistent and specific on this point across both disclosures: its own infrastructure was never touched, and hardware wallets themselves remain secure regardless of this incident.
That distinction matters for how you communicate risk to affected users — this is a contact-data and physical-location exposure, not a cryptographic compromise. But for a company whose customers self-select as crypto asset holders, contact-data exposure carries its own weight, which we'll get to below.
The Real Story: A Broken Data Retention Promise
Here's the part that should worry every security team that outsources data handling to a vendor: Trezor's original August 13 disclosure was deliberately scoped around a 90-day data retention policy. Trezor's stated policy requires fulfillment partners to delete or anonymize order data 90 days after delivery — covering the full lifecycle of an order including returns and refunds. Trezor said it repeatedly requested, and received, written assurance from ShipMonk confirming that older records had been deleted in line with that policy.
They hadn't been. The September 2 notification revealed that data going back to November 2019 — nearly five years past the point it should have existed anywhere in ShipMonk's systems — was still there when the Metabase compromise occurred.
This is the crux of the incident from a governance standpoint. Trezor did what a mature vendor risk program is supposed to do: contractually mandate data minimization, request confirmation, and document that confirmation. The control failed anyway, because it relied on the vendor's word rather than independent verification. Written assurance is not the same as an audited deletion log.
Why This Isn't Just a Phishing Risk
Most breach notifications warn about phishing, and Trezor's does too — the combination of name, email, phone number, and physical address is exactly what's needed to craft a convincing impersonation of Trezor support, a bank, or an exchange, pressuring a victim to enter a recovery seed somewhere they shouldn't.
But Trezor's own notice goes further, explicitly flagging physical security risk. That's a deliberate, unusual escalation in a breach notice, and it's justified by the threat landscape: publicly tracked data on crypto-related violent incidents has shown a rising trend in 2026 compared to the prior year, with kidnapping making up a majority share of documented cases. Home address plus known hardware-wallet ownership is a dangerous combination for this specific customer base — this isn't generic breach-notice boilerplate.
Trezor's response includes a practical mitigation: an "Anonymous Delivery" option using locker pickup with automatic deletion of shipping identifiers, aimed at removing the home-address linkage from future orders entirely.
Detection & Response Angle for SOC Teams
If your organization uses Metabase — internally or through a vendor — this incident is a prompt to check your own exposure, not just read about someone else's.
- Confirm your Metabase instance (or your vendors') is patched against the critical SQL injection zero-day disclosed in August 2026, and that all active sessions were invalidated post-patch, not just new sessions blocked.
- Review admin-level access logs on any business intelligence or analytics tool that sits in front of customer PII — these tools are frequently under-monitored compared to production databases, despite holding equivalent data.
- If a vendor breach notification references SQL injection as the entry vector, treat any BI/analytics layer with database query access as in-scope for the investigation, not just the primary application.
- Watch for a spike in highly targeted phishing or vishing attempts referencing specific past order details — that's a strong indicator a contact list tied to a specific vendor breach is circulating.
Prevention: Third-Party Data Retention Controls
For teams managing vendor risk, this case argues for moving past "get it in writing" toward verifiable controls:
- Independent deletion verification — Don't rely solely on vendor attestation letters. Where contractually feasible, request audit logs, database record counts, or third-party audit confirmation of data purges tied to your retention policy.
- Contractual retention SLAs with teeth — Build periodic verification rights into fulfillment and logistics contracts, not just a one-time deletion clause.
- Scope BI tools in vendor security assessments — Analytics platforms like Metabase often sit outside the primary security review because they're seen as "internal reporting," yet they frequently have broad read access to production customer data.
- Data minimization at the source — The strongest fix is architectural: solutions like locker-based delivery with automatic identifier deletion (as Trezor is now pursuing) reduce the blast radius by never letting the sensitive linkage exist in a third-party system for long in the first place.
Expert Tips
- If you're a Trezor customer, only trust breach communication from help@trezor.io — Trezor has stated anyone who did not receive that email is not part of the affected dataset. Verify any "urgent" request for personal data or a recovery seed exclusively through official Trezor channels.
- Never enter a wallet recovery seed into a website, app, or in response to a phone call or email — no legitimate Trezor communication will ever ask for it.
- If you placed a Trezor order between November 2019 and August 2021 or between May and August 2026, assume your contact and shipping details may be exposed and increase scrutiny on unsolicited "support" contact for the next several months.
Related Cybersecurity Topics You Should Explore
- Microsoft Teams QR Code Protection: What Changes in October 2026
- Dahua Camera Backdoor Survives Password Resets and Factory Resets
- Is Your Driver's License for Sale? 153 Million Records Leaked, FBI Investigates
- QR Code Phishing Just Hit Record Levels: What SOCs Must Know Now
- Microsoft Teams Won't Load? Inside the TM1466820 Windows Bug
- Why Ad Networks Get Your Blogger Blog Locked (Fix It Fast)
- The touch Command Trick Attackers Use to Fake File Timestamps
- WordPress Now Uses AI to Catch Security Flaws Before Hackers Do
- Mini Shai-Hulud Worm Hits npm Package With 150K Weekly Downloads
- more vs less Linux Commands: The SOC Analyst's Log Review Guide
FAQ
Q: Were Trezor hardware wallets or private keys compromised?
A: No. Trezor has confirmed its own systems were not breached and that no wallet backups, seed phrases, or private keys were exposed in either disclosure.
Q: How many customers are affected in total?
A: Combining the original August disclosure (~13,689 customers) and the September update (~67,000 additional US customers), the total impact is above 80,000 people.
Q: What caused the breach?
A: A critical SQL injection zero-day vulnerability in the Metabase analytics platform used by ShipMonk, which gave attackers administrator-level access to customer order data.
Q: Why did the breach scope grow so much in September?
A: ShipMonk had retained order records from November 2019 to August 2021 despite written assurances to Trezor that this data had been deleted per Trezor's 90-day retention policy. Those older records were included in the compromised dataset.
Q: How do I know if I'm affected?
A: Trezor says all affected customers have been directly emailed from help@trezor.io. If you did not receive that notification, Trezor states you were not part of the exposed dataset.
Q: What should affected customers do now?
A: Treat unsolicited calls, emails, or letters referencing your Trezor order as potentially hostile, verify anything through official Trezor channels only, and never share or enter a wallet recovery seed anywhere.
Conclusion
The Trezor-ShipMonk breach is a reminder that vendor risk doesn't end when a contract clause says "data will be deleted." It ends when you can prove it was. Trezor's core security architecture held up exactly as designed — but a paper-based assurance from a fulfillment partner turned a 13,689-person incident into an 80,000-person one, almost overnight.
For every SOC and GRC team reading this: if your vendor risk program treats a signed attestation as equivalent to verified deletion, this is the incident that should get that assumption re-examined this quarter.
What's your organization doing to verify — not just request — data deletion from fulfillment and logistics vendors? Drop your approach in the comments.
Analysis based on SOC monitoring and public threat intelligence review.