BLOCKCHAIN AI.NEWS

Security · Supply Chain

Two Wallet Makers, One Newsletter Vendor, and the Same Fake Alert

The phishing email arrived from Trezor's own domain, warning of a critical entropy flaw and urging an urgent device update. BitBox customers received the same warning the same day. BitBox's preliminary read: the newsletter provider is the thing that was breached, and more than one bitcoin company uses it.

Editorial illustration: a single chrome distribution manifold feeding four frosted-glass tubes, each carrying an identical chrome envelope, one of them glowing warm gold
✓ Broken first by The Block (Sep 9) · Also reported by Cointelegraph, Decrypt, Unchained · Lure text and the 25% claim via CryptoPotato · June chip disclosure via CoinDesk

Everything about the email was right except the facts in it. It came from Trezor's real domain. It carried Trezor's signature block. It passed whatever mental check a customer performs before clicking, because there was nothing to fail — the message was genuinely sent through Trezor's mail infrastructure. What it said was invented.

The subject line was "Critical Security Alert: STM32 Entropy Vulnerability." The body claimed that the STM32 microcontrollers inside Trezor devices could generate recovery phrases without sufficient randomness, and that as many as 25% of devices might be affected, per CryptoPotato. Recipients were urged to check whether their device was affected and to update it. Some versions of the message steered users toward pages soliciting wallet information.

Trezor's response, posted to X, was blunt: "Please be aware that the email named 'Critical Security Alert: STM32 Entropy Vulnerability' is not coming from us, and it's a phishing attempt. Do not click on any link." The company said a third-party email provider had been breached, took the associated domain down, and said it was investigating how attackers came to be sending from its own.

The same message, a different brand, the same day

The detail that turns this from a bad day at one company into an industry problem arrived within hours. BitBox, the Swiss hardware wallet maker, warned its own customers about a phishing email impersonating BitBox. Its preliminary review, as reported by Cointelegraph, indicated that its newsletter provider was likely compromised — and that multiple bitcoin companies appeared to have been targeted through a shared provider.

Casa co-founder Nick Neuman flagged the overlap publicly, noting reports of the same messages reaching BitBox users. Bitcoin security engineer Jameson Lopp warned that threat actors "may have compromised the email provider(s) used by Trezor and BitBox," per Decrypt.

Neither company has named the provider. Decrypt notes that one user's inspection of the message headers referenced Sendinblue campaign metadata, which would point at the platform now trading as Brevo; that is a single unverified reading of an email header and this desk treats it as unconfirmed. Cointelegraph says it approached both Trezor and BitBox and had no response before publication. The honest state of the record is that two hardware wallet companies believe a mail vendor they have in common was breached, and neither has said which one.

The lure named the wrong chip

The most instructive thing in the fake alert is a technical mismatch that almost nobody receiving it would have caught.

There was a real chip disclosure this year, and it was serious enough to make headlines. In June, Ledger's in-house research group Donjon published a laser fault-injection attack against the TROPIC01 secure element used in the Trezor Safe 7, defeating firmware signature verification on the boot and update path. Trezor said at the time that no user funds were at risk: the attack defeats one layer among several and requires physical possession of the device, specialist equipment and expertise, per CoinDesk.

TROPIC01 is a secure element. STM32 is a general-purpose microcontroller family. They are different parts doing different jobs, and the entropy claim in the phishing email — recovery phrases generated with too little randomness — is a different failure class again from what Donjon demonstrated. The lure did not describe June's vulnerability. It described the memory of June's vulnerability: a scary chip, a Trezor device, a reason to touch your wallet.

What the email asserted, against the public record

The email claimed The record says
A critical flaw in STM32 microcontrollersJune's disclosed flaw was in the TROPIC01 secure element, a different component
Recovery phrases generated with insufficient entropyNot a finding in any disclosure this year; Donjon's attack targeted firmware signature verification
As many as 25% of devices affectedNo such figure appears in any published advisory
Update your device via the enclosed linkTrezor: the message is not from us — do not click any link
Lure text per CryptoPotato and The Block; June chip disclosure per CoinDesk; Trezor's warning as posted to X, Sep 9–10, 2026.

Whether that mismatch was carelessness or calculation is not knowable from the outside, and it may not matter. A recipient who half-remembers a June headline about a Trezor chip flaw, and who receives a warning about a Trezor chip flaw from Trezor's own address, is not going to open a datasheet to check which part number is which.

The second vendor breach in a month

This is not the first time in 2026 that Trezor customers have been reached through a company Trezor pays rather than a company Trezor is. In August, the logistics provider ShipMonk disclosed a breach exposing personal data on roughly 80,689 Trezor customers — an initial figure of about 13,700, covering names, cities and email addresses, later expanded by a further 67,000 US customers, with orders reaching back to November 2019.

Line the two up and the shape of the campaign becomes uncomfortable. One breach produced a verified list of people who own hardware wallets, including where they live. A second breach produced the ability to email those people from the manufacturer's own domain. Nobody has demonstrated that the same actors hold both, and neither company has alleged it. But an attacker who did would have the two things phishing normally lacks: a target list with no false positives, and a sender address that no filter will flag.

What the threat model was always missing

The case for a hardware wallet is a case about isolation. Keys are generated on the device, never leave it, and every consequential action requires a physical press on a screen you can read. That argument survives this week intact. No Trezor was compromised. No BitBox was compromised. The devices did exactly what they promise.

What was compromised is the channel through which a manufacturer tells you something is wrong — and there is no secure element for that. The entire security posture of self-custody assumes that when the vendor says "there is a critical flaw, act now," the customer can distinguish that message from an attacker's. Domain authentication was the mechanism doing that work. This week it authenticated the attacker, correctly, because the attacker was inside the machinery that does the signing.

It is also worth noting what made the lure land: the industry has spent two months generating exactly this fear. The Coldcard exploit took more than $130 million from devices whose owners had done nothing wrong. Ledger and Trezor spent August arguing in public about a race condition. The phishing email did not have to invent a world in which hardware wallets have critical flaws and urgent updates. It only had to send a plausible one, from the right address, on a week when readers were primed to believe it.

The Take

Stop treating the marketing stack as a marketing problem. A newsletter platform holding the sending keys for several hardware wallet brands is, functionally, a single point of failure for the trust channel of an entire product category — and it is procured by growth teams, budgeted as software, and secured accordingly. The fix is not user education; a customer who correctly verified the sender still lost this round. The fix is structural: vendors should publish security advisories to a channel they control and customers can independently check, sign them with a key that lives outside the email vendor, and train customers that mail is never the authority. Until then the rule for everyone else is the boring one that keeps working — a real firmware update is never urgent, never arrives by link, and can always wait until you have opened the vendor's site yourself and typed the address by hand.

More on the subject