22 SEP 2026 — Brevo serves JavaScript to customer websites. On 14 September, for four hours and seven minutes, three of those files on its delivery network carried code nobody at Brevo had written.
Every account of the incident disagrees about how long the injection lasted, and that duration is the only proxy anyone has for how many people were exposed.
How long it actually ran
Sansec, which watches third-party scripts for content security policy violations, timed the injection window to the second. Its research note states that "Brevo served the malware between 16:05:18 and 20:12:53 UTC on 14 September". That is four hours and seven minutes.
Brevo's own account is close without matching. It gives 16:07 to 20:30 UTC, about four hours and twenty-three minutes. Two independent measurements of one event, seventeen minutes apart at the end.
A third figure has travelled further than either. SecurityWeek's report of 18 September says "the malicious worker was active for roughly five and a half hours before Brevo removed it" — and, in the same article, that "the malware was served for roughly four hours". Both figures cannot be correct, but the higher one has been repeated most often.
What the worker changed
Brevo has said the attackers held a long-lived Cloudflare API key with full account permissions, hardcoded in application source code, and that it may have been compromised as early as late August. No injection into customer pages was detected before 14 September.
With that key they deployed a Cloudflare Worker that rewrote responses at the edge for three files: cdn.brevo.com/js/sdk-loader.js, cdn.brevo.com/js/brevo-conversations.js and conversations-widget.brevo.com/brevo-conversations.js. The payloads themselves loaded from subdomains of sendibt1.com.
The worker also stripped content security policy headers from those responses. That is the step that turns an injection into a dependable one. The browser rule that would have refused an unexpected script was removed before the browser ever saw it.
Preparation shows in the certificate record. A certificate for cdn.sendibt1.com was created on 25 August, roughly three weeks before anything was served from it.
Two payloads, two targets
Visitors got one of two things, depending on who they were.
On WordPress sites carrying an embedded Brevo widget, and only for a logged-in administrator, the script attempted to install a plugin called Web Media Optimizer. BleepingComputer describes it persisting through the must-use plugin directory, calling out to attacker infrastructure, and carrying hardcoded authentication keys that permit administrative access with no password.
Everyone else was shown a counterfeit Cloudflare human-verification overlay, which then asked them to paste and run a command on Windows. The technique is called ClickFix, and it works because the victim performs the compromise by hand, which no browser control can intercept.
Where 100,000 comes from
The figure of 100,000 websites, repeated across the coverage, needs to be read precisely.
Sansec derived it from a PublicWWW search for pages referencing brevo.com, sibforms.com or sibautomation.com. That is a count of sites embedding Brevo code at all — reach, not infection.
Its own direct observation is far smaller and far harder. The policy monitor recorded 2,549 violation reports across 12 sites, in and after the window.
The two figures answer different questions. 100,000 is how many sites could have served the file. 2,549 is how many times a browser reported being asked to run something the site's own policy forbade, across the sample Sansec happens to watch. Neither is a victim count. Nobody has published one.
The breach before this one
On 10 September Brevo had reported a separate compromise involving SAML single sign-on, in which attackers took over customer accounts and sent phishing from them. The 14 September malware was the company's second disclosure in five days.
Trezor, the hardware wallet maker, confirmed on 11 September that phishing sent through its Brevo account reached 347,000 user email addresses, and that at least 2,500 were compromised.
The two incidents share no mechanism. One is an authentication failure at the account layer; the other is a stolen infrastructure key used at the edge. A customer reading both disclosures sees one supplier fail twice in a week, in two different places.
View author profile → · Editorial policy
