A compromise of Brevo's cloud infrastructure has demonstrated how a single stolen API credential can turn a trusted third-party service into a large-scale supply-chain attack platform.
On September 14, 2026, attackers used a compromised Cloudflare API key belonging to Brevo to deploy a malicious Cloudflare Worker. The Worker modified content delivered through Brevo's infrastructure and injected malicious JavaScript into websites using Brevo's embedded services.
Security researchers at Sansec estimate that more than 100,000 websites may have been affected.
The incident is particularly significant because visitors did not necessarily have to interact directly with Brevo. A website they trusted could load a compromised Brevo script and become the delivery mechanism for the attack.
What happened?
Brevo's investigation found that an attacker obtained a long-lived Cloudflare API key with full account permissions.
The key had been stored in application source code. According to Brevo, the attacker could use it to create Cloudflare Workers, routes and DNS records without triggering an alert.
On September 14, the attacker deployed a malicious Worker.
Rather than modifying Brevo's original website files, the Worker modified HTTP responses at the Cloudflare edge, meaning malicious content could be inserted while traffic was being delivered to visitors.
Brevo says the malicious Worker was active for approximately five and a half hours, from 15:01 to 20:30 UTC, with the affected embedded JavaScript assets being modified from approximately 16:07 UTC.
This distinction is important: the company's origin systems and source files were not necessarily altered. The malicious content was inserted during delivery.
How did the supply-chain attack work?
The attack relied on software that thousands of websites had already chosen to trust.
Brevo provides services such as forms, tracking and customer-conversation functionality through JavaScript components embedded into customer websites.
The compromised Worker modified several of these assets.
Researchers observed malicious code being added to Brevo's SDK loader and Conversations components, which are loaded by customer websites. Sansec reported evidence of the injected scripts being served through Brevo-controlled domains and embedded assets.
This created a classic supply-chain scenario:
Brevo infrastructure → trusted JavaScript component → customer website → website visitor
An attacker did not need to compromise every individual website.
Compromising the shared service created a potential path to many websites simultaneously.
The ClickFix attack
The malicious JavaScript was not simply a conventional malware download.
Instead, selected visitors were shown a convincing fake Cloudflare "verify you are human" page.
The page instructed users to:
- Press Win + R
- Press Ctrl + V
- Press Enter
The clipboard contained a command prepared by the malicious script.
Running it could download and execute malware on the visitor's Windows computer.
This is the ClickFix social-engineering technique, where victims are persuaded to execute commands themselves under the pretext of completing a security verification or fixing a browser problem.
Brevo confirmed this behavior in its post-incident investigation.
The attack was also selective. Brevo says the malicious page was shown only to selected visitors, meaning many people who visited an affected page may not have seen the fake verification screen.
WordPress sites faced an additional risk
The attack had another component targeting WordPress administrators.
According to Brevo, if a visitor was logged into a WordPress website as an administrator and the site loaded an affected Brevo widget, the injected code attempted to silently install and activate a malicious WordPress plugin.
Independent analysis by BleepingComputer found that the malicious plugin presented itself as a legitimate-sounding plugin called "Web Media Optimizer", but behaved as a persistent backdoor.
This significantly increases the potential impact for websites whose administrators visited their own sites during the attack window.
Why more than 100,000 websites?
The reported figure does not mean that 100,000 websites were individually hacked at their origin servers.
Instead, researchers found that the compromised Brevo scripts were embedded across a very large number of websites.
Sansec estimated that more than 100,000 customer websites were potentially exposed to the malicious delivery mechanism.
This is one of the defining characteristics of a supply-chain attack.
A company may have strong security controls around its own website while still depending on dozens or hundreds of external JavaScript libraries, SaaS platforms, analytics services and widgets.
If one trusted provider is compromised, its customers can inherit the attack.
Brevo's API and customer data were not compromised in this incident
It is important to distinguish the supply-chain incident from a conventional customer-data breach.
Brevo says that:
- app.brevo.com was not affected
- The Brevo API was not affected
- Email sending was not affected
- Customer account data held by Brevo was not affected
- The malicious content was inserted at the CDN edge rather than into Brevo's source systems
This means the primary risk from the September 14 incident was malicious content delivery, rather than attackers downloading Brevo's entire customer database.
A separate Brevo security incident came first
There is an additional piece of context worth highlighting.
On September 10, four days before the Cloudflare Worker incident, Brevo disclosed a separate security issue involving SAML SSO.
Brevo said an attacker exploited a flaw in its SSO implementation and gained access to 138 Brevo accounts. Six accounts were used to send phishing emails, while contact data was exported from 43 accounts. Brevo said it closed the access route and signed users out of the platform.
The September 14 Cloudflare incident involved a different access mechanism: a compromised Cloudflare API key.
The two incidents should therefore not be presented as one single technical exploit, although they occurred within the same week and both affected Brevo's security posture.
Why the API key was so important
The incident highlights a common cloud-security problem: an API key can be as powerful as a password — and sometimes considerably more dangerous.
The compromised credential reportedly had full Cloudflare account permissions.
That allowed the attacker to:
- Create Cloudflare Workers
- Modify routing
- Create DNS records
- Control how content was delivered from Brevo's domains
The credential was also long-lived and stored in source code.
This combination created a particularly dangerous situation:
Long-lived credential + excessive permissions + source-code exposure + insufficient monitoring = infrastructure takeover
Why traditional integrity monitoring could miss the attack
One of the most interesting technical aspects of the incident is that the attack operated at the edge.
Brevo says the malicious Worker rewrote responses before they reached users and removed security headers such as Content-Security-Policy.
Because the original files on Brevo's servers were not modified, conventional file-integrity monitoring could remain unaware of the injected content.
This is an important lesson for modern cloud environments.
Checking whether files on an origin server have changed is no longer necessarily enough.
Companies also need visibility into:
- CDN configuration
- Edge functions
- Cloudflare Workers
- DNS changes
- Routing rules
- API credentials
- Third-party JavaScript
- Runtime behavior in browsers
What Brevo has done
Brevo says it has:
- Removed the malicious Worker and routes
- Deleted attacker-created hostnames
- Revoked the compromised API key and credentials created with it
- Purged edge caches
- Removed the hardcoded credential from source code
- Replaced it with narrowly scoped, short-lived tokens
- Reviewed Cloudflare account credentials and members
- Added monitoring for Cloudflare audit events
- Begun streaming Cloudflare logs into its security monitoring platform
- Started reviewing third-party edge configurations
Brevo also says it is adopting HashiCorp Vault as the central storage location for Cloudflare keys and tokens, with automatic rotation.
What website owners should do
Companies using Brevo's embedded scripts should treat the incident as a potential supply-chain exposure.
✅ Review WordPress administrator activity
If a WordPress administrator visited the site on September 14, check for unexpected plugins installed or activated that day.
Brevo specifically recommends reviewing WordPress installations for this activity.
✅ Search for unauthorized changes
Review:
- New WordPress plugins
- New administrator accounts
- Modified PHP files
- Scheduled tasks
- Unknown JavaScript
- Unexpected redirects
- Changes to
.htaccess - Recently modified website files
✅ Rotate important credentials
If a website may have been compromised, rotate:
- WordPress administrator passwords
- Hosting credentials
- SSH credentials
- Database passwords
- API keys
- Cloud credentials
- Other secrets accessible from the affected website
✅ Check visitors who may have executed ClickFix commands
If an employee or customer was shown the fake Cloudflare verification and actually executed the requested command, that endpoint should be treated as potentially compromised.
Brevo recommends disconnecting the computer, performing a full antivirus scan and changing passwords used on that machine.
✅ Review third-party JavaScript
This incident is a reminder to maintain an inventory of external scripts loaded by company websites.
For each third-party component, companies should know:
- Who operates it
- What data it can access
- Where it is loaded from
- What permissions it has
- How quickly it can be disabled
- How changes to it are monitored
The bigger cybersecurity lesson
The Brevo incident demonstrates why software supply-chain security is no longer limited to libraries and package repositories.
Cloud platforms, SaaS providers, CDN configurations, embedded JavaScript and third-party widgets can all become part of an application's trusted execution path.
A website may be fully patched and have no compromised files, yet still deliver malware because a trusted external script has been altered.
That makes third-party dependencies a security boundary.
The attack also shows the danger of combining powerful cloud credentials with long lifetimes and broad permissions. A single API key was sufficient to give attackers control over the delivery layer of a major service.
Final thoughts
The Brevo incident was particularly effective because it exploited trust.
Visitors trusted the websites they were visiting. Website owners trusted Brevo's JavaScript. Brevo's infrastructure trusted a powerful API credential.
The attackers ultimately attempted to turn that chain of trust into a malware distribution network.
Every third-party script, SaaS integration and cloud API credential is part of the security boundary. Companies need short-lived, least-privileged credentials, strong monitoring of cloud changes and a clear inventory of every external component their websites depend on.
