The incident was disclosed by Trezor on August 13 after ShipMonk reported unauthorized system access on August 10. The submitted report correctly identifies the most important practical consequence — criminals can now use delivery details to make scams look credible — but it overstates several details that Trezor has not publicly established, including the alleged Metabase zero-day and a definitive May 10-to-August 8 cutoff for everyone affected.
For Windows users who manage crypto through Trezor Suite, the immediate danger is not a remote compromise of a connected device. It is a tailored message, phone call, or fake desktop update that persuades an owner to surrender the one secret that can empty a wallet: the recovery seed.
What Trezor says ShipMonk exposed
Trezor’s public notice says ShipMonk held the information necessary to fulfill orders: name, email address, order number, phone number, and shipping address. It says 11,742 customers experienced full exposure, while 1,947 had a narrower exposure of name, city, and email address. The company says it contacted affected people individually from its official support address.
The affected customers are in the United States, United Kingdom, Sweden, Colombia, Brazil, Italy, and Portugal. Trezor’s own shipping documentation independently confirms that ShipMonk operates fulfillment locations for U.S., U.K., Swedish, Italian, Portuguese, and Colombian orders, making the geographic list consistent with its current logistics setup.
Trezor also says orders placed through its official Amazon storefronts were handled by a different fulfillment partner and were not involved. That is a useful exclusion, but customers should not treat a lack of an email as proof that every historical Trezor-related record is safe; it means only that Trezor did not identify their details in this incident.
The company attributes the limited reach of the breach to a 90-day retention arrangement with ShipMonk. Older fulfillment records were supposed to have been deleted or anonymized before the intrusion. This may have reduced the number of full-address records available to the attacker, but it did not prevent recent buyers from being exposed in a particularly sensitive category of data.
The reported time window is less settled than it first appeared
The commonly repeated claim that all victims received orders from May 10 through August 8 is incomplete. Trezor initially described the group as people who received orders within the 90 days before August 8. That roughly corresponds to the May 10 date cited in the submitted report for the full-exposure group.
However, Trezor representatives later said that the 1,947 customers whose exposure was limited to name, city, and email address may include older orders, and that the company was verifying the exact timeframe with ShipMonk. In other words, the 90-day period is a reliable working boundary for the detailed delivery-address exposure, but it is not yet a final universal cutoff for every partially exposed customer.
That distinction matters for incident response. A customer who bought a Trezor before May 10 should not assume their information could not have appeared in the smaller, partial-data set. Trezor’s clearest practical criterion is whether the customer received its breach-notification email.
There is also no public evidence supporting the submitted article’s assertion that an exploited Metabase zero-day caused the breach. Trezor has described unauthorized access to ShipMonk’s systems and said the investigation remains ongoing; it has not publicly named Metabase, identified a CVE, or published a technical root-cause analysis. Readers should not turn an unverified explanation into an assumed fact.
Trezor’s public status page also listed no service incidents for August, which illustrates a common reporting problem with third-party data breaches: a vendor’s uptime status is not a complete security record. Trezor Suite and Trezor devices may have remained operational even as customer delivery data held by a partner was exposed.
Why an address breach changes the threat model
A normal email-address leak feeds bulk spam. This incident potentially gives a fraudster a package of details that can be used to impersonate Trezor support, a courier, a bank, a tax agency, or a cryptocurrency exchange. An authentic order number — if exposed as Trezor says — would make a message or call more convincing still.
The available disclosures do not establish that the attackers obtained a product name, wallet balances, a recovery phrase, or a verified mapping from each home address to cryptocurrency holdings. That missing detail is important. A ShipMonk fulfillment record may identify a shipment without explicitly identifying the contents to whoever accessed the data.
But Trezor customers should plan for attackers to infer the connection anyway. A delivery contact record paired with a Trezor-themed email lure does not need a balance estimate to produce a successful fraud attempt. The attacker only needs one recipient to enter a seed phrase into a counterfeit page, install a trojanized “Trezor Suite” update, or approve a malicious transaction.
BleepingComputer’s reporting on Trezor’s 2024 third-party support breach shows why the warning is more than theoretical. In that earlier incident, Trezor confirmed phishing attempts that tried to collect recovery seeds under the pretext of support or firmware validation. A customer’s seed phrase is sufficient to restore the wallet elsewhere and move assets; the hardware wallet’s security protections cannot reverse that disclosure.
The risk therefore sits at the intersection of physical identity and Windows endpoint security. A hardware wallet protects private-key operations from malware on a PC far better than a browser extension or a software-only wallet can. It cannot protect a user who is tricked into importing the recovery phrase into a malicious Windows application or a fake web portal.
What affected Trezor owners should do now
The right first response is to harden against impersonation rather than reset a working Trezor in a panic. The device itself does not need replacement solely because ShipMonk’s customer records were accessed, and generating a new seed carelessly can create a worse loss scenario.
Affected customers should take the following steps:
- Treat any unexpected email, text, direct message, or call referring to a Trezor order as hostile, even when it contains an accurate address, telephone number, or order detail.
- Never type a Trezor recovery seed into Trezor Suite on Windows, a web page, a document, a chat window, or an alleged support form. A legitimate support agent has no reason to request it.
- Do not install an update received through an email link, attachment, or search advertisement. Open Trezor Suite directly from an existing trusted installation, or manually navigate to Trezor’s official site before downloading anything.
- Verify transactions on the hardware device’s screen. A connected Windows PC can display misleading destination addresses or prompts if it is compromised; the device screen is the final place to confirm what will be signed.
- Change the email password used for Trezor communications if it is reused anywhere else, enable multifactor authentication on that email account, and consider using a dedicated address for future financial-service communications.
- Alert other people in the household that a convincing parcel-delivery or “account verification” scam may arrive. The breach makes social engineering against family members more plausible, not only against the person who placed the order.
Users with substantial holdings should also review their personal exposure beyond Trezor. The core question is not whether a criminal can prove a wallet’s balance from this leak; it is whether the combination of home address, phone number, and a likely crypto association could make the household a more attractive target for scams or coercion.
Hardware wallets remain useful, but fulfillment is part of security
The response from Binance founder Changpeng Zhao — that software self-custody avoids shipping-address exposure — identifies a genuine trade-off, but it is not a verdict that software wallets are safer overall. Software-only wallets remove the logistics data trail created by a mailed device, while placing more responsibility on the security of the user’s Windows PC, browser, mobile device, and backup practices.
Hardware wallets retain a clear purpose: they isolate signing keys from the general-purpose computer that connects to the internet. For a user facing malware, clipboard hijackers, malicious browser extensions, or credential-stealing Windows software, that separation is meaningful. The ShipMonk breach exposes a different weakness: the vendor’s purchase and fulfillment chain can reveal information the device was designed to keep secret.
Trezor says it is working on more anonymous purchasing options, but it has not announced what those options will be, when they will arrive, or whether they will apply across all fulfillment regions. Until then, buyers should understand that a wallet’s security model starts before it is powered on. It includes the storefront account, payment trail, delivery address, email account, and every logistics company that touches the order.
