Trezor's ShipMonk breach: retention policy capped the damage

Two days ago we wrote that your 3PL sits inside your data perimeter and told you to audit how long each vendor keeps your customer records. Here is what it looks like when a company actually did that work in advance. Trezor disclosed a breach at its fulfillment partner ShipMonk that exposed 13,689 customers — and the exposure window stops dead at 90 days, because Trezor's contract required the partner to delete the data.

What actually happened

ShipMonk told Trezor on August 10 that an unauthorized party had reached systems holding customer data. Trezor disclosed publicly on August 13. Per Trezor's own notice, 11,742 customers had full records exposed — name, email address, phone number, shipping address — and another 1,947 had partial records: name, city, email. Affected customers were in the US, UK, Sweden, Colombia, Brazil, Italy, and Portugal.

The entry point was not Trezor and not ShipMonk's own code. It was CVE-2026-72898, an unauthenticated SQL injection in Metabase reachable through the password-reset endpoint, scored CVSS 10.0. Metabase published its advisory on August 6; CISA added the bug to the Known Exploited Vulnerabilities catalog on August 11. The same zero-day was used to reach customer data at Framework and other companies, per Help Net Security. ShipMonk says the vendor has patched and invalidated all active sessions, per BleepingComputer.

Now the part worth copying. The exposed orders run from May 10 to August 8, 2026 — roughly 90 days. That is not luck. Trezor requires fulfillment partners to delete or anonymize purchase data within 90 days of delivery, which it describes as the shortest window that still covers delivery, returns, and any refund or replacement. Everything older was already gone when the attacker arrived.

Why data retention is a security control, not a compliance chore

Most operators treat retention as paperwork for the privacy policy. It is actually the one control that works after every other control has failed. You cannot patch your vendor's BI tool. You cannot force their session hygiene. You can decide how many rows are sitting there when someone else's zero-day lands.

Trezor's blast radius was one quarter of orders. A company with the same breach and no deletion clause hands over every address it has ever shipped to.

Three moves, in order of how fast you can do them:

Pick a number and write it into the contract. Not "as needed." A count of days, tied to delivery, with anonymization as the fallback when a record has to persist for accounting. Ninety days is a defensible starting point because it survives a return window.

Verify the deletion instead of trusting it. Ask your 3PL to export everything they hold on a customer who ordered five months ago. If a record comes back, your clause is decorative.

Assume the phishing wave. Names plus phone numbers plus shipping addresses is a social-engineering kit, and it stays useful long after the systems are patched. Trezor's advice to its customers is the right template: be suspicious of anything that pressures you to act immediately, and never enter recovery material anywhere. Send that email yourself before someone else sends a convincing fake of it.

The pattern here is the one we keep coming back to. The systems holding your customer relationship should be ones you can inspect, limit, and expire on a schedule you set.

Sources: Trezor, BleepingComputer, CISA, Help Net Security.