Brevo Supply-Chain Attack: Clean Files, Malicious Delivery
Brevo's CDN served malicious JavaScript to 100K+ sites while origin files stayed clean. How the attack worked and what businesses should verify now.
On September 14, 2026, attackers compromised Brevo’s content delivery infrastructure and injected malicious JavaScript into scripts embedded on an estimated 100,000+ customer websites. The attack ran for roughly four hours before Brevo contained it.
What made this incident unusual was the disconnect between what Brevo stored and what browsers actually received. Origin servers were never modified. File integrity checks returned clean. Last-Modified headers stayed unchanged. Every standard server-side detection mechanism reported nothing wrong.
The malicious code was injected at the CDN edge by a rogue Cloudflare Worker, and it stripped Content-Security-Policy headers on the way out.
Key takeaways
- Origin files and server-side integrity checks were clean throughout the attack.
- A compromised Cloudflare API key allowed the attacker to deploy a Worker that rewrote responses at the CDN edge.
- The Worker also stripped Content-Security-Policy headers, preventing browser-side enforcement.
- Two payloads were delivered: ClickFix social engineering for general visitors and a persistent WordPress backdoor for logged-in administrators.
- Subresource Integrity (SRI) was not implemented on Brevo’s vendor scripts, so browsers had no way to detect the tampering.
Stored reality vs. delivered reality
The core of this attack was a gap between what existed on Brevo’s servers and what reached end users. A Cloudflare Worker intercepted responses at the edge and rewrote them before delivery.
Stored reality
Source files on Brevo's servers were never altered. File hashes matched known-good versions. Last-Modified timestamps stayed unchanged. Server-side WAFs and malware scanners reported no anomalies.
Delivered reality
Browsers received modified JavaScript with appended loader functions that pulled malware from attacker-controlled domains. Content-Security-Policy headers were stripped from every response. No origin-level check could detect the difference.
This is the scenario that makes supply-chain attacks against CDN infrastructure particularly difficult to detect. The attacker never needed to touch the source code, the build pipeline, or the origin servers. Control of the delivery layer was enough.
How the attack worked
The root cause was a long-lived Cloudflare API key with full account permissions, hardcoded in Brevo’s application source code. The key gave the attacker authority to create Workers, routes, and DNS records across every Brevo zone.
1. Credential acquisition
The attacker obtained the hardcoded API key. Brevo’s post-mortem confirms the key had full account permissions and was embedded in application source. The key was first misused in late August 2026, when an SSL certificate was created for the attacker domain sendibt1.com.
2. Worker deployment
On September 14, the attacker deployed a Cloudflare Worker across Brevo’s production zones. The Worker intercepted HTTP responses for several Brevo-hosted JavaScript files:
cdn.brevo.com/js/sdk-loader.js(tracking script)conversations-widget.brevo.com/brevo-conversations.js(chat widget)- Signup forms script hosted on
sibforms.com
3. Edge-level code injection
The Worker appended loader functions to each JavaScript file during delivery. These loaders pulled the primary malware payload from attacker-controlled subdomains of sendibt1.com. The Worker also stripped CSP headers from every response, ensuring browsers could not block the injected resources.
4. Payload delivery
Two distinct payloads were served depending on the visitor:
General visitors received a ClickFix social engineering overlay that mimicked a Cloudflare “Verify you are human” prompt. The overlay placed a malicious command on the visitor’s clipboard and instructed them to paste and execute it. The script included targeting logic that skipped bots, scanners, and developer user agents to avoid detection.
WordPress administrators with active sessions were targeted silently. The payload detected WordPress admin sessions and uploaded a malicious plugin called “Web Media Optimizer” through the standard WordPress plugin upload endpoint. The backdoor hid itself from the WordPress plugin dashboard, copied itself into the must-use plugins folder for persistence, maintained a hardcoded key for passwordless admin session creation, and contacted a command-and-control server for updated injection scripts.
What code did our users actually receive?
That is the question every organization embedding third-party scripts should be able to answer, and the one this attack made unanswerable from the server side alone.
Timeline
| Time (UTC), Sep 14 | Event |
|---|---|
| 15:01 | brevo.com begins serving injected scripts |
| 16:04 | Last clean version of sdk-loader.js observed |
| 16:05 | First malicious sdk-loader.js detected (Sansec) |
| ~16:07 | Customer-embedded scripts begin delivering payload |
| 19:33 | Brevo opens incident response ticket |
| 20:12 | Last malware activity from Brevo domains |
| ~20:30 | Brevo removes malicious Worker and revokes API key |
Active injection window for customer-embedded scripts: approximately four hours and five minutes.
Was my website affected by the Brevo attack?
Investigation is warranted if, during the September 14 window (approximately 16:07–20:12 UTC), your organization:
- Loaded any of the affected Brevo scripts (
sdk-loader.js,brevo-conversations.js, or thesibforms.comsignup script) on customer-facing pages - Used Brevo forms, Conversations widgets, tracker or SDK integrations, or other embedded Brevo scripts
- Had a WordPress administrator visit any site loading affected Brevo assets while authenticated
- Had a Windows user interact with a ClickFix-style “Verify you are human” prompt and follow the clipboard instructions
- Cannot confirm whether an affected Brevo resource was loaded during that window
If none of these apply, your environment was likely not exposed. If any apply, work through the verification steps below.
Important context: Potential exposure does not equal confirmed compromise. Sansec’s estimate of 100,000+ sites refers to sites that may have loaded the affected assets, not 100,000+ confirmed infections. An inability to reproduce the malicious page after the incident does not prove the page was never served during the active window.
Even if your organization does not use Brevo, this attack pattern applies to any third-party JavaScript embedded on your sites. If you do use Brevo scripts, the steps below are more urgent.
1. Check for the WordPress backdoor
If any WordPress site in your environment embedded Brevo scripts and a WordPress administrator visited that site between 15:00 and 20:30 UTC on September 14:
- Search for a plugin named “Web Media Optimizer” in
wp-content/plugins/andwp-content/mu-plugins/. - Review
POSTrequests to/wp-admin/update.php?action=upload-pluginin server logs for that date. - Check for connections to the command-and-control domain
glegchner.com.
The WordPress backdoor persists independently of Brevo. Removing the Brevo script does not remove an installed backdoor. While investigating, also confirm that WordPress core itself is current.
2. Audit third-party script controls
Review which vendor scripts are loaded on your sites and how they are controlled:
- Subresource Integrity (SRI): Do your
<script>tags includeintegrityattributes? SRI allows the browser to verify that a fetched resource has not been altered. This attack would have been blocked by SRI on the Brevo script tags. - Content Security Policy: Is your site’s CSP enforced at the origin and not solely dependent on the vendor’s headers? The attacker stripped Brevo’s CSP headers at the edge.
- Script inventory: Do you maintain a list of every third-party script loaded on your sites, who controls each one, and what access each has?
3. Review your own credential hygiene
The attack started with a hardcoded API key that had full account permissions. Review your own infrastructure for:
- API keys or tokens embedded in source code.
- Long-lived credentials with permissions broader than necessary.
- CDN or DNS provider credentials without rotation policies.
4. Verify monitoring coverage
Traditional file integrity monitoring and server-side WAFs did not detect this attack. Confirm whether your monitoring would catch a similar edge-level injection:
- Does your monitoring compare what the origin serves with what browsers actually receive?
- Are CSP violation reports collected and reviewed?
- Would an unexpected script domain in your CSP report trigger an alert?
The Infonaligy perspective
This incident reinforces a gap that many organizations have not addressed: the difference between verifying what you publish and verifying what your users receive. Server-side controls alone are not sufficient when the delivery layer can be independently compromised.
Organizations should be able to confirm:
- Which third-party scripts are loaded on their sites and what each one does.
- Whether Subresource Integrity is enforced for externally hosted scripts.
- Whether Content Security Policy is set at the origin and not dependent on vendor headers.
- Whether monitoring covers the gap between origin responses and browser-delivered content.
- Whether credential storage practices prevent the kind of hardcoded key that enabled this attack.
Infonaligy’s SOC Services and Threat and Vulnerability Assessments help organizations evaluate third-party script exposure, monitor for supply-chain indicators, and validate that what reaches end users matches what was intended.
Primary sources
- Brevo security update, September 17, 2026 (official post-mortem)
- Sansec: Brevo supply chain attack hits 100K+ sites (technical analysis)
Frequently asked questions
No. Brevo confirmed that origin servers, application source files, and the Brevo application itself were not modified. The malicious code was injected by a Cloudflare Worker at the CDN edge, meaning it only existed in responses delivered to browsers. This is why server-side file integrity checks, malware scanners, and WAFs reported no anomalies throughout the incident.
Customer-embedded scripts delivered malicious payloads for approximately four hours and five minutes on September 14, 2026 (roughly 16:07 to 20:12 UTC). The window is defined by the first observed malicious response from Sansec's monitoring and the last recorded malware activity before Brevo removed the Worker. Not every site loading Brevo scripts was necessarily served the malicious payload during this entire window.
Yes. If sites embedding Brevo scripts had included SRI integrity attributes on their script tags, browsers would have rejected the modified files because the delivered hash would not have matched the expected value. SRI is a client-side defense that works regardless of where tampering occurs: origin, CDN edge, or anywhere in between. Brevo's scripts did not use SRI, and most sites embedding third-party vendor scripts do not implement it.
No. The "Web Media Optimizer" plugin was installed independently on affected WordPress sites through the standard plugin upload endpoint. It persists in both the regular plugins directory and the must-use plugins folder regardless of whether Brevo scripts remain on the site. The backdoor must be found and removed separately. It also includes a hardcoded key for passwordless admin session creation and a command-and-control connection.
No CVE has been assigned. The attack exploited stolen credentials and Cloudflare account access rather than a software vulnerability in a catalogued product. Supply-chain attacks that exploit compromised infrastructure credentials typically do not receive CVEs because there is no patchable defect in a specific software version. Brevo's post-mortem described the root cause as a hardcoded API key with full account permissions.
If your organization embeds third-party scripts and cannot verify what code your visitors actually receive, that gap is worth closing before the next supply-chain incident. Infonaligy can help assess your exposure and implement the right controls.