Avis de sécurité de septembre 2026

Brevo a divulgué deux incidents de sécurité distincts en septembre 2026 impliquant sa plateforme client et son infrastructure.

Le premier concernait un accès non autorisé à 138 comptes clients Brevo, plusieurs comptes ayant ensuite été utilisés pour distribuer des emails de phishing via l’infrastructure légitime de Brevo.

Quelques jours plus tard, une compromission distincte impliquant l’environnement Cloudflare de Brevo a entraîné la diffusion de JavaScript malveillant via des sites web contrôlés par Brevo et des ressources intégrées par les clients.

Des chercheurs en sécurité indépendants estiment que le second incident aurait pu atteindre plus de 100 000 sites web utilisant des composants Brevo.

Ensemble, ces incidents mettent en lumière une réalité de plus en plus importante pour les organisations qui s’appuient sur des plateformes tierces d’email et de marketing :

Une infrastructure de confiance peut toujours devenir un canal d’attaque lorsque les systèmes ou les comptes qui la contrôlent sont compromis.

Ils soulèvent également une question importante pour les organisations dont les domaines restent configurés avec DMARC à p=none :

Votre domaine applique-t-il réellement une protection contre l’utilisation non autorisée, ou se contente-t-il de la surveiller ?

I. Que s’est-il passé chez Brevo ?

Brevo a divulgué deux incidents de sécurité distincts en septembre 2026.

Incident 1 : Compromission de comptes SAML SSO

Le 10 septembre 2026, Brevo a identifié un problème de sécurité concernant son implémentation de l’authentification unique SAML.

Selon le rapport d’incident officiel de Brevo, un attaquant a exploité un problème de limite d’autorisation pour accéder à :

138 comptes clients Brevo

Brevo a rapporté que :

• 6 comptes ont été utilisés pour envoyer des emails de phishing.
• Des contacts ont été exportés de 43 comptes.
• 93 comptes n’ont montré aucune activité significative de l’attaquant.

Brevo a identifié le problème vers 06h30 UTC le 10 septembre et a déclaré que la voie d’accès avait été fermée vers 08h30 UTC.

L’entreprise a également déconnecté tous les utilisateurs actifs sur sa plateforme.

Selon Brevo, l’attaquant a créé un compte Brevo, configuré le SSO et invité des utilisateurs légitimes de Brevo dans cet environnement.

Le problème s’est produit car l’authentification via la configuration SSO d’une organisation n’était pas correctement restreinte à cette organisation.

Au lieu de cela, l’attaquant pouvait accéder à d’autres organisations auxquelles ces utilisateurs invités pouvaient accéder.

Brevo a décrit la cause racine comme une limite d’autorisation qui n’avait pas été correctement appliquée.

II. Le phishing a été envoyé via l’infrastructure légitime de Brevo

L’un des aspects les plus importants de la divulgation de Brevo est que les messages de phishing n’étaient pas simplement des messages usurpés envoyés depuis une infrastructure non liée.

Ils ont été envoyés via l’infrastructure légitime de Brevo.

Brevo a explicitement déclaré que :

Les messages ont passé les vérifications d’authentification email normales car ils provenaient d’une infrastructure légitime.

Cette distinction est cruciale.

SPF, DKIM et DMARC peuvent déterminer si un email est techniquement authentifié.

Ils répondent à des questions telles que :

• Ce serveur était-il autorisé à envoyer ?
• Le message était-il signé cryptographiquement ?
• Le domaine d’envoi authentifié correspond-il au domaine visible dans le champ De ?

Mais ils ne peuvent pas répondre à :

Le compte autorisé lui-même était-il contrôlé par un attaquant ?

Si un attaquant compromet un compte légitime sur une plateforme autorisée et envoie des messages via une infrastructure correctement configurée, les messages résultants peuvent réussir les vérifications SPF, DKIM et DMARC.

C’est pourquoi l’authentification email doit être considérée comme une couche d’une architecture de sécurité email plus large.

III. Un second incident Brevo a suivi quatre jours plus tard

Le 14 septembre 2026, Brevo a connu un second incident de sécurité techniquement différent.

Brevo a confirmé qu’un attaquant avait obtenu une clé API Cloudflare de longue durée avec des permissions complètes sur le compte.

