Vous avez un formulaire Brevo ou le widget de chat Brevo Conversations sur votre site web ? Méfiez-vous, car le 14 septembre 2026, pendant plus de quatre heures, ces scripts ont affiché une fausse vérification Cloudflare à certains visiteurs et tenté d’installer une extension malveillante sur des sites WordPress. Voici ce que l’on sait sur cet incident de sécurité.
De qui parlons-nous? Brevo (ex-Sendinblue) est une entreprise française spécialisée dans l’e-mailing et le CRM. C’est d’ailleurs cette solution que j’utilise pour envoyer ma newsletter et elle est intégrée sur IT-Connect via le formulaire d’inscription situé dans la barre latérale. En réalité, elle est utilisée par des dizaines de milliers de sites web et ses scripts JavaScript sont intégrés sur de nombreux sites : formulaires de newsletter, chat en ligne, suivi marketing…. Ainsi, via la compromission de Brevo, les attaquants ont pu tenter d’atteindre les sites de ses clients.
Cet incident de sécurité a d’abord été révélé par un rapport publié par Sansec où il est mentionné que cette attaque pourrait concerner plus de 100 000 sites. De son côté, Brevo a publié le 17 septembre 2026 un post-mortem détaillé, sans donner de chiffre. Surtout, cela commence à faire beaucoup pour Brevo : c’est le deuxième incident en quelques jours. En effet, le 10 septembre, Brevo avait publié un message à propos d’une faille dans sa gestion du SSO SAML, exploitée alors pour accéder à 138 comptes clients.
Revenons sur l’incident le plus récent, et qui aurait pu atteindre IT-Connect tout comme des milliers d’autres sites.
Une clé d’API Cloudflare codée en dur dans le code source
Tout est parti d’une clé d’API Cloudflare à longue durée de vie, dotée de toutes les permissions sur le compte, était stockée dans le code source d’une application. C’est pourtant un risque connu…! De son côté, l’attaquant a pu mettre la main sur cette clé d’API et ainsi s’amuser avec la configuration de Cloudflare. Il a notamment créé des Workers, des routes et des enregistrements DNS sans déclencher la moindre alerte.
Cloudflare Worker, kézako ? Grâce à cela, il peut exécuter du code directement sur le CDN, ce qui permet de réécrire les réponses à la volée et d’y ajouter un script malveillant. Au passage, le Worker retirait des en-têtes de sécurité, dont Content-Security-Policy. Résultat, “nos serveurs d’origine et nos fichiers sont restés intacts”, explique Brevo. Cela s’est joué lors du passage des flux chez Cloudflare.
La chronologie, en heure UTC (pensez à ajouter deux heures pour la France) :
14h28. L’attaquant déploie le Worker et le teste sur des domaines Brevo à faible trafic
15h01. Le Worker est appliqué à l’ensemble de brevo.com
16h07. Il s’étend à sibforms.com et à trois fichiers JavaScript intégrés par les clients : le script des formulaires, le widget Brevo Conversations et le chargeur du SDK Brevo. D’après Brevo, c’est à partir de cette heure que le leurre ClickFix est actif
19h33. L’incident de sécurité est ouvert
20h30. Le Worker et ses routes sont supprimés, la clé compromise est révoquée
Au total, Brevo évoque une fenêtre d’impact de 5h29. Trois heures et demie se sont écoulées entre l’extension jusqu’aux scripts chez les clients et l’ouverture de l’incident. Brevo ajoute que la clé aurait été utilisée pour la première fois fin août 2026, sans injection de contenu malveillant avant le 14 septembre. Par ailleurs, il est à noter que le SaaS (app.brevo.com), l’API et l’envoi des e-mails ne sont pas affectés par cet incident de sécurité.
ClickFix pour les visiteurs, une porte dérobée pour WordPress
Que s’est-il passé sur les sites web concernés par cet incident de sécurité ? Le script affichait une page plein écran aux couleurs de Cloudflare, invitant à presser Win+R, puis Ctrl+V, puis Entrée afin d’exécuter une commande malveillante. C’est clairement du ClickFix pur jus, comme dans l’affaire du compte Reddit de HBO Max dont je vous parlais cette semaine. La commande, placée dans le presse-papiers, téléchargeait un malware sur la machine Windows.
Sur les sites WordPress, c’était différent, et ça allait même encore plus loin. Si le visiteur était connecté à WordPress en tant qu’administrateur, le script tentait d’installer et d’activer silencieusement une extension, téléchargée depuis cdn10.sendibt1[.]com. Cette extension se présente avec le nom Web Media Optimizer et agit comme une porte dérobée persistante au sein du site WordPress. Si vous souhaitez vérifier votre site web, regardez plutôt sur le serveur en direct, y compris dans les mu-plugins.
Ce qu’il faut bien comprendre : ce n’est pas une faille de WordPress. Un script chargé directement dans vos pages s’exécute dans la même origine que votre site. Il peut donc faire ce que l’administrateur connecté peut faire à la main : ouvrir la page d’ajout d’extension, envoyer l’archive vers update.php, puis activer l’extension. Le navigateur joint les cookies de session tout seul.
Que faire si vous utilisez Brevo avec WordPress ?
J’ai moi-même un formulaire Brevo sur IT-Connect, je me suis donc posé deux questions : IT-Connect est-il compromis ? Les visiteurs d’IT-Connect ont-ils été exposés ? La réponse à ces deux questions est non. Je vous explique pourquoi.
Le formulaire est généré par l’extension officielle Brevo pour WordPress. Il s’appuie sur un fichier JavaScript local, et aucune ressource n’est chargée depuis les domaines de Brevo. Le problème, c’est que le chargeur du SDK (cdn.brevo.com/js/sdk-loader.js), est injecté dans l’en-tête de toutes les pages dès que le suivi Marketing Automation est activé dans les paramètres de l’extension. Problème : c’est l’un des trois fichiers piégés. Ce qui a épargné IT-Connect, c’est que je n’utilise pas cette fonctionnalité. Donc en réalité, tout dépend de la façon dont vous avez intégré Brevo à votre site.
Sur une installation par défaut de WordPress, un site web a pu être vulnérable si :
Le script Brevo est chargé dans l’origine du site. C’est le cas avec le code HTML du formulaire collé dans une page, le widget Conversations ou le SDK. Avec une iframe, c’est différent car il ne peut pas accéder au contexte avec authentification.
Un administrateur a ouvert une session WordPress. Seul ce rôle peut installer des extensions.
Un administrateur a chargé une page du site le 14 septembre 2026 entre 16h07 et 20h30 UTC. Front ou back-office, peu importe.
Étape 1 : identifier les scripts Brevo chargés par votre site
Vous pouvez lancer cette commande sur la page d’accueil, puis sur une page qui contient votre formulaire Brevo. Si elle ne retourne rien, aucun des fichiers piégés n’était chargé chez vous. Mais attention tout de même s’il n’y a pas du JS différé ou s’il faut tout d’abord interagir avec la page, par exemple.
curl -s https://www.votre-site.fr/ | grep -oiE ‘(sibforms\.com|cdn\.brevo\.com|sibautomation\.com|brevo-conversations|sdk-loader)[^” ]*’ | sort -u
Comme curl ne voit que le HTML initial, vous pouvez aussi tester avec la console. Ouvrez la page en étant connecté en administrateur, interagissez avec elle (certaines extensions de cache retardent l’exécution des scripts), puis collez ceci dans la console du navigateur (F12) :
[…document.scripts].map(s => s.src || s.dataset.rocketSrc || ”).filter(u => /brevo|sibforms|sibautomation|sendinblue/i.test(u))
Un tableau vide signifie qu’aucun script Brevo n’est présent dans la page. Vous pouvez aussi filtrer sur brevo puis sibforms dans l’onglet Réseau. C’est ce que j’ai obtenu sur IT-Connect.
Étape 2 : inspecter le système de fichiers
Je vous invite aussi à analyser votre système de fichiers. L’extension malveillante sera masquée dans l’interface d’administration, donc seul le disque fait foi. Depuis la racine de votre site WordPress :
# Contenu du répertoire des extensions must-use
ls -la wp-content/mu-plugins/
# Fichiers créés ou modifiés les 14 et 15 septembre
find wp-content/plugins wp-content/mu-plugins -type f -newermt “2026-09-14” ! -newermt “2026-09-16”
# Marqueurs connus de la backdoor
grep -rlE “Web Media Optimizer|glegchner” wp-content/
Le find remontera aussi vos mises à jour d’extensions légitimes sur ces deux jours, à vous de faire le tri.
Étape 3 : fouiller les journaux du serveur Web
Sansec recommande de rechercher les uploads d’extension via l’interface de WordPress effectués en date du 14 septembre 2026. Avec Apache sur Debian, voici la commande à exécuter (la rotation quotidienne a déjà compressé les logs, d’où le zgrep).
zgrep -h “14/Sep/2026” /var/log/apache2/access.log* | grep -E “update\.php\?action=upload-plugin|plugins\.php\?action=activate”
L’horodatage est en heure locale du serveur : la fenêtre à surveiller va de 18h07 à 22h30 si votre serveur est à l’heure de Paris.
Si vous trouvez quelque chose…
Supprimez l’extension, dans wp-content/plugins comme dans wp-content/mu-plugins, puis modifiez les mots de passe du compte administrateur (ou de tous les comptes admins, s’il y en a plusieurs). Profitez-en pour passer en revue la liste des comptes administrateurs.
Enfin, une piste pour limiter ce genre d’attaque à l’avenir : le SRI, pour Subresource Integrity. Le principe est d’ajouter à la balise script l’empreinte attendue du fichier, et le navigateur refuse de l’exécuter si le contenu reçu ne correspond pas. Un fichier réécrit à la volée par un Worker malveillant aurait donc été bloqué. Si le sujet vous intéresse, je vous invite à lire l’article de Mickaël disponible sur IT-Connect : SRI, le contrôle d’intégrité des ressources web externes. Dans son post-mortem, Brevo s’engage d’ailleurs à mettre en place une protection d’intégrité pour ses ressources embarquées versionnées, “quand c’est techniquement possible”, sans nommer le mécanisme retenu. En attendant, rien ne vous empêche d’appliquer le SRI sur vos applications web.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.