How a Flawed SSO Invitation Flow Turned Brevo Into a Phishing Launchpad for 347,000 Crypto Users

Create a free account. Turn on single sign-on. Send an invitation to someone else's employee — someone who works at a company you've never had any business relationship with. Wait for them to authenticate through their own identity provider, the way they do every morning without thinking about it. Now you're logged in as them, inside their employer's paid account, and as far as the platform is concerned, nothing unusual just happened.

That is, in plain terms, how an attacker walked into 138 Brevo customer accounts in September 2026, including the marketing platform used by hardware wallet maker Trezor, and used one of them to email a fake critical vulnerability alert to 347,000 real subscribers. I've spent enough years around identity federation — configuring SAML and OIDC integrations, arguing with vendors about session scoping, cleaning up after "temporary" SSO exceptions that never got revoked — to know exactly which corner this bug was hiding in. It's the corner almost nobody threat-models, because everyone's attention is on the login screen and none of it is on the invitation and provisioning logic sitting quietly behind it.

What Actually Broke Inside Brevo's SSO

Brevo (formerly Sendinblue) is a French email marketing and CRM platform used by a long list of companies to run newsletters, transactional email, and marketing automation. Plenty of cryptocurrency companies use it, which is exactly why this incident hurt the way it did.

On September 10, 2026, Brevo's own security team identified the problem and moved fast. Within a few hours they had shut off the attacker's access and posted a short public update:

"This morning we have closed a security incident that allowed an attacker to access 120 Brevo accounts. The majority of those have no suspicious activity. The bad actor used the access to send phishing emails to the client's contactbase. The access has been closed as of 11:30AM CEST today 10.09.2026."

Figure 1: Brevo's first public acknowledgment of the breach, posted the same morning it closed the attacker's access (Source: Brevo / @brevo_official).

That initial number — 120 accounts — turned out to be a floor, not a ceiling. Brevo's full postmortem, published later the same day, revised it upward:

"On September 10th at 6:30 AM UTC we identified a security issue where an attacker exploited a flaw in the way Brevo handles SAML SSO to gain access to 138 Brevo accounts. 6 of those accounts were used to send phishing emails to the contacts stored there, and for 43 accounts they exported the contacts. 93 accounts have no meaningful activity."

The root cause, as described by Brevo and reported by outlets that reviewed the postmortem, was an authorization scoping failure in how SSO sessions were bound to organizations. An identity that authenticated through one customer's SSO configuration was supposed to stay confined to that one organization. It wasn't. The access token or session context the attacker generated carried over to every organization that user identity could reach inside Brevo's multi-tenant account structure — and the attacker controlled which identities existed in the first place, because they'd invited them.

The Attack Chain, Step by Step

Strip away the SaaS-specific vocabulary and the sequence is almost mundane, which is exactly what makes it dangerous:

1. Register. The attacker signed up for an ordinary, free-tier Brevo account under their own control — no different from any legitimate new customer onboarding.
2. Enable SSO. They turned on SAML single sign-on for that account and pointed it at an identity provider they also controlled.
3. Invite. Using Brevo's normal organization-invitation feature, they sent SSO invitations addressed to email addresses belonging to employees at unrelated, legitimate Brevo customers — companies with no relationship to the attacker's account.
4. Authenticate. When those invitations were accepted (or simply processed as part of routine SSO provisioning), the attacker signed in through their own identity provider as the invited identities — exactly the behavior SSO is designed to allow, just aimed at accounts it was never meant to reach.
5. Escape the scope. Because Brevo's session logic didn't confine that authenticated access to the attacker's own organization, the attacker's session carried real permissions inside the legitimate customers' accounts — 138 of them in total.
6. Pick targets and act. Of those 138, the attacker used 6 to send phishing campaigns to the account's own newsletter subscribers, and exported the full contact list from 43 more — harvesting email addresses for future campaigns even where they didn't fire anything through that account directly.

Trezor was one of the six accounts used to actually send mail. BitBox and CoinTracking, both compromised through the same mechanism, confirmed phishing emails went out to their subscriber lists as well.

The Payload: A Fake Hardware Vulnerability

The email that went out from Trezor's own Brevo-managed sending infrastructure was well built. It didn't ask for a password reset or dangle a prize. It manufactured a plausible-sounding hardware defect and used Trezor's own brand, layout, and sending domain to deliver it — which is precisely why supply-chain phishing through a trusted vendor's infrastructure converts so much better than phishing from a spoofed lookalike domain.

Figure 2: The phishing email sent from Trezor's compromised Brevo sending account, using the fabricated “STM32 Entropy Bug” pretext (Source: Trezor).

The email, titled "Critical Security Alert: STM32 Entropy Bug Identified", told recipients:

"We have some difficult news to share. Unfortunately, our engineering team has identified a critical hardware-level vulnerability in the STM32 microcontrollers used in a range of Trezor devices. Currently we believe the majority of defective devices were initialized prior to 2023, however some newer devices also may be vulnerable. The bug is a hardware factory defect present in an estimated 1 in 4 devices." The vulnerability results in: "Insufficient randomness in recovery phrase generation, Exposure of seeds to brute-force cracking, Seeds with as little as 40 bits of entropy."

