## The Trezor Breach That Grew 6x Because of a Broken Vendor Promise
If you follow supply-chain and vendor risk incidents, this one is worth a technical breakdown — not just a headline skim.
TL;DR
On September 4, 2026, Trezor confirmed that a breach at fulfillment partner ShipMonk now affects 80,000+ US customers — up from the ~13,689 originally disclosed on August 13. The root cause: a critical SQL injection zero-day in Metabase, the BI/analytics tool ShipMonk used to query customer order data.
Trezor's hardware wallets, seed phrases, and private keys were not compromised. This was a contact-data exposure via a third-party vendor's analytics layer — not a cryptographic failure.
Attack Chain (MITRE ATT&CK mapped)
- Initial Access — T1190, Exploit Public-Facing Application (Metabase SQLi)
- Privilege Escalation — T1068, reaching admin-level access on the Metabase instance
- Collection/Exfiltration — direct DB querying through the compromised BI layer
Other companies (Framework, Tally) disclosed similar Metabase-linked breaches around the same window — this looks like a broader campaign, not a Trezor/ShipMonk-specific attack.
The part that actually matters for engineers and SOC teams
Trezor's original disclosure was scoped around a 90-day data retention policy. Trezor said it had repeatedly requested — and received — written confirmation from ShipMonk that data older than 90 days had been deleted.
It hadn't been. Records dating back to November 2019 — nearly 5 years past expiration — were still live in ShipMonk's systems when the Metabase compromise happened.
This is the real lesson: a signed attestation is not equivalent to an audited deletion log. If your team manages vendor risk, "get it in writing" doesn't scale as a control — you need independent verification (audit logs, record counts, third-party confirmation).
If you run Metabase internally or through a vendor
- Confirm you're patched against the Aug 2026 Metabase SQLi zero-day, and that sessions were invalidated, not just blocked going forward
- Audit admin-level access logs on BI/analytics tools sitting in front of PII — these are chronically under-monitored vs. production DBs
- If a vendor breach mentions SQL injection as entry vector, treat your BI layer as in-scope for investigation too
Full technical writeup with the complete timeline, exposed data breakdown, and prevention controls:
🔗 https://www.xpert4cyber.com/2026/09/trezor-shipmonk-data-breach-67000-exposed.html
What's your team's actual process for verifying vendor data deletion — not just requesting it? Curious how others are handling this.
Top comments (0)