Selon Brevo, cette information d’identification avait été stockée dans le code source de l’application.

L’attaquant a utilisé la clé API compromise pour déployer un Cloudflare Worker malveillant dans l’environnement de Brevo.

Ce Worker était capable de modifier le trafic passant par l’infrastructure CDN de Brevo.

Pendant environ cinq heures et demie, du JavaScript malveillant a été injecté dans :

• brevo.com
• sendinblue.com
• Les pages de connexion, de compte et d’intégration de Brevo
• sibforms.com
• Les formulaires Brevo
• Les widgets Brevo Conversations
• Les chargeurs SDK Brevo
• Les fichiers JavaScript intégrés par les clients Brevo sur leurs propres sites web

Brevo a rapporté que la fenêtre d’impact principale a duré approximativement de :

15h01 UTC jusqu’à 20h30 UTC le 14 septembre.

L’attaque ClickFix

Les visiteurs affectés par le JavaScript malveillant pouvaient voir une fausse page de vérification Cloudflare.

La page demandait aux utilisateurs Windows d’effectuer des actions incluant :

1. Appuyer sur Win + R
2. Coller une commande
3. Exécuter cette commande

Suivre ces étapes entraînait le téléchargement de malware sur l’ordinateur de la victime.

Cette technique est communément appelée ClickFix.

Brevo a également rapporté que, sur les sites web WordPress intégrant des composants Brevo affectés, le script malveillant tentait d’installer et d’activer un plugin lorsqu’un administrateur WordPress connecté visitait le site.

Brevo a supprimé le Cloudflare Worker malveillant, révoqué les informations d’identification compromises, supprimé les noms d’hôtes contrôlés par l’attaquant et purgé les caches edge affectés.

L’entreprise a déclaré que les scripts compromis sont désormais sûrs à utiliser.

IV. Plus de 100 000 sites web potentiellement exposés

Brevo n’a pas publié de nombre exact de sites web clients ayant chargé le JavaScript affecté.

Cependant, une recherche de sécurité indépendante de Sansec a estimé que les composants intégrés de Brevo étaient présents sur plus de 100 000 sites web.

Cela ne signifie pas que 100 000 sites web ont nécessairement été compromis ou que chaque visiteur a reçu un malware.

Le contenu malveillant a été diffusé de manière sélective.

Cependant, l’empreinte potentielle de distribution démontre l’effet d’amplification créé lorsqu’une infrastructure JavaScript tierce de confiance est compromise.

Il s’agit d’un risque classique de chaîne d’approvisionnement.

Au lieu de compromettre les organisations individuelles une par une, un attaquant peut compromettre une infrastructure que des milliers d’organisations font déjà confiance.

V. Deux incidents, deux problèmes de sécurité différents

Il est important de ne pas combiner techniquement les deux incidents.

Ils ont impliqué des voies d’attaque différentes.

10 septembre

Vecteur d’attaque : Faille d’autorisation SAML SSO

Impact : Accès non autorisé à 138 comptes clients

Résultat : Emails de phishing envoyés via des comptes clients Brevo légitimes et données de contacts exportées de certains comptes

14 septembre

Vecteur d’attaque : Identifiants API Cloudflare compromis

Impact : JavaScript malveillant injecté dans les sites web Brevo et les ressources intégrées par les clients

Portée potentielle : Plus de 100 000 sites web selon des recherches de sécurité indépendantes

Résultat : Diffusion de malware ClickFix et tentative de persistance WordPress

VI. Quel est le rapport avec DMARC ?

Aucun des incidents n’a été causé par DMARC.

Et aucun des incidents ne devrait être présenté comme quelque chose que DMARC seul aurait pu empêcher.

Cependant, les incidents soulignent pourquoi les organisations doivent comprendre exactement comment les services tiers sont autorisés à utiliser leurs domaines.

La documentation actuelle de Brevo fournit aux clients une configuration DMARC utilisant :

v=DMARC1; p=none; rua=mailto:[email protected]

Une politique DMARC p=none est valide.

Mais il est important de comprendre ce qu’elle signifie.

p=none signifie surveillance

Selon la norme DMARC actuelle, un domaine configuré avec :

p=none

fonctionne en mode surveillance.

