September 7, 2026
Trezor’s Wallets Were Never Hacked. Here’s Why 80,000+ Customers Got Exposed Anyway
Trezor’s Wallets Were Never Hacked. Here’s Why 80,000+ Customers Got Exposed Anyway.

By Xpert4Cyber
1 min read
If you own a Trezor hardware wallet, this is the breach you need to actually read — not skim.
On September 4, 2026, Trezor confirmed that a breach at its fulfillment partner ShipMonk now impacts over 80,000 US customers — six times larger than the ~13,689-person incident disclosed just three weeks earlier on August 13.
The root cause: a critical SQL injection zero-day in Metabase, the analytics platform ShipMonk used to query customer order data. Attackers gained administrator-level access and exfiltrated names, emails, phone numbers, shipping addresses, and order numbers.
But the real story isn't the exploit. It's what happened after.
Trezor's original disclosure was scoped around a 90-day data retention policy — fulfillment partners are contractually required to delete order data 90 days after delivery. Trezor said it repeatedly requested, and received, written confirmation from ShipMonk that older records had been deleted.
They hadn't been. Data dating back to November 2019 — nearly five years past its expiration — was still sitting in ShipMonk's systems when the Metabase compromise occurred.
This is a textbook vendor risk governance failure: a mature security program did everything "right" — contractual mandates, written attestation, documentation — and it still failed, because nobody independently verified the deletion. Written assurance is not an audited deletion log.
Trezor's wallets, seed phrases, and private keys were never touched. But for a crypto-holding customer base, exposed home addresses carry a documented physical security risk beyond typical phishing — a risk Trezor explicitly flagged in its own notice.
In this breakdown, I cover: → The full incident timeline (both disclosure waves) → MITRE ATT&CK mapping of the attack chain → What data was exposed vs. what stayed secure → Why written vendor assurances aren't enough → Detection steps for SOC teams using Metabase → Prevention controls for third-party data retention risk → What affected Trezor customers should do right now
Read the full technical analysis: https://www.xpert4cyber.com/2026/09/trezor-shipmonk-data-breach-67000-exposed.html