Attaque supply chain chez Brevo : quand un prestataire marketing compromet les sites de ses clients

Ce qui s'est passé chez Brevo

Brevo, plateforme française de CRM (gestion de la relation client) et de marketing digital, a confirmé avoir été victime d'une attaque dite « supply chain » (attaque par la chaîne d'approvisionnement : les attaquants compromettent un fournisseur pour atteindre ses clients). Selon le post-mortem publié par l'entreprise, des attaquants ont dérobé une clé API Cloudflare — une clé d'accès programmatique au CDN (réseau de diffusion de contenu) utilisé par Brevo — disposant de permissions complètes sur le compte.

Point crucial : cette clé était codée en dur dans le code source d'une application, avec une durée de vie longue. Elle aurait pu être compromise dès fin août, sans qu'aucune activité malveillante antérieure n'ait été détectée. Le 14 septembre 2026, les attaquants l'ont utilisée pour créer un « Cloudflare Worker », un petit programme exécuté directement sur les serveurs du CDN, qui a réécrit à la volée le contenu servi aux visiteurs pendant environ cinq heures et demie (entre 16 h 07 et 20 h 30 UTC).

Pourquoi les clients de Brevo ont été touchés

L'attaque n'a pas seulement modifié les pages de brevo.com, sendinblue.com ou sibforms.com. Le Worker malveillant a également altéré les scripts que les clients de Brevo embarquent sur leurs propres sites : le script des formulaires Brevo, le widget de chat Brevo Conversations et les chargeurs du SDK (kit de développement) Brevo. Autrement dit, tout site intégrant ces composants a pu, pendant la fenêtre d'exposition, servir du code malveillant à ses visiteurs.

La société de sécurité Sansec, qui a détecté l'incident en premier, estime que jusqu'à 100 000 sites utilisant les composants Brevo affectés ont pu être impactés. Elle a depuis confirmé que les sous-domaines malveillants ont cessé de résoudre le 15 septembre et que les fichiers Brevo sont désormais sains.

Le mode opératoire : ClickFix et fausse page de vérification

Les visiteurs des sites touchés voyaient s'afficher une fausse page de vérification Cloudflare, suivie d'instructions dites « ClickFix » : une technique d'ingénierie sociale qui incite l'utilisateur à copier-coller et exécuter lui-même une commande sur son poste Windows, déclenchant l'installation d'un logiciel malveillant.

Sur les sites WordPress embarquant un widget Brevo affecté, le script allait plus loin : il vérifiait si le visiteur était connecté en tant qu'administrateur et tentait alors d'installer une fausse extension nommée « Web Media Optimizer ». D'après l'analyse de BleepingComputer, cette extension agit comme une porte dérobée persistante : elle se masque dans la liste des plugins, se copie dans le répertoire des extensions obligatoires (« must-use plugins »), contacte régulièrement un serveur contrôlé par les attaquants pour injecter du JavaScript malveillant dans les pages des visiteurs, et contient une clé d'authentification permettant de générer une session administrateur WordPress sans connaître le mot de passe du compte.

Pourquoi personne n'a rien vu

C'est l'un des enseignements les plus dérangeants de cet incident. Brevo l'explique elle-même : le Worker réécrivait les réponses au niveau du CDN et supprimait des en-têtes de sécurité comme la Content-Security-Policy (politique qui restreint les scripts autorisés à s'exécuter sur une page). Les serveurs d'origine et les fichiers de Brevo n'ont donc jamais été modifiés, et les contrôles d'intégrité standards n'ont rien détecté. L'infrastructure paraissait saine ; seul ce qui était livré aux visiteurs était compromis.

Brevo précise que son application app.brevo.com, son API, son infrastructure d'envoi d'e-mails et les données des comptes clients n'ont pas été affectées. Après détection, l'entreprise a supprimé le Worker et ses routes, révoqué la clé compromise et les identifiants créés avec elle, retiré la clé codée en dur de son code source, supprimé les noms d'hôte contrôlés par les attaquants et purgé ses caches.

Un contexte déjà tendu pour Brevo

Cet épisode survient quelques jours après un autre incident, distinct, lié au SSO (authentification unique) de Brevo, divulgué le 10 septembre : des attaquants avaient détourné des comptes clients pour lancer des campagnes de phishing. Le fabricant de portefeuilles de cryptomonnaies Trezor a notamment rapporté que ces attaques avaient atteint 347 000 adresses e-mail de ses utilisateurs et compromis au moins 2 500 comptes. Brevo n'a pas indiqué si les deux incidents étaient liés.

Ce que cet incident implique pour vos scripts tiers

Pour un directeur de la communication ou du marketing, la leçon dépasse largement le cas Brevo. La plupart des sites d'entreprise embarquent des dizaines de scripts tiers : outils d'analytics, gestionnaires de tags, widgets de chat, formulaires, pixels publicitaires, players vidéo. Chacun de ces scripts s'exécute dans le navigateur de vos visiteurs avec les mêmes privilèges que votre propre code. Si le fournisseur est compromis, votre site devient le vecteur de l'attaque — avec votre marque en première ligne face aux visiteurs piégés.

Quelques réflexes de gouvernance à tirer de cet incident :

• Tenir un inventaire à jour des scripts tiers présents sur vos sites : qui les a ajoutés, pourquoi, et qui en est responsable. Un tag oublié est un risque non gouverné.
• Limiter les scripts au strict nécessaire : chaque widget embarqué est une extension de votre surface d'attaque, à mettre en balance avec sa valeur métier réelle.
• Intégrer la sécurité dans l'évaluation des prestataires marketing : pratiques de gestion des secrets, communication en cas d'incident, transparence des post-mortem. L'incident Brevo montre qu'une clé API codée en dur chez un fournisseur peut suffire.
• Surveiller ce qui est réellement servi aux visiteurs, pas seulement l'intégrité de vos serveurs : dans ce cas précis, la compromission n'était visible que côté navigateur.
• Prévoir un plan de réaction : savoir désactiver rapidement un script tiers, vérifier les extensions installées, faire tourner les mots de passe administrateurs. BleepingComputer recommande d'ailleurs aux administrateurs WordPress ayant visité un site affecté le 14 septembre, en étant connectés, de vérifier les extensions installées ou activées ce jour-là et de changer leurs mots de passe.