The email pushed recipients to download an "app" and enter their wallet recovery phrase to check whether their device was affected — the single worst thing a hardware wallet owner can do, and the entire reason hardware wallets exist in the first place: to keep the seed phrase off any screen or app that could exfiltrate it. There was no STM32 entropy bug. The vulnerability was invented specifically to manufacture urgency around the one action that drains a wallet.

CoinTracking's compromised account sent a different pretext to its own subscribers, titled "Data Breach Notice: Please refresh API Keys as soon as possible", also carrying a malicious link. Different bait, same delivery mechanism.

The Numbers

Trezor's own account of its response, laid out in an internal timeline it later published, credits fast detection and a quick DNS-level takedown with keeping the number of clicks to roughly 2,500 out of 347,000 — well under 1%, but on a wallet-draining phishing page, even a fraction of a percent is real money walking out the door.

Figure 3: Trezor's own published timeline, from the phishing send through link takedown and customer notification (Source: Trezor).

Worth noting: this wasn't Trezor's first brush with third-party exposure this year. Weeks earlier, a breach at its shipping fulfillment provider, ShipMonk, reportedly exposed order and shipping details for roughly 81,000 customers. Two unrelated vendors, two unrelated incidents, the same underlying lesson about where a hardware wallet company's actual attack surface lives — not in the firmware, in the vendor list.

My Take

I keep coming back to how ordinary every individual step in this attack chain was. Nobody found a memory corruption bug. Nobody cracked a hash. Every action the attacker took — registering an account, enabling SSO, sending an invitation, authenticating through their own IdP — is a feature Brevo built on purpose and that a legitimate customer performs routinely. The vulnerability wasn't in any single function; it was in an assumption that never got tested: that an SSO session, once established, stays inside the organizational boundary it was established for. Most engineers I've worked with build access control around the login event. Far fewer stress-test what happens after a valid session already exists and starts reaching sideways into tenants it has no business touching. Multi-tenant SaaS platforms that let customers self-provision SSO are exactly where that gap tends to live, because provisioning logic gets built once, works for the demo, and then quietly carries the trust of every session it ever creates.

The part that should worry infrastructure and security teams more than the Brevo bug itself is the delivery mechanism it enabled. This wasn't a spoofed domain, a typo-squatted lookalike, or a compromised personal inbox. The phishing email came from Trezor's actual sending infrastructure, through Trezor's actual authenticated relationship with its actual email provider, to a list Trezor had legitimately built over years of customer trust. Every anti-spoofing control — SPF, DKIM, DMARC — that a security team would normally point to as the reason "this can't happen to our brand" was irrelevant here, because nothing was spoofed. The mail really did come from where it said it came from. That's the uncomfortable trend line running through a lot of 2026's supply-chain phishing: attackers increasingly don't need to fake your infrastructure when they can just borrow a vendor's.

And the target selection wasn't random. Whoever ran this operation clearly understood that crypto companies using a shared marketing platform represented a concentrated, high-value blast radius — hardware wallet owners are precisely the population most likely to have meaningful funds behind a recovery phrase, and precisely the population a "critical hardware vulnerability, act now" pretext is most effective against, because it inverts the exact security behavior these products are marketed on.

What You Should Do Right Now

• Audit every SSO integration you run as an identity provider or service provider for tenant isolation, not just authentication. Confirm explicitly, in a test environment, that a session or token issued under one tenant's SSO configuration cannot reach resources belonging to a different tenant — don't assume your vendor's multi-tenancy model enforces this correctly just because login works.
• Treat SSO invitation and provisioning endpoints as a first-class attack surface in your vendor risk reviews. Ask SaaS vendors directly: can a customer's SSO invitation reach an identity outside that customer's own domain or organization? If they can't answer confidently, that's your answer.
• If you run marketing or transactional email through any third-party platform (Brevo, Mailchimp, SendGrid, Customer.io, or similar), review who on your team has SSO or API access to that platform today and confirm none of it traces back to an invitation or integration you don't recognize.
• Build a customer-facing incident protocol for "an email really did come from us, but we didn't send it." Trezor's ~20-minute takedown worked because they had a fast path to pull DNS and push a warning through other channels immediately — decide who has that authority on your team before you need it at 2 a.m.
• Coach users, and yourself, away from "the email domain checks out" as a trust signal. A legitimate sending domain plus a legitimate provider relationship is no longer proof of anything. Recovery phrases, seed words, and API keys should never be entered anywhere a link took you — full stop, regardless of how convincing the branding is.
• If you or anyone on your team clicked a link from this specific campaign and entered a wallet backup or recovery phrase anywhere other than directly on a hardware device, move those funds to a new wallet immediately. Don't wait to confirm whether the page "looked real enough" to have worked — assume it did.

This article was researched and drafted with AI assistance as part of an experiment in building a faster tech-writing workflow, then reviewed and edited before publishing.

Primary source: Crypto customers targeted by scammers after email marketing provider breach — Malwarebytes, September 2026

Secondary sources: Multiple crypto companies warn customers of phishing emails after alleged provider breach, Trezor Says 347,000 Users Received Phishing Emails After Brevo Hack — SecurityWeek, and Security Incident at Brevo, Our Third-Party Email Provider — Trezor Blog