Brevo’s SAML flaw crossed 138 customer accounts. Six sent phishing through legitimate infrastructure.

The SAML assertion was valid, but its tenant boundary was not

Brevo’s incident write-up describes an attacker creating a normal Brevo account, enabling SAML single sign-on and inviting legitimate Brevo users into that configuration. The attacker controlled the identity provider, so signing in as an invited user was expected behaviour inside the new organisation.

The defect appeared after authentication. Brevo says the access was not restricted to the organisation that owned the SSO configuration. It extended to every Brevo organisation those invited users could reach. A valid assertion issued for tenant A therefore inherited authority in tenants B, C and beyond.

This is a cross-tenant authorisation failure, not simply stolen credentials. The system answered “who is this user?” but did not bind that answer tightly enough to “which organisation accepted this identity provider?” Federation design must enforce both.

Brevo reports 138 accounts accessed and contact exports from 43

Brevo identified the issue at 06:30 UTC on 10 September. Its write-up says 138 accounts were accessed, contacts were exported from 43, six were used to send phishing and 93 showed no meaningful attacker activity. At 08:30 UTC it closed the route and signed out every user.

Trezor’s notice, published on 10 September, cited an earlier total of 120 affected Brevo accounts. That number conflicts with Brevo’s later detailed account of 138. The responsible presentation is to keep both dates and treat 138 as the provider’s corrected total, not silently erase the discrepancy.

Brevo says the phishing messages travelled through legitimate infrastructure, so ordinary sender-authentication checks passed. SPF, DKIM and DMARC can show that an authorised service sent a message for a domain. They cannot prove that the customer intended the campaign after its marketing account was taken over.

Incident figures published by Brevo and Trezor

Measure	Published figure	Source context
Brevo accounts accessed	138	Brevo incident write-up
Accounts with contacts exported	43	Brevo incident write-up
Accounts used to send phishing	6	Brevo incident write-up
Accounts with no meaningful activity	93	Brevo incident write-up
Trezor newsletter addresses mailed	Roughly 347,000	Trezor notice
Clicks before domain takedown	2,500	Trezor notice

The Trezor lure asked for the one secret no wallet vendor needs

Trezor says a phishing message sent from its Brevo account used the subject “Critical Security Alert: STM32 Entropy Vulnerability”. The linked application asked recipients to enter their wallet backup. Trezor states that its wallet, product and account systems were not breached. The exposed system was its opt-in newsletter channel.

Trezor says it disabled sending, took down the malicious domain at DNS level within 20 minutes and limited working-link access to 2,500 people who had clicked. It cannot confirm from its notice whether its list was exported, so it treats all roughly 347,000 addresses as potentially known to the attacker.

A click alone did not expose wallet funds, according to Trezor. The critical event was entering the wallet backup into the malicious application. Anyone who did so needs to move funds to a newly secured wallet using Trezor’s published recovery guidance. The incident also creates a longer phishing risk because a verified newsletter address can be reused with different lures.

Three controls should change after a cross-tenant federation failure

First, bind every identity-provider configuration to an immutable tenant identifier and test negative cases in which one user belongs to several organisations. A valid identity assertion must still fail when the tenant, audience or organisation relationship does not match.

Second, alert on new identity providers, SSO invitations, contact exports and high-volume campaigns as one sequence. Each event can be legitimate alone. Together they form the path Brevo describes. Require step-up approval for bulk export and first-time campaign sends after an identity configuration changes.

Third, plan for compromise of the legitimate sending platform. Maintain an emergency kill switch at the sending service and domain or DNS layer, pre-authorise customer notifications through independent channels, and retain campaign evidence. Email authentication remains necessary, but content and account-behaviour controls must assume that an authorised sender can be abused.

Evidence to request from an email-platform provider

Boundary	Evidence	Control test
Identity provider	Who created or changed SSO, when and from where	Cross-tenant assertion must fail
Contacts	Exports, API reads and list access	Bulk extraction generates an alert
Campaign	Creator, approving account, template and send volume	New SSO plus mass send requires review
Response	Session revocation and message or domain takedown times	Emergency route works without the compromised account

The position

Brevo’s incident shows why federation is an authorisation system as well as an authentication system. The attacker did not need to forge a SAML response if a legitimate response for one organisation was accepted across others.

For customers, the damage also extends beyond the provider’s account count. Phishing sent through real infrastructure can pass sender authentication, inherit brand trust and reach an audience assembled precisely because it is interested in that brand. Supplier reviews should therefore cover tenant-isolation tests, bulk-export telemetry and emergency campaign shutdown, not only security certifications.

Brevo has published a clear root cause and corrected totals. The next proof is evidence that its permanent tenant binding works for users who legitimately belong to several organisations, the exact condition that allowed this incident to spread.