Brevo Supply-Chain Attack: Trusted Scripts Turned Into Malware Delivery

A compromised Cloudflare API key allowed attackers to interfere with Brevo’s web infrastructure. Moreover, they injected malicious JavaScript into resources that other websites loaded, a hallmark of the Brevo supply chain attack.

For several hours on September 14, visitors to affected pages could be shown fake Cloudflare verification prompts designed to trick them into running malicious commands on Windows.

But ordinary visitors were not the only target.

When the malicious code detected someone already logged into a WordPress site as an administrator, it attempted something quieter: installing a malicious WordPress plugin using the administrator’s existing session.

That turns what initially looks like another ClickFix campaign into a much more interesting supply-chain incident.

The attackers did not need to break into every customer website individually.

They went after a shared point of trust instead.

Brevo provides forms, chat components, and JavaScript libraries that customers embed on their websites. However, this points to a Brevo supply chain attack risk when attackers manipulate Brevo-delivered resources.

Brevo supply chain attack details say the entry point was a long-lived Cloudflare API key with full account permissions. That key had been hardcoded in the application source code.

That single credential gave the attackers enough control to create Cloudflare Workers, routes and DNS records across Brevo-controlled zones.

And because the manipulation happened at Cloudflare’s edge rather than by directly rewriting Brevo’s original files, some of the places defenders would normally look for an unauthorised modification could still appear clean.

The original files did not need to change

This is one of the more important details of the attack.

A website normally stores its files on an origin server. A service such as Cloudflare can sit between that origin and the person visiting the website, receiving requests and delivering content closer to the user.

That position also means the edge can influence what ultimately reaches the browser.

The attackers abused that layer.

Using the compromised API key, they created a malicious Cloudflare Worker capable of changing responses while they were being delivered.

So Brevo’s original file could remain untouched while the browser received something different.

The malicious Worker could also remove security headers, including Content-Security-Policy, from responses.

This helps explain why checking the files sitting on the origin server would not necessarily reveal what visitors had actually received.

Brevo says the malicious activity ran from approximately 16:07 to 20:30 UTC on September 14, a window of about five and a half hours.

Sansec, which independently investigated the incident, observed malicious Brevo resources from roughly 16:05 to 20:13 UTC.

By September 15, the malicious hostnames identified during the investigation had stopped resolving and the affected Brevo resources were clean.

The attack itself was relatively short.

Its reach is harder to measure.

Customer websites inherited Brevo’s problem

Brevo’s own websites were affected, but the more significant exposure came from JavaScript components loaded by other websites.

Brevo customers can embed resources such as its forms, Conversations widget and SDK loader into their pages.

Normally, that arrangement is convenient.

The customer does not need to host and maintain all of that code themselves. Their website simply requests the component from Brevo when somebody loads the page.

But that convenience creates a trust relationship.

If the external script changes, the customer website can begin executing the changed code even though nobody modified the customer’s own application.

That is what made this incident a supply-chain problem.

Sansec found malicious modifications affecting Brevo resources including its SDK loader and Conversations JavaScript. Its investigation estimated that more than 100,000 websites use affected Brevo components.

That number needs to be interpreted carefully.

It does not mean more than 100,000 websites were successfully hacked.

A website had to be using an affected Brevo resource during the attack window to potentially serve the malicious JavaScript, and further compromise depended on what happened after the code reached a visitor.

The important point is that the attacker gained a way to distribute malicious code through infrastructure that a potentially large number of unrelated websites already trusted.

Most visitors saw a fake security check

For an ordinary visitor, the attack could appear as something increasingly familiar on the web: a Cloudflare-style verification screen.

The page told the visitor that an additional step was necessary to prove they were human.

But the verification was fake.

The instructions were part of a technique known as ClickFix.

Instead of relying entirely on a browser exploit that silently installs malware, ClickFix persuades the victim to perform the dangerous action themselves.

The user may be instructed to open the Windows Run dialog, paste a command and execute it.

To someone who believes they are completing a browser or security verification, those steps can appear technical but legitimate.

In reality, the victim is being guided into launching attacker-supplied code on their own computer.

This changes the security boundary in an uncomfortable way.

The browser does not necessarily have to be exploited.

The attacker convinces the person sitting in front of it to cross the boundary for them.

WordPress administrators received a different attack

The malicious JavaScript behaved differently when it detected a visitor who was already authenticated to WordPress as an administrator.

Instead of simply displaying the ClickFix lure, the script attempted to upload a WordPress plugin.

That distinction matters.

A visitor falling for ClickFix potentially compromises their own computer.

A malicious plugin installed through an administrator’s authenticated WordPress session can potentially compromise the website itself.

Sansec observed the script attempting to retrieve a plugin archive named wm.zip and upload it through WordPress’s normal plugin installation mechanism.

Sansec was unable to recover the plugin during its initial investigation, so it correctly stopped short of claiming exactly what the plugin could do.

The archive was subsequently found in VirusTotal and analysed.

The plugin presented itself as Web Media Optimizer, but its behaviour went far beyond media optimisation.

It could act as a persistent loader for attacker-controlled JavaScript.

More seriously, analysis found functionality capable of creating a valid authenticated WordPress administrator session using a hardcoded authentication key.

That means persistence on an affected WordPress site could survive beyond the few hours during which Brevo was actively serving the malicious JavaScript.

Removing the malicious Brevo code from the supply chain stops new delivery.

It does not automatically remove a backdoor that was already installed downstream.

One credential provided far more access than it should have

At the centre of the incident was the compromised Cloudflare API key.

Brevo says the key was long-lived, stored in application source code and carried full account permissions.

