What happened
On 9 September 2026, an attacker used Brevo access to send phishing through customer accounts, including Trezor’s newsletter account. At 06:30 UTC on 10 September 2026, Brevo identified the SAML SSO issue; at 08:30 UTC it closed the route and signed out every platform user. Brevo said an attacker configured SSO in an attacker-controlled account, invited legitimate users and gained access beyond the organisation that owned the SSO configuration because the boundary was not correctly enforced.
Brevo said 138 accounts were accessed: six were used to send phishing, 43 had contacts exported and 93 showed no meaningful activity. Trezor’s initial notice said 120 Brevo accounts were affected, while Brevo’s later write-up reported 138. On 11 September 2026, independent reporting consolidated Brevo’s revised account scope and Trezor’s customer impact.
Trezor said roughly 347,000 addresses received the initial email and 2,500 people clicked before the linked domain was disabled within 20 minutes. The phishing subject was: Critical Security Alert: STM32 Entropy Vulnerability. The malicious link prompted download of an application requesting the user’s wallet backup. Trezor said no wallet, product or account system was affected.
The cited sources did not publish the phishing domain, application filename, file hash, IP address or actor identity. Attribution posture: Brevo and Trezor referred to an unauthorised attacker but did not identify or attribute the actor.
Why this matters now
The messages passed normal email-authentication checks because they were sent through legitimate provider infrastructure. That reduces the defensive value of sender reputation, SPF, DKIM and DMARC for recipients and shifts emphasis to content, destination, behavioural context and customer education. Enterprises using shared SaaS platforms should ask whether tenant boundaries are enforced after federated authentication, not merely whether SSO is enabled.
The revised scope also separates three impact populations: accounts used to send phishing, accounts from which contacts were exported and accounts accessed without meaningful activity. That distinction matters for notification, credential containment and supplier assurance. Trezor’s rapid DNS action limited continued access to the malicious destination, but addresses may remain reusable for future targeting even where recipients did not enter a wallet backup.
The decision for security leaders
Require evidence that SaaS identity federation binds every authenticated session to the organisation that owns the identity-provider configuration. A generic statement that SSO is supported is insufficient. Assurance should cover cross-tenant authorisation tests, invitation workflows, session invalidation and the provider’s ability to identify contact exports and messages sent from each affected account.
Treat outbound customer communications as a privileged channel. Marketing or support platforms should have least-privilege roles, strong approval for high-volume sends, export alerts and an emergency method to disable links or sending. Incident plans must assume a message can pass authentication and still be malicious, with customer instructions tailored to the specific secret or action attackers seek.
Evidence of closure
- Provider assurance includes tested cross-tenant SSO isolation results.
- Federated-user review removes unexplained invitations and access paths.
- Outbound-send monitoring alerts on abnormal volume and secret-seeking content.
- Emergency runbook proves link and sending disablement authority.
The Security.io assessment
The breach is well supported by two direct company disclosures, although Trezor’s initial 120-account figure differs from Brevo’s later 138-account total. Brevo’s breakdown is the more specific provider-wide scope, while Trezor’s figures describe its own newsletter population and click impact. The evidence does not establish how many recipients entered wallet backups or lost funds.
This is both a third-party incident and a supply-chain security failure because compromise propagated through a shared communications platform and its trusted delivery infrastructure. The durable enterprise lesson is not to abandon federated identity or email providers; it is to require tenant-boundary evidence and to monitor privileged outbound channels with the same seriousness as administrative access.
Questions for the morning meeting
- Can a federated identity configured in one SaaS tenant reach any other tenant or organisation?
- Which communications vendors can send authenticated messages to customers without secondary approval?
- Can the organisation rapidly disable malicious links after trusted email has been delivered?