One scoping bug, many downstream victims
Brevo, an email marketing platform used by Trezor and other companies for customer newsletters, had a flaw in how it scoped access under its SAML single sign-on feature. According to Brevo's own account of the incident, an attacker created a Brevo account, enabled SSO on it, and then invited legitimate Brevo users into that SSO configuration. The access those invitations granted was supposed to be limited to the single organization where SSO had been enabled. Instead, Brevo confirmed it wrongly granted the attacker access to every organization those invited users could reach, turning a single misconfigured invitation flow into a master key across unrelated customer accounts that had no relationship to each other beyond sharing the same vendor.
The blast radius that produced is the real story here: 138 Brevo accounts were compromised in total, six of them actively abused to send phishing campaigns, and customer contact data was exfiltrated from 43 accounts. This is a textbook example of how a SaaS platform's internal access control bug becomes every one of its customers' incident simultaneously, regardless of how carefully any individual customer configured their own account.
Why crypto wallet makers specifically
Trezor's exposure through this campaign was severe on its own: 347,000 users received phishing emails, using the subject line Critical Security Alert: STM32 Entropy Vulnerability, a plausible-sounding hardware security concern designed to get a security-conscious crypto holder to click. The messages directed recipients to a fake site built to harvest wallet backup phrases, the single piece of information that gives an attacker complete control of a cryptocurrency wallet's funds. Roughly 2,500 users clicked through before the site was taken offline, twenty minutes after detection.
Trezor was not alone. BitBox and CoinTracking, two other companies in the cryptocurrency and hardware wallet space, were targeted through the same Brevo compromise. That pattern, three companies in the same narrow niche hit through one shared vendor, is a strong signal this was a targeted campaign against the crypto hardware wallet ecosystem specifically, not an opportunistic attacker who happened to compromise a marketing platform and phished whoever was on the list.
The second hit in a month is the part that should worry Trezor's board
This Brevo incident lands less than a month after Trezor disclosed a separate breach at shipping provider ShipMonk, which exposed data on more than 67,000 additional US customers. Two vendor-linked exposures inside one month deserves scrutiny well beyond treating it as bad luck. It is a pattern that points toward Trezor's own vendor risk management, not just the vendors themselves, as a meaningful part of the underlying problem, since both incidents trace back to trusting a third party with sensitive customer data without apparently verifying how that party actually protected it.
Any company sitting on high-value, high-trust customer relationships, and a hardware wallet maker is about as high-trust as it gets, needs to treat repeated vendor-side breaches as evidence that its third-party risk assessment process is not catching real exposure before it happens. A single vendor breach can reasonably be called bad luck. Two in a month against the same company is a process failure that deserves a board-level review, not a second round of the same vendor questionnaire that missed the first problem.
The SSO lesson every SaaS buyer should take from this
The specific failure mode here, an SSO configuration meant for one tenant leaking access to other tenants, is a class of bug that recurs across multi-tenant SaaS platforms whenever enterprise identity features get bolted onto a system that was not originally designed with strict tenant isolation in mind. It is worth asking any vendor handling your customer data directly: how is tenant isolation enforced at the identity layer, and has that isolation been independently tested rather than just documented.
For a marketing platform specifically, the stakes of getting this wrong are unusually high because the asset at risk, a customer contact list, is exactly what an attacker needs to run a highly targeted phishing campaign against your actual customers, using your own trusted sending relationship to lend the message credibility. Any vendor holding your customer list deserves the same identity security scrutiny you would apply to a vendor holding your production database.
What CISOs should do this week
If your organization uses Brevo or any similar marketing platform, confirm directly with the vendor whether your account and contact lists were among the 138 compromised, rather than waiting for a proactive notification that may not distinguish clearly between affected and unaffected customers. Then audit your own customer-facing email templates for anything that could be convincingly spoofed the way Trezor's STM32 alert was, and consider pre-briefing your customer support team on what a real security notice from your company looks like versus what a spoofed one might claim.
More broadly, add a specific question to every SaaS vendor security review going forward: describe how your platform enforces tenant isolation under SSO and multi-organization access scenarios, and ask for evidence of independent testing rather than a policy statement. This incident shows exactly what happens when that isolation is assumed rather than verified, and the answer is a coordinated phishing campaign against your own customers wearing your name, using the trust your brand spent years building against the very people that trust was meant to protect.
