www.it-connect.fr
Brevo Scripts Hit Customer Sites With ClickFix and a WordPress Backdoor
Do you use a Brevo form or the Brevo Conversations chat widget on your website? Be careful: on September 14, 2026, for more than four hours, these scripts displayed a fake Cloudflare verification to some visitors and tried to install a malicious extension on WordPress sites. Here is what we know about this security incident.
Who are we talking about? Brevo (formerly Sendinblue) is a French company specializing in email marketing and CRM. It is also the solution I use to send my newsletter, and it is integrated into IT-Connect through the signup form in the sidebar. In reality, it is used by tens of thousands of websites, and its JavaScript scripts are embedded across many sites: newsletter forms, live chat, marketing tracking... Through the compromise of Brevo, attackers were therefore able to try to reach its customers' websites.
This security incident was first revealed by a report published by Sansec, which mentions that the attack may affect more than 100,000 sites. For its part, Brevo published a detailed post-mortem on September 17, 2026, without giving a number. Above all, this is becoming a lot for Brevo: it is the second incident in just a few days. Indeed, on September 10, Brevo published a message about a flaw in its SAML SSO management, which was then exploited to access 138 customer accounts.
Let's go back to the most recent incident, which could have affected IT-Connect as well as thousands of other sites.
A hard-coded Cloudflare API key in the source code
It all started with a long-lived Cloudflare API key, with full permissions on the account, stored in the source code of an application. And yet, this is a known risk...! The attacker was able to get hold of this API key and then have fun with the Cloudflare configuration. In particular, they created Workers, routes, and DNS records without triggering any alert.
Cloudflare Workers, what are they? With this, code can run directly on the CDN, which makes it possible to rewrite responses on the fly and inject malicious code into them. Along the way, the Worker removed security headers, including Content-Security-Policy. As a result, "our origin servers and files remained intact", Brevo explains. It all happened while traffic passed through Cloudflare.
Here is the timeline, in UTC (remember to add two hours for France):
- 2:28 PM. The attacker deploys the Worker and tests it on low-traffic Brevo domains
- 3:01 PM. The Worker is applied to the entire brevo.com domain
- 4:07 PM. It is extended to sibforms.com and to three JavaScript files embedded by customers: the form script, the Brevo Conversations widget, and the Brevo SDK loader. According to Brevo, this is when the ClickFix lure became active
- 7:33 PM. The security incident is opened
- 8:30 PM. The Worker and its routes are removed, and the compromised key is revoked
In total, Brevo refers to an impact window of 5 hours and 29 minutes. Three and a half hours elapsed between the extension to the customer-side scripts and the opening of the incident. Brevo also says the key had been used for the first time in late August 2026, but without malicious content injection before September 14. In addition, note that the SaaS platform (app.brevo.com), the API, and email sending were not affected by this security incident.
ClickFix for visitors, a backdoor for WordPress
What happened on the websites affected by this security incident? The script displayed a full-screen Cloudflare-branded page, instructing users to press Win+R, then Ctrl+V, then Enter in order to run a malicious command. This is clearly pure ClickFix, like in the HBO Max Reddit account case I told you about this week. The command, placed in the clipboard, downloaded malware onto the Windows machine.
On WordPress sites, it was different, and it went even further. If the visitor was logged into WordPress as an administrator, the script tried to silently install and activate an extension downloaded from cdn10.sendibt1[.]com. This extension appears under the name Web Media Optimizer and acts as a persistent backdoor inside the WordPress site. If you want to check your website, look at the live server instead, including in mu-plugins.
What must be understood: this is not a WordPress vulnerability. A script loaded directly into your pages runs in the same origin as your site. It can therefore do whatever the logged-in administrator can do manually: open the add-plugin page, upload the archive to update.php, then activate the plugin. The browser sends the session cookies automatically.
What should you do if you use Brevo with WordPress?
I have a Brevo form on IT-Connect myself, so I asked myself two questions: is IT-Connect compromised? Have IT-Connect visitors been exposed? The answer to both questions is no. Here's why.
The form is generated by the official Brevo extension for WordPress. It relies on a local JavaScript file, and no resources are loaded from Brevo domains. The problem is that the SDK loader (cdn.brevo.com/js/sdk-loader.js) is injected into the header of all pages as soon as Marketing Automation tracking is enabled in the extension settings. The issue: this is one of the three compromised files. What spared IT-Connect is that I do not use this feature. So in reality, it all depends on how you integrated Brevo into your site.
On a default WordPress installation, a website may have been vulnerable if:
- The Brevo script is loaded from the site's origin. This is the case with the HTML code for the form pasted into a page, the Conversations widget, or the SDK. With an iframe, it is different because it cannot access the authenticated context.
- An administrator had a WordPress session open. Only this role can install plugins.
- An administrator loaded a page on September 14, 2026 between 4:07 PM and 8:30 PM UTC. Front end or back office, it does not matter.
Step 1: Identify the Brevo scripts loaded by your site
You can run this command on the home page, then on a page that contains your Brevo form. If it returns nothing, none of the compromised files were loaded on your site. But be careful if there is deferred JavaScript or if the page needs to be interacted with first, for example.
curl -s https://www.votre-site.fr/ | grep -oiE '(sibforms\.com|cdn\.brevo\.com|sibautomation\.com|brevo-conversations|sdk-loader)[^" ]*' | sort -uSince curl only sees the initial HTML, you can also test with the console. Open the page while logged in as an administrator, interact with it (some caching extensions delay script execution), then paste this into the browser console (F12):
[...document.scripts].map(s => s.src || s.dataset.rocketSrc || '').filter(u => /brevo|sibforms|sibautomation|sendinblue/i.test(u))An empty array means no Brevo script is present on the page. You can also filter on brevo and then sibforms in the Network tab. That is what I got on IT-Connect.
Step 2: Inspect the file system
I also recommend analyzing your file system. The malicious extension will be hidden in the administration interface, so only the disk is authoritative. From the root of your WordPress site:
# Content of the must-use plugins directory
ls -la wp-content/mu-plugins/
# Files created or modified on September 14 and 15
find wp-content/plugins wp-content/mu-plugins -type f -newermt "2026-09-14" ! -newermt "2026-09-16"
# Known markers of the backdoor
grep -rlE "Web Media Optimizer|glegchner" wp-content/The find command will also return your legitimate plugin updates during those two days, so you will need to sort through them.
Step 3: Search the web server logs
Sansec recommends looking for plugin uploads via the WordPress interface performed on September 14, 2026. With Apache on Debian, here is the command to run (daily rotation has already compressed the logs, hence the use of zgrep).
zgrep -h "14/Sep/2026" /var/log/apache2/access.log* | grep -E "update\.php\?action=upload-plugin|plugins\.php\?action=activate"The timestamp is in the server's local time: the window to watch is from 6:07 PM to 10:30 PM if your server is set to Paris time.
If you find something...
Remove the extension, both in wp-content/plugins and in wp-content/mu-plugins, then change the passwords for the administrator account (or for all admin accounts, if there is more than one). Take the opportunity to review the list of administrator accounts.
Finally, one way to limit this kind of attack in the future: SRI, for Subresource Integrity. The idea is to add the expected file hash to the script tag, and the browser refuses to execute it if the received content does not match. A file rewritten on the fly by a malicious Worker would therefore have been blocked. If you are interested in the topic, I invite you to read Mickaël's article available on IT-Connect: SRI, the integrity check for external web resources. In its post-mortem, Brevo also commits to putting in place integrity protection for its versioned embedded resources, "when technically possible", without naming the mechanism chosen. In the meantime, nothing prevents you from applying SRI to your web applications.