Les systèmes de réception de courrier peuvent évaluer DMARC et générer des données de rapport, mais le propriétaire du domaine ne demande pas de traitement restrictif basé spécifiquement sur un échec DMARC.

Cela rend p=none extrêmement utile lors du déploiement initial de DMARC.

Les organisations peuvent découvrir :

• Quels systèmes envoient des emails utilisant leur domaine
• Si SPF est aligné
• Si DKIM est aligné
• Quelles plateformes tierces sont autorisées
• Quelle infrastructure inconnue peut usurper l’identité du domaine

Mais p=none n’est pas une application de DMARC.

VII. Surveillance DMARC vs application

Il existe trois états principaux de politique DMARC.

p=none

Surveillance

Fournit une visibilité sur l’authentification et l’alignement.

Aucune préférence de traitement restrictif n’est demandée en cas d’échec DMARC.

p=quarantine

Application

Demande que les destinataires traitent les messages échouant DMARC de manière plus restrictive.

Selon le fournisseur destinataire, cela peut impliquer le placement dans les spams, la mise en quarantaine ou un autre traitement.

p=reject

Application plus stricte

Exprime la préférence de politique DMARC la plus forte pour les messages qui échouent la validation DMARC.

Les fournisseurs destinataires conservent en fin de compte le contrôle sur la disposition finale d’un message.

La distinction pratique est :

p=none surveille.

p=quarantine et p=reject appliquent une politique.

p=none a-t-il causé les incidents Brevo ?

Non.

Ce point est important.

Dans l’incident du 10 septembre, les attaquants ont obtenu l’accès à des comptes Brevo légitimes.

Si un compte Brevo compromis envoie des emails via l’infrastructure Brevo correctement authentifiée, ces messages peuvent réussir DMARC.

Changer un domaine de :

p=none

à :

p=reject

ne bloquerait pas nécessairement un message malveillant authentifié provenant d’un compte autorisé compromis.

DMARC n’analyse pas l’intention ou le contenu d’un email.

DMARC répond à une question différente :

Ce message est-il authentifié et aligné avec le domaine qu’il prétend représenter ?

Cette distinction est fondamentale.

VIII. Alors pourquoi l’application de DMARC est-elle importante ?

Considérez un attaquant différent.

Cet attaquant n’a pas compromis Brevo.

Il n’a pas accès à Microsoft 365.

Il n’a pas accès à Google Workspace.

Il ne contrôle aucune plateforme légitimement autorisée à envoyer des emails au nom de l’organisation.

Au lieu de cela, l’attaquant essaie simplement d’envoyer :

From: [email protected]

en utilisant une infrastructure contrôlée par l’attaquant.

Si cette infrastructure ne peut pas fournir d’authentification SPF ou DKIM alignée avec entreprise.com, le message échoue DMARC.

Avec :

p=none

le propriétaire du domaine surveille principalement l’échec.

Avec une politique d’application telle que :

p=quarantine

ou :

p=reject

l’organisation exprime une politique de traitement restrictif pour ce message échoué.

C’est l’une des fonctions de sécurité les plus importantes de DMARC.

Elle réduit la capacité d’un attaquant à usurper directement l’identité d’un domaine protégé en utilisant une infrastructure non autorisée.

p=none est souvent le bon point de départ

Les organisations ne doivent pas simplement déplacer tous les domaines immédiatement vers p=reject.

Le faire sans comprendre l’environnement d’envoi de l’organisation peut perturber les emails légitimes.

Les organisations modernes peuvent envoyer des emails via :

• Microsoft 365
• Google Workspace
• Salesforce
• HubSpot
• Brevo
• Zendesk
• Plateformes marketing
• Systèmes de facturation
• Systèmes CRM
• Plateformes RH
• Fournisseurs d’emails transactionnels
• Systèmes de ticketing
• Plateformes de sécurité
• Applications internes

Avant l’application, ces systèmes doivent être découverts et correctement authentifiés.

C’est pourquoi p=none est souvent une étape de déploiement appropriée.

La question est de savoir si cela doit rester la posture de sécurité permanente.

IX. DMARC déployé ne signifie pas toujours DMARC appliqué

Cette distinction est fréquemment négligée.

