Trezor ShipMonk Breach: Never Put Your Wallet Backup Online

Trezor says a breach at ShipMonk, one of its shipping providers, exposed personal order data belonging to approximately 13,689 customers. The incident did not compromise Trezor's systems, hardware wallets, private keys or wallet backups, according to the company. The immediate risk is different: attackers can combine real identity and delivery details to make a phishing message, phone call or physical letter unusually convincing.

This distinction matters. A leaked address does not give an attacker control of a wallet, but it can tell them who may own one and help them construct a believable path to the only secret that matters: the wallet backup. That backup must never be entered on a website or shared with anyone—including through an encrypted sharing service.

What Trezor confirms

Trezor says ShipMonk notified it on August 10 of unauthorized access to systems containing customer data. The company divides the affected population into two groups: 11,742 customers whose names, email addresses, phone numbers and shipping addresses were exposed, and 1,947 customers whose names, cities and email addresses were exposed. That produces the published total of approximately 13,689 affected customers.

The notice names the United States, United Kingdom, Sweden, Colombia, Brazil, Italy and Portugal. For the fully exposed group, Trezor describes customers who received an order between May 10 and August 8, 2026. It says affected customers were contacted directly from help@trezor.io.

Trezor says its products and services continue to operate normally and that no Trezor device was affected. The public notice does not report exposure of wallet backups, private keys, passwords, PINs, payment-card data or wallet balances.

An important update to the 90-day boundary

Trezor requires order data to be deleted or anonymized 90 days after delivery and says it negotiated the same retention period with fulfillment partners. That policy limited the amount of current shipping data available in ShipMonk's environment.

However, Trezor's current notice adds a caveat: the 1,947 customers with partial exposure may include older orders. The company says it is verifying the exact timeframe with ShipMonk. It would therefore be inaccurate to claim that every affected record was definitely created during the 90 days before August 8.

This does not invalidate data minimization. It shows why a retention clause needs operational evidence: deletion or anonymization should be testable across production systems, analytics platforms, exports, backups and downstream processors—not assumed from policy wording alone.

What independent reporting adds

BleepingComputer independently reviewed breach-notification material and corroborated Trezor's affected counts, countries and exposed data categories. It reports that a ShipMonk notification attributed the access to exploitation of a vulnerability in a third-party analytics platform, Metabase. It also reports that ShipMonk received extortion emails associated with ShinyHunters.

Those details are reporting, not conclusions published in Trezor's incident notice. Trezor says the investigation remains ongoing and does not publicly attribute the incident to a named group. The full access path, dwell time, affected ShipMonk systems and whether the extortion claim reflects the same actor remain unconfirmed publicly.

Why shipping data creates a high-quality phishing pretext

An attacker who knows a customer's name, address, phone number, email and relationship with Trezor can impersonate support with details that feel private. A message might claim that the device is vulnerable, that a replacement must be activated, that the wallet needs to be “verified,” or that funds must be moved immediately.

The attacker may use several channels at once: an email followed by a phone call, a text message that references the delivery address, or even a letter with a QR code. None of those details authenticate the sender. They are leaked context, not proof of authority.

The non-negotiable rule: never digitize or share the wallet backup

A wallet backup—often called a recovery seed or recovery phrase—is not an ordinary password. Anyone who obtains it may be able to recreate the wallet and control its assets. It should remain offline and physically protected according to the wallet vendor's official guidance.

Never enter the backup on a website, even one that appears to be Trezor.
Never read it to a caller or type it into chat, email, a support ticket or a form.
Never photograph, scan or store it in cloud notes or online password fields.
Never use Secretus—or any other transfer service—to send a wallet backup.
Only follow the official, model-specific recovery workflow that you initiated through Trezor Suite and your device; never follow recovery steps supplied by an unsolicited caller or website.

If someone asks for the backup, stop. Do not continue the conversation, click a supplied link or scan a QR code. Open a fresh browser session, type trezor.io yourself and use the support path published there.

What affected customers should do

Read the notice through an official path. Navigate directly to Trezor's website or verified channels rather than following an unexpected email link.
Expect personalized contact. Treat knowledge of your order, address or phone number as compromised context, not identity verification.
Keep the wallet backup offline. No legitimate breach response requires you to reveal it, “validate” it online or move funds to a support wallet.
Do not reset a secure device because of the shipping breach alone. Trezor says its devices, systems and wallet secrets were not affected. Follow official guidance if that assessment changes.
Secure adjacent accounts. Use a unique password and phishing-resistant MFA for the email account that received the order notification, and protect your mobile account against unauthorized SIM changes.
Preserve suspicious messages safely. Report them through Trezor's official support route without replying or exposing additional personal information.
Consider physical privacy. Because some shipping addresses were exposed, avoid discussing wallet ownership with unexpected visitors or callers and review how future hardware is delivered.

The vendor lesson: minimize data and verify deletion

Trezor's 90-day retention policy is one reason this incident did not expose an unlimited history of full shipping records. Organizations that ship sensitive products should adopt the same principle, then test whether it survives the vendor chain.

Collect only the fields required to deliver and support the order.
Set field-level retention periods instead of retaining the entire order indefinitely.
Require deletion or anonymization across analytics, support, backups and subprocessors.
Ask vendors for evidence of deletion jobs, exceptions, failures and restore behavior.
Keep payment data, account credentials and support secrets outside fulfillment exports.
Design notification templates before an incident so customers can distinguish guidance from a phishing lure.

Where one-time secret sharing does—and does not—fit

Not every secret should be shared. A wallet backup belongs in the “never transfer” category. Secretus is intended for ad-hoc operational values that another authorized person genuinely needs—such as a temporary password, scoped API token or recovery code used during an incident—and can reduce the plaintext copies left in email or chat.

It cannot make an inappropriate transfer safe, protect a compromised endpoint or undo a disclosure. The first control is deciding whether the recipient should receive the secret at all. For a hardware-wallet backup, the answer is no.