Breach Teardown
What Caused the Brevo Breach?
In September 2026, the email marketing platform Brevo published post-mortems on two incidents four days apart, each a different identity failure. In the first, its SAML single sign-on let an attacker who controlled one organization sign in to every organization its invited users belonged to. In the second, a long-lived Cloudflare API key with full account permissions, stored in application source code, let an attacker rewrite the scripts Brevo serves onto its customers’ websites.
By Vidyaa Ganesh, Founder, Identara
- Scale
- 138 accounts via SSO; up to 100,000 sites potentially exposed (per Sansec)
- Attack vector
- SSO invites that crossed tenants, and a hardcoded Cloudflare key
- IAM domains implicated
- CIAM, PAM, Cloud, Security
- Domino controls hit
- 2 of 4
The Incident
What Happened
On September 10, 2026, Brevo identified an attacker abusing its SSO feature. Per Brevo’s post-mortem, the attacker created a Brevo account, enabled SAML SSO on it, invited legitimate Brevo users into that configuration, and then signed in as those users through an identity provider the attacker controlled. That much is how SSO is designed to work. The flaw was scope: access was not limited to the organization that owned the SSO configuration, so the attacker reached every organization those users belonged to. 138 accounts were accessed, contacts were exported from 43, and 6 were used to send phishing to their own contact lists. Brevo closed the access route two hours later and signed out every user on the platform.
A second incident followed on September 14. Per Brevo’s second post-mortem, a long-lived Cloudflare API key with full account permissions, stored in application source code and first misused in late August, let the attacker create hostnames on Brevo-owned domains and a Cloudflare Worker routed to brevo.com and sibforms.com. The Worker appended a loader to embedded JavaScript that showed selected visitors a fake “verify you are human” page instructing them to run a malware-downloading command, and that tried to silently install a plugin when a logged-in WordPress administrator visited a site embedding a Brevo widget.
Per Brevo, impact began at 15:01 UTC, when the Worker was routed to all of brevo.com; the lure was appended to embedded scripts from 16:07 until 20:30, and the incident was opened at 19:33. Security firm Sansec estimated that up to 100,000 websites using the affected Brevo components may have been impacted. Brevo revoked the key, replaced it with narrowly scoped, short-lived tokens, and committed to vault-based storage for Cloudflare keys and alerting on Cloudflare audit events. Brevo has not said whether the two incidents are connected.
Attack Chain
How the Attack Compounded
Each step below marks the AXIS control that failed at that point in the chain, where one applies. Steps without a control marker were outside the victim's direct span of control.
September 10: an attacker creates a Brevo account, enables SAML SSO on it, and invites real Brevo users into the configuration.
CIAM-04
Signing in as those users through the attacker’s own identity provider opens every organization they belong to, not just the attacker’s. 138 accounts are accessed.
CIAM-04
Separately, a long-lived Cloudflare API key with full account permissions sits in Brevo’s application source code.
PAM-02
The key is first misused in late August without an alert. On September 14 it is used to create hostnames and a Worker on Brevo’s own domains.
CLOUD-02
The Worker injects a fake verification lure and a WordPress backdoor installer into scripts customers embed. The incident is opened more than three hours after the code goes live.
SEC-01
Control Mapping
The IAM Controls That Failed
Every failure point below is a capability in the AXIS IAM capability model: the same 4 controls an IAM maturity assessment would have scored before this incident.
| Control | Domain | Capability | How it failed here |
|---|---|---|---|
| CIAM-04 | CIAM | B2B Delegated Administration & Partner Identity | Multi-tenant SSO is a tenant-isolation control. An identity provider configured by one organization was trusted to assert identities for users across every organization they belonged to, so the boundary between customers was only as strong as the least trustworthy tenant’s IdP. |
| PAM-02 Domino | PAM | Secrets Management (Non-Human & Application Credentials) | A credential able to rewrite Brevo’s edge was hardcoded in source code, long-lived, and scoped to the whole account. Its location, lifetime, and reach were each the opposite of what secrets management prescribes, and Brevo’s own remediation replaced it with short-lived, narrowly scoped tokens. |
| CLOUD-02 | Cloud | Non-Human Identity (NHI) Governance | The key was a non-human identity that could create Workers, routes, and DNS records without triggering an alert. Its first misuse in late August went unnoticed, and the changes it made raised no alert. |
| SEC-01 Domino | Security | Identity Threat Detection & Response (ITDR) | The malicious Worker served customer-facing traffic for hours before the incident was opened, weeks after the key’s first misuse. Brevo’s remediation plan adds streaming Cloudflare logs to security monitoring and alerting on audit events, which describes the detection loop that was missing. |
The Maturity Lesson
What Would Have Changed the Outcome
The Domino Effect
PAM-02 and SEC-01 are both domino controls, and Brevo shows how they compound for a platform whose code runs on other people’s websites. One hardcoded key turned Brevo’s edge into an attacker’s distribution network, and detection that lagged by weeks, then by hours, set the exposure window for up to 100,000 downstream sites. The SSO flaw is the quieter lesson: tenant isolation is an identity control, and a SaaS vendor’s B2B identity model is part of every customer’s attack surface.
The Maturity Level That Mattered
At level 2 or higher on PAM-02, infrastructure credentials live in a vault with automated rotation, and nothing that can rewrite production edge configuration exists as a static string in a repository. At level 2 on CIAM-04, delegated administration is tenant-isolated by design: an SSO configuration asserts identities only for the organization that owns it.
For customers of any SaaS that serves scripts onto their pages, this case reframes vendor review. Ask how the vendor stores the credentials that control its CDN and edge, and how quickly it would notice them being used. Those answers are effectively part of your own website’s security.
Related Compliance Frameworks
The controls implicated in this breach carry citations in these frameworks within the AXIS bank:
Put a Number on It
What Would a Breach Like This Cost You?
The breach cost calculator turns a failure pattern like the one above into a dollar figure. Set your identity count, pick your industry, give an honest read of your IAM maturity, and see the annualized loss exposure it implies.
Run the Breach Cost CalculatorSources
About This Analysis
This teardown is based exclusively on public disclosures, regulatory findings, and reporting cited above; it makes no claim of insider knowledge about the internal environment at Brevo. Control mappings express how the publicly documented failure points correspond to capabilities in the AXIS methodology, for educational purposes. AXIS is not affiliated with Brevo.
More From the Breach Radar
What Caused the Salesloft Drift Breach?
Stolen OAuth tokens from a chatbot integration
What Caused the Okta Support System Breach?
Service account credential exposed via a personal browser profile
What Caused the Microsoft Midnight Blizzard Breach?
Password spray on a legacy tenant, over-privileged OAuth app
Would Your Program Have Caught This?
The 4 controls that failed here are questions in the AXIS assessment. Score your organization against them, and the rest of the bank, in about 20 minutes. No signup required to start.