The Hardware Wallet Held. The Shipping List Didn't.

Trezor disclosed a breach affecting 13,689 customers on August 13, 2026. Its own systems and devices were not compromised. Its fulfillment partner's were.

ShipMonk, Trezor's shipping and logistics provider, informed the company on August 10 that an unauthorized party had accessed systems containing customer order data. 11,742 customers had full exposure — name, email, phone number, and shipping address. Another 1,947 had partial exposure: name, city, and email.

The affected orders shipped between May 10 and August 8, 2026, to customers in the United States, United Kingdom, Sweden, Colombia, Brazil, Italy, and Portugal.

The root cause was a SQL injection zero-day in Metabase, the open-source business intelligence tool, used to gain administrative access to ShipMonk's instance.

The threat model was inverted

Hardware wallets exist to solve one problem: keeping private keys off internet-connected devices. Trezor's product did that. Nothing about this breach touched a key, a seed phrase, or a device.

What leaked is arguably worse for the specific population affected, because it defeats a different assumption entirely.

A cold-storage wallet protects against remote compromise. It does not protect against someone knowing your name, your phone number, and where you live — and knowing, with high confidence, that you own crypto. A shipping manifest from a hardware wallet vendor is precisely that list, and it is more reliable than any inference an attacker could draw from on-chain analysis or social media.

The device secures the key against the network. The order record identifies the human holding it.

Wrench attacks are the reason this matters

The relevant risk category is coercion — physically confronting a holder and compelling them to unlock their device.

Hardware wallets are unusually exposed to this, and the reason is structural. Their security model deliberately removes every intermediary that could reverse a transaction. No custodian to freeze the account, no bank to claw back the transfer, no support line to call. That is the entire value proposition, and it means that once a holder unlocks the device under duress, the outcome is final.

An attacker's hard problems are identification and location. A hardware wallet vendor's shipping list solves both, with delivery confirmation attached.

The timing compounds it. France's tax authority disclosed a breach the same week exposing 678,000 people's names, home addresses, and reference taxable income. Correlating a high-income French taxpayer against a Trezor shipping record is not a sophisticated operation — it is a join on two columns.

Metabase is the actual vector, and it is bigger than Trezor

The vulnerability was not in ShipMonk's code. It was a critical SQL injection zero-day in Metabase, a widely deployed open-source BI tool that thousands of companies point directly at their production databases.

That is the architectural problem. Metabase's purpose is to let non-engineers query operational data, which means a Metabase instance sits with broad read access to exactly the tables a company would least like exfiltrated. Administrative access to the instance is close to administrative access to the data warehouse.

Trezor was not the only victim of the campaign. Laptop maker Framework and form builder Tally were caught in the same exploitation of the same flaw. Metabase has since patched the vulnerability and invalidated active sessions.

One zero-day in one internal analytics tool produced breaches at a hardware wallet vendor, a laptop manufacturer, and a SaaS form product — three companies with nothing in common except a dependency they almost certainly never listed in a threat model.

The vendor chain is where the security budget isn't

Trezor is a security company. It employs people who think about adversaries for a living, publishes its firmware, and has an established relationship with the security research community.

None of that helped, because the compromise was two hops away: Trezor → ShipMonk → Metabase.

Every e-commerce operation has this shape. Order data must reach the fulfillment provider or nothing ships. The fulfillment provider has its own internal tooling, its own vendors, and its own security posture — and the customer of that provider has essentially no visibility into any of it. Contractual security requirements are audits of paperwork, not of a running Metabase instance.

The asymmetry is that Trezor absorbs the reputational damage for a decision made inside a company it does not control, using software it did not choose. Customers do not distinguish between "Trezor was breached" and "Trezor's logistics provider's analytics tool was breached." The headline is the same.

The read

Three things follow.

The affected customers should treat this as permanent. Names and home addresses do not rotate. Every one of the 13,689 should assume they are on a list identifying them as a crypto holder, treat unsolicited contact referencing their order as hostile, and consider whether their physical security assumptions were built on the belief that nobody knew.

Phishing is the near-term risk; coercion is the tail risk. A convincing message referencing a real order, a real delivery date, and a real address will fool people who would ignore a generic one. The standard defense holds absolutely: a seed phrase is never entered anywhere except the device, and no legitimate party ever asks for it. The tail risk is smaller in probability and far worse in outcome, and it is the reason this breach is not comparable to an ordinary retailer losing a customer list.

And the lesson generalizes past crypto. Any company whose customer list is itself sensitive — hardware wallets, firearms, medical devices, security products — has to treat fulfillment as part of the security perimeter, because the shipping manifest is the sensitive data. Trezor built a device that keeps keys off the internet, then handed a list of everyone who bought one to a third party running an unpatched analytics tool.

The device worked exactly as designed. That was never the part under attack.