www.it-connect.fr
Brevo Scripts Hijacked to Push ClickFix Attacks 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 check 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 on IT-Connect through the signup form located in the sidebar. In practice, it is used by tens of thousands of websites, and its JavaScript scripts are embedded on many sites: newsletter forms, live chat, marketing tracking.... As a result, by compromising Brevo, attackers were able to attempt to reach its customers' websites.
This security incident was first revealed in a report published by Sansec, which states that the attack could affect more than 100,000 sites. Brevo, for its part, published a detailed post-mortem on September 17, 2026, without giving a number. More importantly, this is becoming a lot for Brevo: it is the second incident in just a few days. On September 10, Brevo had already published a message about a flaw in its SAML SSO handling, which was then exploited to access 138 customer accounts.
Let's go back to the most recent incident, which could have affected IT-Connect just like thousands of other sites.
A hardcoded Cloudflare API key in the source code
It all started with a long-lived Cloudflare API key with full account permissions stored in an application's source code. And yet this is a known risk...! The attacker was able to get hold of this API key and have fun with Cloudflare's configuration. In particular, they created Workers, routes, and DNS records without triggering any alert.
Cloudflare Worker, what is that? With this, code can be executed directly on the CDN, which makes it possible to rewrite responses on the fly and add a malicious script to them. Along the way, the Worker removed security headers, including Content-Security-Policy. As a result, "our origin servers and files remained untouched," Brevo explains. It happened while traffic was passing through Cloudflare.
Timeline, in UTC (remember to add two hours for France):
- 2:28 p.m. The attacker deploys the Worker and tests it on low-traffic Brevo domains
- 3:01 p.m. The Worker is applied to all of brevo.com
- 4:07 p.m. It expands to sibforms.com and to three JavaScript files embedded by customers: the forms script, the Brevo Conversations widget, and the Brevo SDK loader. According to Brevo, this is when the ClickFix lure became active
- 7:33 p.m. The security incident is opened
- 8:30 p.m. The Worker and its routes are removed, and the compromised key is revoked
Overall, Brevo refers to an impact window of 5 hours and 29 minutes. Three and a half hours passed between the extension to customer scripts and the opening of the incident. Brevo adds that the key was apparently used for the first time at the end of August 2026, without malicious content being injected before September 14. In addition, the SaaS platform (app.brevo.com), the API, and email delivery 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 page in Cloudflare's colors, asking users to press Win+R, then Ctrl+V, then Enter in order to execute a malicious command. This is classic ClickFix, just 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 in to WordPress as an administrator, the script attempted to silently install and activate a plugin downloaded from cdn10.sendibt1[.]com. This plugin 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 directly on the live server, including in mu-plugins.
What is important to understand is that 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 what the logged-in administrator can do manually: open the add-plugin page, upload the archive to update.php, then activate the plugin. The browser automatically attaches the session cookies.
What should you do if you use Brevo with WordPress?
I have a Brevo form on IT-Connect myself, so I asked two questions: is IT-Connect compromised? Were IT-Connect visitors exposed? The answer to both questions is no. Here's why.
The form is generated by the official Brevo plugin 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 every page as soon as Marketing Automation tracking is enabled in the plugin settings. The issue: this is one of the three tampered 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 could have been vulnerable if:
- The Brevo script is loaded in 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 was logged into WordPress. Only this role can install plugins.
- An administrator loaded a page of the site on September 14, 2026 between 4:07 p.m. and 8:30 p.m. 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 tampered files was loaded on your site. But be careful if there is no deferred JS or if user interaction is required 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 cache 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 that no Brevo script is present in the page. You can also filter on brevo 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 plugin 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 backdoor markers
grep -rlE "Web Media Optimizer|glegchner" wp-content/The find command will also show your legitimate plugin updates over those two days, so you will need to sort through the results.
Step 3: dig through the web server logs
Sansec recommends searching for plugin uploads through the WordPress interface performed on September 14, 2026. With Apache on Debian, here is the command to run (daily log 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 p.m. to 10:30 p.m. if your server is on Paris time.
If you find something...
Delete the plugin, both in wp-content/plugins and in wp-content/mu-plugins, then change the passwords of the administrator account (or of all admin accounts, if there are several). Take the opportunity to review the list of administrator accounts.
Finally, one way to limit this kind of attack in the future is SRI, for Subresource Integrity. The idea is to add the expected fingerprint of the file 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, web external resource integrity checking. In its post-mortem, Brevo also commits to implementing 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.