Un domaine peut avoir un enregistrement DMARC valide tout en fonctionnant entièrement en mode surveillance.

Par exemple :

v=DMARC1; p=none;

signifie que DMARC est présent.

Mais le domaine n’est pas passé à l’application.

C’est pourquoi les organisations doivent distinguer entre :

Déploiement DMARC

et :

Application DMARC

Ils ne sont pas synonymes.

X. La conformité minimale n’est pas la protection maximale

Les principaux fournisseurs de boîtes aux lettres exigent de plus en plus l’authentification des expéditeurs en masse.

Ces exigences ont considérablement amélioré la sécurité des emails dans l’écosystème.

Mais de nombreuses exigences pour les expéditeurs acceptent :

p=none

comme politique DMARC minimale.

Le mot important est :

minimale

Une entreprise peut donc satisfaire une exigence d’expéditeur en masse tout en maintenant son domaine en mode surveillance.

Pour les entreprises, les institutions financières, les entreprises réglementées et les marques de grande valeur, la conformité réglementaire ou de plateforme ne doit pas automatiquement être considérée comme équivalente à la protection maximale du domaine.

XI. Les clients Brevo devraient examiner leur configuration DMARC actuelle

Brevo fournit actuellement aux clients une politique DMARC utilisant :

v=DMARC1; p=none; rua=mailto:[email protected]

Les organisations utilisant Brevo doivent vérifier s’il s’agit également de la politique de sécurité DMARC plus large de leur organisation.

Il ne devrait y avoir qu’un seul enregistrement DMARC valide par domaine.

Les organisations doivent donc éviter de publier des enregistrements DMARC concurrents simplement parce que plusieurs plateformes email demandent l’authentification.

Les expéditeurs tiers doivent plutôt être incorporés dans l’architecture d’authentification existante de l’organisation.

XII. Les organisations doivent-elles supprimer Brevo ?

Pas simplement à cause de ces incidents.

Si Brevo reste un système commercial légitime activement utilisé par l’organisation, la suppression brutale des enregistrements d’authentification peut perturber les emails légitimes.

Au lieu de cela, les organisations doivent réévaluer la relation de confiance.

1. Confirmer que Brevo est toujours nécessaire

Chaque plateforme externe autorisée à utiliser un domaine d’entreprise doit avoir un objectif commercial actuel légitime.

Les plateformes inutilisées ne doivent pas rester indéfiniment autorisées.

2. Examiner la sécurité du compte Brevo

Les organisations doivent examiner :

• Les comptes administrateurs
• La configuration SSO
• Les utilisateurs privilégiés
• Les identifiants API
• Les identifiants SMTP
• La configuration MFA
• Les journaux d’accès au compte

3. Examiner votre politique DMARC

Déterminez si le domaine de votre organisation fonctionne actuellement à :

p=none

p=quarantine

ou :

p=reject

Ne supposez pas que l’existence d’un enregistrement DMARC signifie que le domaine applique DMARC.

4. Identifier chaque expéditeur autorisé

Les organisations doivent comprendre chaque plateforme envoyant actuellement des emails en utilisant leurs domaines.

L’infrastructure d’envoi inconnue doit être investiguée.

5. Valider l’alignement SPF et DKIM

Les services d’envoi légitimes doivent satisfaire DMARC grâce à un SPF et/ou DKIM correctement aligné.

Cela permet aux emails légitimes de continuer pendant que l’infrastructure non autorisée est identifiée.

6. Progresser vers l’application lorsque approprié

Une fois que les expéditeurs légitimes ont été découverts et authentifiés, les organisations doivent évaluer si continuer indéfiniment en mode surveillance reflète leur posture de sécurité souhaitée.

7. Ne pas publier plusieurs enregistrements DMARC

Un domaine doit avoir une politique DMARC cohérente.

L’ajout d’enregistrements DMARC indépendants supplémentaires peut créer une configuration invalide.

XIII. Actions supplémentaires suite à l’incident du 14 septembre

Les organisations utilisant des composants de site web Brevo doivent également examiner les conseils de remédiation de Brevo.

Brevo recommande spécifiquement une action si un utilisateur a interagi avec le contenu malveillant le 14 septembre.

Si la commande ClickFix a été exécutée

