Three vendor failures in four weeks. That is the number that should stop you, not the phishing email itself.
On a quiet September morning, a subscriber to Trezor's newsletter opened a message carrying a legitimate-looking sending domain, a genuine company template, and a subject line warning of an "STM32 Entropy Vulnerability" affecting their device. The message asked them to verify their recovery phrase on a linked portal. Some clicked. Some typed. The device in their pocket was never touched.
Here is the anomaly that deserves our attention: the hardware was never compromised. The firmware was never signed with a malicious payload. The STM32 microcontroller inside every Trezor — the same STM32 family that has anchored these devices for a decade — was functioning exactly as designed. And yet this may be the most serious security event to hit the self-custody category this quarter, because the breach did not occur at the silicon. It occurred two layers up, in the email service provider that Trezor relies on to reach its own customers.
Tracing the hidden vulnerabilities in the code is often a waste of time when the vulnerability lives in the supply chain. This is the lesson I want to unpack slowly, because the instinct to look at firmware is precisely what the attacker exploited.
Context: What Actually Broke
For readers less familiar with the mechanics: a hardware wallet is a small computer whose only real job is to keep a private key isolated from the internet. Trezor, manufactured by Satoshi Labs in Prague, is one of the oldest and most audited devices in the category. Its STM32 chip is a general-purpose ARM microcontroller — well-documented, widely used, and the subject of public security research for years. When attackers fabricated an "STM32 entropy vulnerability," they picked a component users have heard of but rarely understand.
Entropy is the randomness that seeds your recovery phrase. If entropy is weak, your phrase becomes predictable, and predictable keys can be brute-forced. There is real history here — the 2013 Android SecureRandom bug that produced colliding Bitcoin keys, and the 2016 Railgun wallet failure. So the attack narrative was not invented from nothing. It was designed around a genuine, verifiable technical fear.
What actually happened was less exotic. Trezor's third-party email service provider was breached. An attacker obtained control sufficient to send messages through infrastructure that carried legitimate domain authentication. The phishing template mimicked Trezor's official voice closely enough that even users who know what a recovery phrase should never do had to think twice.
This was the third such event in roughly four weeks. Before this, a logistics partner, ShipMonk, leaked names, phone numbers, home addresses, and order details for roughly 80,000 users — information that surfaced into scam calls and physical letters. Earlier in 2024, a support portal exposed records affecting some 66,000 users. The pattern is not coincidence; it is a supply surface that has never been hardened.
Core: The Attack Chain, Deconstructed
Let me walk through the mechanics the way I would in an audit report, because the design of this campaign reveals intent.
The attacker needed four things: a sending domain that authenticated, a template indistinguishable from the real thing, a target list, and a narrative that suppressed rational verification. The first two are the technical heavy lifting. Standard email authentication relies on SPF, DKIM, and DMARC — records that let a receiving mail server verify that a message genuinely originated from the claimed domain. When an attacker gains access to the legitimate sending infrastructure, those checks pass. The message is, cryptographically speaking, from Trezor. This is the point most defenders miss.
I have spent enough time inside security reviews to know that "verify the sender" is the advice that dies first. When the sender is genuinely verified, advice becomes useless.
The target list came from the ShipMonk exposure. The narrative came from the STM32-entropy framing. And the framing is where the campaign earns its sophistication. Consider what the attacker gained by avoiding the usual "you have won an airdrop" bait:
- They referenced a real chip in the user's device, establishing immediate relevance.
- They invoked entropy — a concept that sounds fundamental, technical, and alarming without being fully graspable.
- They triggered a response that bypasses caution: is my money in danger right now?
The information asymmetry is the weapon. A user who half-understands entropy is more vulnerable than one who understands nothing, because half-knowledge converts directly into fear. Fear converts into clicking.
Now, let me be precise about what the attacker could and could not do, because the risk matrix is where panic usually replaces analysis.
| Attack Vector | Target | Success Rate | Cost | Present in This Event | |---|---|---|---|---| | Supply-chain data leak + targeted phishing | Recovery phrase | Medium-High | Low-Medium | Yes — direct | | Physical/silicon attack on the device | Private key | Very Low | Very High | Only as phishing narrative | | Transaction interception/replacement | Destination address | Low | Medium | Marginal | | Social media impersonation of support | Recovery phrase | Medium | Low | Indirect | | Untargeted mass phishing | Recovery phrase | Very Low | Very Low | No |
The row that matters is the first. Combining a real name, a real device model, a real order record, and a legitimately authenticated email produces something far more dangerous than any firmware flaw. This is why the STM32 chip was never the threat — it was the costume.
There is a second, quieter component that concerns me more than the phishing wave itself. The ShipMonk exposure did not only leak email addresses. It leaked home addresses and phone numbers. When you combine those with email access, you enable a follow-up phase the industry has not yet fully confronted: physical correspondence, phone calls, and in-person social engineering dressed as official support. The phishing email is phase one. It is loud. The dangerous variant is phase two, executed months later against users with large holdings, when public attention has moved on.
I have seen this pattern before, in my work reviewing liquidation engines during the 2018 MakerDAO audit. The most damaging exploits were never the ones that fired the first shot loudly. They were the slow, patient setups that waited for volatility and attention to peak elsewhere. Attackers here are behaving the same way: the data leak is the setup, not the strike.
It is worth noting, too, that BitBox suffered a similar newsletter provider breach, and SafePal leaked roughly 40,000 records last month. When multiple competing hardware vendors are hit through the same category of third-party service, we are not looking at isolated bad luck. We are looking at a shared structural weakness — vendors who sell trust as their product, yet outsource the layers that carry that trust.
Quietly securing the layers beneath the hype is the work that was skipped.
Contrarian: The Blind Spot Nobody Is Naming
The conventional reading of this event is that Trezor "got hacked." The contrarian reading — and the more accurate one — is that Trezor's device security worked exactly as intended, and that is precisely why the failure is more instructive.
We have spent a decade telling users that hardware is the answer: not your keys, not your coins, so buy the device and sleep well. That narrative was correct, and remains correct, at the level of the device. But this event exposes the fault line beneath the slogan. The device protects the key. The company protects the context around the key — the emails you trust, the shipping you await, the support you call. The attacker did not need to break the vault. They only needed to impersonate the person with the key to the vault.
This is where the industry's defensive posture has quietly inverted. Redefining what ownership means in the digital age requires acknowledging that custody now extends beyond the silicon to every vendor in the trust chain. The device is the anchor. The chain is the vulnerability.
The blind spot is this: organizations have gotten very good at auditing code and firmware (Trezor's is open and has been reviewed publicly many times) while treating marketing email, logistics, and support tooling as administrative overhead rather than attack surface. Those categories carry user data. User data is the raw material of social engineering. And social engineering, as every honest auditor knows, is the attack that no cryptographic control can stop.
There is a further uncomfortable point. The fact that attackers could authenticate through legitimate infrastructure means that even technically literate users — the ones who know better — were placed in a position where the usual verification heuristics failed. That is not a user error problem. It is a design problem at the organizational boundary.
Takeaway: A Vulnerability Forecast
What should we expect next? The phishing wave will pass. The data, however, will not. The 80,000 leaked records create a multi-month reservoir for later targeting, and the most sophisticated attempts likely have not occurred yet. I would watch for follow-up phone calls and physical mail impersonating official support, aimed at users who hold meaningful balance and who have grown complacent after the initial noise subsides.
The forward-looking question is not whether your device is secure. It almost certainly is. The question is whether the institution behind it has extended its security perimeter to cover the emails it sends you, the boxes it ships you, and the calls it might place to you — or whether it is still defending only the silicon while trusting everything around it on faith.
Building trust through rigorous, unseen diligence is now a supply-chain discipline, not a firmware checklist. Own your keys. Distrust your inbox.