Trezor Phishing Scam: The Fake Alert Explained

On the morning of September 9, 2026, subscribers on Trezor's own mailing list opened an email that turned out to be the opening move of a Trezor phishing email breach with the subject line "Critical Security Alert: STM32 Entropy Vulnerability." The message looked exactly like every other security bulletin Trezor had ever sent them. It came from Trezor's real sending address. It carried valid SPF, DKIM, and DMARC records, the technical signatures that email clients use to decide whether a message actually came from who it claims to be from. It warned that a hardware flaw could expose recovery phrases and pointed recipients to a "verification tool" to check whether their wallet was affected. Users at BitBox, a separate Swiss hardware wallet maker, received a nearly identical email around the same time. Neither company had sent it.

What Actually Happened in the Trezor Phishing Email Breach

The emails did not come from a break-in at Trezor or BitBox themselves. They came from Brevo, the third-party email marketing platform, formerly known as Sendinblue, that both companies use to reach their own subscriber lists, along with at least one other firm, the crypto tax service CoinTracking. Attackers compromised Brevo's infrastructure and used it to send messages through the companies' own legitimate delivery pipelines. That is why the emails passed every standard authentication check a recipient's inbox would normally run. The vulnerability described in the email, a supposed flaw in the STM32 microcontroller's random number generation, does not exist. Bitcoin security researcher and Casa chief security officer Jameson Lopp was among the first to flag the pattern publicly, noting that the email provider used by both Trezor and BitBox appeared to have been compromised and that no legitimate security advisory matching the email's claims had been issued by either company.

Why the Trezor Phishing Email Breach Was So Hard to Catch

A normal phishing email is easy to catch because something about it looks off: a strange sending address, a broken link, a domain that is almost but not quite the real one. This one had none of those tells. It came from Trezor's actual infrastructure, addressed to people who had genuinely signed up for Trezor's own updates, formatted the way Trezor's own security notices are formatted. The "verification tool" the email linked to was built to harvest a wallet's recovery phrase from anyone who trusted the alert enough to follow its instructions and enter one. A recovery phrase is not a password that can be reset. Anyone who typed theirs into that page handed over full control of every asset the phrase protects, permanently, the moment they hit submit.

What Trezor and BitBox Did Next

Both companies moved quickly once the pattern was identified. Trezor confirmed the breach publicly and told users directly that the STM32 entropy warning was fabricated, that no firmware or hardware issue of that kind exists, and that any email asking someone to enter a recovery phrase into a web page should be treated as fraudulent by default. BitBox issued a parallel warning to its own subscriber base. Neither company's hardware or firmware was compromised. The breach lived entirely in the marketing layer sitting on top of otherwise unaffected products, which is exactly what made it so difficult for an ordinary recipient to catch on sight.

Back to the Inbox

Picture the same moment again, now with the full picture in hand. The email still arrives looking flawless: real sending address, real formatting, real authentication headers. What changes is what a recipient does next. Instead of clicking through to a page that asks for a recovery phrase, the move is to close the email entirely and go check the company's own official channel, its verified account on X, its own support site typed in directly rather than clicked from a link, for whether the alert is real. A hardware wallet manufacturer will never legitimately need a customer's recovery phrase to fix a firmware issue. No verification tool that asks for one, no matter how convincing the email that sent you there, should ever get it. That is the one fact this entire incident turns on, and it holds regardless of how good the next version of this scam looks.

This incident is a reminder of a wider point that matters beyond hardware wallets specifically: infrastructure a company depends on but does not fully control, in this case a third-party email vendor, can become the weak point even when a product itself is secure. NexusPool's own approach to that kind of trust gap is to minimize what a miner has to take on faith in the first place. A block a NexusPool miner finds pays out through the coinbase transaction directly to the miner's own address, with 0% pool fee, across Bitcoin, Litecoin, Dogecoin, and Bitcoin Cash, nothing held in an account that could be phished, drained, or socially engineered after the fact. The signed, offline-checkable receipts behind that design are documented on NexusPool's Glass Ledger page, and anyone who wants to see exactly how a payout gets checked before a block is even found can review NexusPool's Payout Preflight tool. The wider architecture that keeps a miner's coins out of any pool-held account in the first place is set out on NexusPool's technology page. This is not a claim that NexusPool is immune to every category of phishing or social engineering risk that exists, and it is not a claim about the odds of finding a block, which are set entirely by network difficulty relative to a miner's own hashrate and identical for every miner on a given chain. It is not investment advice, and it is not a claim that NexusPool's own core software is open source or public today. For the full account of the breach and both companies' response, see Decrypt's reporting on the Trezor and BitBox phishing incident.

Trust nothing. Verify a wallet security alert through the company's own official channel before you ever type a recovery phrase anywhere.