Those three characteristics created a dangerous combination.

A credential embedded in source code can eventually escape through places developers may not immediately think about: repositories, backups, logs, build systems, copied code or other development infrastructure.

A long-lived credential gives an attacker more time to use it once it has been exposed.

And a credential with broad permissions turns one leaked secret into access to functions that may have little to do with the application’s original reason for having the key.

In this case, the key could be used to create Cloudflare Workers, routes and DNS records across Brevo’s zones.

The attackers did not merely obtain permission to read information.

They obtained the ability to change how trusted web content was delivered.

Brevo says the key may have been compromised as early as late August, although it has found no evidence showing malicious activity before the September 14 attack.

An SSL certificate for cdn.sendibt1.com was created on August 25, and Sansec found evidence suggesting attackers had gained the ability to create DNS records under Brevo-controlled infrastructure before the main attack.

The precise point at which the attackers first obtained the Cloudflare credential has not been publicly established.

The attack could hide from origin-side checks

The way the attackers used Cloudflare created another problem.

Security teams often monitor important web files for unexpected changes.

If a JavaScript file suddenly contains an unfamiliar loader or malicious domain, an integrity-monitoring system may detect that the file on disk no longer matches the expected version.

But that assumes the attacker changes the file being monitored.

Here, the modification could occur after the origin had already served the legitimate content.

The original file remained clean.

The malicious Worker changed what was delivered at the edge.

That creates two different versions of reality.

The server administrator inspecting the origin can see the legitimate file.

The visitor’s browser can receive the modified one.

Brevo said this was one reason standard integrity checks did not detect the modification.

For organisations heavily dependent on CDNs, edge functions and third-party JavaScript, that distinction is worth paying attention to.

Protecting the origin is no longer enough if another trusted layer has the ability to rewrite what leaves it.

Brevo says its core application and customer data were not affected

The scope also needs to be kept precise.

Brevo says app.brevo.com, its API, email-delivery infrastructure and customer account data were not affected by this particular compromise.

The company removed the malicious Worker and associated routes after detecting the incident.

It then revoked the compromised API key and credentials created through it, removed the hardcoded secret from the source code, deleted attacker-controlled hostnames and cleared affected edge caches.

Those containment actions stopped the compromised delivery path.

But this incident should not be confused with another Brevo security event disclosed only days earlier.

On September 10, Brevo identified a separate flaw involving the way its platform handled SAML single sign-on.

That earlier issue allowed an attacker to gain access to 138 Brevo customer accounts. Six of those accounts were used to send phishing emails, while contacts were exported from 43 accounts.

The Cloudflare compromise described here is a separate incident.

There is currently no confirmed evidence establishing that the same attacker conducted both operations.

The proximity of the incidents makes the question understandable.

It does not make the connection proven.

Website owners still have something to investigate

Brevo’s infrastructure is no longer serving the malicious code, but that does not necessarily end the incident for every downstream website.

WordPress administrators who used affected Brevo components during the September 14 window should determine whether the plugin installation attempt succeeded.

Sansec recommends reviewing web access logs for requests to WordPress’s plugin upload and activation endpoints around the attack period.

Administrators should also examine plugins installed or modified on September 14 rather than relying entirely on what appears inside the WordPress administration interface.

A malicious plugin can deliberately hide itself from the normal plugin list.

Sites should also examine their filesystem and compare the actual plugin directories against what WordPress reports through the interface.

For organisations whose users encountered the fake verification page, the investigation is different.

Anyone who followed the ClickFix instructions and executed the supplied command should treat the endpoint as potentially compromised and investigate it accordingly.

The two branches of the attack therefore leave two different questions behind:

Did a visitor execute the malicious command?

And for WordPress sites:

Did the attacker manage to leave something behind?

The real weakness was inherited trust

The Brevo incident is interesting because the individual customer websites did not necessarily have to contain a vulnerability of their own.

They trusted code supplied by another company.

That code, in turn, depended on infrastructure controlled through another privileged account.

Once the attackers reached that point in the chain, the trust flowed downstream automatically.

A website owner could have patched WordPress, used strong administrator passwords and kept their own application files completely clean and still have served malicious JavaScript during the exposure window because the browser was instructed to load code from a compromised third party.

That does not mean organisations should stop using externally hosted components.

Modern websites depend heavily on them.

But it does mean that every externally loaded script becomes part of the website’s effective security boundary.

The same applies to the infrastructure delivering those scripts.

A CDN is not simply a faster pipe between a server and a browser when it also has the ability to execute Workers, manipulate headers, change DNS and rewrite responses.

In this incident, control over that layer was enough to change what users saw without changing what Brevo stored at the origin.

The number of actual compromises remains unknown

The malicious delivery infrastructure has been removed, but several important questions remain unanswered.

There is no verified count of visitors who followed the ClickFix instructions.

There is also no verified count of WordPress websites on which the malicious plugin was successfully installed.

The figure of more than 100,000 websites describes the potential reach of Brevo’s affected components, not a confirmed victim count.

It is also unclear who obtained the Cloudflare credential, exactly how the key was exposed and whether the same attacker was responsible for Brevo’s separate SAML SSO incident days earlier.

Those details will determine whether this ultimately looks like a short-lived compromise with limited downstream infection or a much broader supply-chain intrusion whose effects continued after Brevo cleaned its own infrastructure.

For now, the most important part of the incident is already clear.

The attackers did not need to modify thousands of websites one at a time.

They compromised a place those websites already trusted.

And once malicious code had crossed that trust boundary, removing it from Brevo’s infrastructure was only half of the cleanup.

The remaining question is where it managed to stay behind.