The Brevo Supply Chain Attack: What 100,000 Hacked Websites Mean for Your Business

On 14 September, somewhere between 100,000 and "we may never know exactly how many" websites started serving malware to their visitors. The site owners had done nothing wrong. They had not been hacked in any traditional sense. They simply had a small script from Brevo, a popular email marketing and CRM platform, embedded in their pages, and for about four hours that script was quietly rewritten by attackers. This is what a supply chain attack looks like, and the Brevo supply chain attack is one of the largest to hit ordinary business websites this year.

The incident matters well beyond Brevo's own customer base. Most business websites today are assembled from third-party pieces: a chat widget here, an analytics tag there, a signup form from an email platform, a payment script from a processor. Each of those pieces is a door into your site that you do not control.

In this post we go through what actually happened, why one forgotten API key was enough to poison six-figure numbers of websites, and what practical steps a business owner or manager should take now, even if you have never heard of Brevo before today.

What happened in the Brevo supply chain attack

Brevo, which many will still remember under its old name Sendinblue, provides email marketing, signup forms, a chat widget and CRM tools to hundreds of thousands of businesses. To make those features work, customers paste small JavaScript snippets into their websites. That code loads from Brevo's servers, which means whatever Brevo serves, your visitors receive.

The trouble started earlier in September. On the 10th, attackers exploited a weakness in Brevo's single sign-on system and got into 138 customer accounts. One of them belonged to Trezor, the hardware wallet maker, and phishing emails went out to roughly 347,000 addresses connected to it. Unpleasant, but still a fairly contained incident.

Four days later the same attackers came back with something much bigger. On 14 September, from around 16:05 UTC, they used a compromised Cloudflare API key to deploy a malicious Worker on Brevo's CDN infrastructure. That Worker sat at the network edge and modified Brevo's scripts as they were delivered, including the form scripts, the Conversations chat widget and the SDK loader that customers embed on their sites. Security firm Sansec spotted the campaign and estimates that over 100,000 websites were serving the altered code before Brevo shut it down after roughly four hours.

One forgotten API key was enough

The detail that should worry every technical leader is how the attackers got in. Brevo's own post-mortem, published on 17 September, admits that a long-lived Cloudflare API key with full account permissions had been hardcoded in the application source code. Whoever obtained that key could do nearly anything with Brevo's Cloudflare account, and nobody was alerted when they did.

Working at the CDN edge gave the attackers two big advantages. First, they never touched Brevo's origin servers, so file integrity monitoring saw nothing unusual. Second, the malicious Worker stripped security headers such as Content-Security-Policy from responses, which quietly disabled protections that would normally have blocked injected code in the browser.

It is an old lesson in a new costume. Hardcoded credentials have been behind breaches for decades, but the edge computing twist makes them far more dangerous, because a CDN key is effectively a master key to everything your users see. A single string in a repository turned into four hours of malware delivery across a six-figure number of domains.

The nasty part: a WordPress plugin that hides itself

What visitors experienced depended on who they were. Regular users saw a fake "Cloudflare, verify you are human" page, followed by instructions to run a command on their own computer. This trick is known as ClickFix, and it has become one of the most common infection methods of the last two years, because it convinces people to infect themselves and no antivirus warning appears at any point.

Logged-in WordPress administrators got special treatment. The injected script detected the admin session and tried to install a plugin called Web Media Optimizer, pulled from attacker-controlled domains. The name is boring on purpose. Once installed, the plugin hid itself from the plugin list, copied itself into the must-use plugins directory so it would survive cleanups, and contained hardcoded authentication that let the attackers open admin sessions whenever they wanted. It also kept calling home and injecting fresh ClickFix lures for the site's visitors.

So a marketing tool's script was turned, in effect, into a distribution channel for website backdoors. If an administrator merely browsed their own site during the wrong four hours, their WordPress installation may now belong to someone else as well.

Why attacks on trusted platforms keep working

The economics here are brutally simple. Breaking into one well-defended website is work. Breaking into a platform whose code runs on 100,000 websites is the same work with a hundred thousand times the payoff. Attackers understood this some time ago, which is why the last few years brought the Polyfill.io incident, a steady stream of poisoned npm packages, and now Brevo.

Trust is what makes it possible. Browsers treat a script loaded from a legitimate vendor exactly the same as your own code. It runs with full access to the page, the forms, the cookies it can reach and the user's clicks. Your SSL certificate and your hosting security say nothing about it, because nothing on your server changed.

There is also a visibility problem. Most businesses have no complete list of the third-party scripts running on their site. Tags were added by an agency three years ago, a plugin quietly loads two more, marketing added a pixel last quarter. When one of those vendors has a bad day, nobody inside the company even knows the exposure exists.

What your business should do about third-party scripts

The uncomfortable truth is that you cannot fully outsource this risk, but you can manage it. A few practices make the difference between a bad afternoon and a long compromise.

Start with an inventory. Have your developers, in-house or outsourced, produce a list of every external script your site loads and what it is for. On most business sites this list is longer than anyone expects, and a few entries usually serve no purpose anymore. Every script you remove is attack surface gone for free.

Then reduce the blast radius of what remains. A Content-Security-Policy limits which domains may run code on your pages. Subresource Integrity can pin static third-party files to a known version. Neither would have fully stopped Brevo's edge-level tampering on its own, but together they raise the cost for the attacker, and CSP violation reports often provide the earliest warning that something changed.

Monitoring closes the loop. External scanners such as the ones Sansec runs, or even a simple scheduled job that fetches your key pages and diffs the scripts they load, will catch injections that server-side tools cannot see by definition. And it is worth asking your vendors direct questions: how do you store credentials, do you use short-lived API keys, how would you notice a rogue Worker on your CDN? Their answers, or the silence, tell you a lot. Finally, treat privileged browsing as a risk of its own. Administrators should log into the CMS only when they need to, ideally from a separate browser profile, because the Brevo attack specifically hunted logged-in admins.

How to check whether your site was caught

If your website uses Brevo forms, chat or tracking, assume exposure during the window of 14 September, roughly 16:05 to 20:30 UTC, and check properly rather than hope.

For WordPress sites, review the plugin list and the wp-content/mu-plugins directory for anything named Web Media Optimizer or anything you do not recognise, and compare installation dates against 14 September. Remove suspicious entries, then rotate every administrator password and invalidate active sessions. Given that the malicious plugin could hide itself, a scan with a server-side malware tool is worth the small cost, and a restore from a clean backup is the safer route where doubt remains.

Beyond WordPress, check your analytics for that afternoon. A sudden spike in bounce rate or strange outbound requests can indicate that visitors were seeing the fake verification overlay. If customers report being asked to "verify" by running commands on their computer, they were targeted through your pages and deserve a warning from you, not from the press.

Brevo says its API, email sending and customer data were not affected, and the malicious infrastructure stopped resolving on 15 September. The embedded scripts are clean again. The plugins installed during the window, wherever they succeeded, are still out there.

Final notes

The Brevo supply chain attack will not be the last of its kind, and honestly, it was handled faster than many. Four hours of exposure and a public post-mortem within three days is a decent response to an ugly mistake.

For business owners the takeaway is not to strip every third-party tool from your website. These tools exist because they solve real problems. The takeaway is that every embedded script is a supplier relationship with security consequences, and it deserves the same basic diligence you would apply to any supplier: know who they are, know what they can touch, and have a plan for the day they get breached. At Davydov Consulting we have been adding script inventories and CSP setups to client projects for exactly this reason. It is unglamorous work, and it is much cheaper than explaining to your customers why your website told them to infect their own computers.