Traitez l’ordinateur affecté comme potentiellement compromis.

Brevo recommande :

• Déconnecter le système
• Exécuter une analyse de sécurité complète
• Changer les mots de passe utilisés sur l’appareil
• Prioriser les identifiants du compte Brevo

Si un administrateur WordPress a visité un site affecté

Les organisations utilisant des scripts Brevo sur WordPress doivent examiner les plugins installés ou activés le 14 septembre.

Brevo recommande de supprimer les plugins suspects et de changer les identifiants administrateur.

Si un utilisateur s’est connecté à Brevo le 14 septembre

Brevo recommande de changer le mot de passe du compte et d’examiner les identifiants API par précaution.

XIV. Ce que les clients Skysnag doivent faire

Pour les clients Skysnag utilisant Brevo, il n’y a aucune exigence automatique de supprimer Brevo en tant qu’expéditeur autorisé.

Brevo peut rester intégré en tant que plateforme d’envoi légitime pendant que Skysnag continue de gérer l’authentification de domaine plus large et la politique DMARC.

Votre configuration DMARC existante gérée par Skysnag ne doit pas être remplacée par un enregistrement générique p=none simplement parce que Brevo demande l’authentification de domaine.

L’objectif n’est pas de bloquer l’infrastructure légitime.

L’objectif est de s’assurer que :

• Les services légitimes restent authentifiés
• Les sources non autorisées ne peuvent pas facilement usurper l’identité du domaine
• L’alignement DMARC reste correct
• La politique d’application du domaine reste contrôlée
• Les changements dans l’environnement d’envoi restent visibles

XV. La leçon de sécurité plus large

Les deux incidents Brevo illustrent deux formes différentes de risque tiers.

Le premier a montré que :

Un compte email légitime peut devenir un canal de phishing lorsque l’autorisation du compte échoue.

Le second a montré que :

Une infrastructure web de confiance peut devenir un canal de distribution de malware lorsque les identifiants d’infrastructure sont compromis.

Les organisations dépendent de plus en plus de réseaux interconnectés de :

• Fournisseurs SaaS
• Plateformes email
• Systèmes marketing
• CRM
• Infrastructure CDN
• Bibliothèques JavaScript
• Fournisseurs cloud
• Systèmes d’emails transactionnels

Chaque intégration de confiance élargit les capacités opérationnelles de l’organisation.

Elle élargit également sa limite de confiance.

Cela signifie que la sécurité de domaine moderne doit être stratifiée.

La sécurité des comptes protège l’accès aux plateformes autorisées.

SPF authentifie l’infrastructure d’envoi.

DKIM authentifie les messages.

DMARC valide l’alignement du domaine.

Les rapports DMARC fournissent une visibilité.

L’application DMARC renforce la protection contre l’usurpation d’identité directe non autorisée du domaine.

Aucun contrôle unique ne résout toutes les classes d’attaques.

L’objectif est de faire fonctionner ces contrôles ensemble.

XVI. La surveillance devrait conduire à une décision de sécurité

DMARC p=none a un objectif important.

Il fournit aux organisations l’intelligence nécessaire pour comprendre leur environnement d’envoi avant d’introduire l’application.

Mais la surveillance est plus précieuse lorsqu’elle informe finalement une décision de sécurité.

Une fois que les expéditeurs autorisés ont été identifiés et correctement authentifiés, les organisations doivent déterminer si rester indéfiniment à p=none reflète le niveau de protection qu’elles requièrent réellement.

Parce qu’il y a une différence importante entre :

Savoir que quelqu’un usurpe l’identité de votre domaine

et :

Publier une politique destinée à empêcher l’infrastructure non autorisée d’usurper avec succès son identité.

La surveillance fournit la visibilité.

L’application transforme cette visibilité en politique.

XVII. Vérifiez votre domaine

Si votre organisation utilise Brevo et que vous n’êtes pas sûr que votre domaine fonctionne actuellement à p=none, p=quarantine ou p=reject, Skysnag peut évaluer votre posture d’authentification email actuelle, identifier l’infrastructure d’envoi autorisée et déterminer un chemin approprié vers l’application sans perturber inutilement les emails légitimes.

Vérifiez votre domaine avec Skysnag.