Liste newsletter compromise après un piratage de site
Si la base clients du site a pu être lue, la liste newsletter l'a peut-être été aussi — ou l'inverse, via une clé API. Forcez un opt-in de confirmation si l'export est plausible, surveillez les plaintes, prévenez Brevo ou Mailchimp. Le RGPD s'applique à ces emails autant qu'à la table commandes.
Si la base clients a pu être lue, la liste l'a peut-être été. Forcez un opt-in de confirmation, surveillez les plaintes, prévenez Brevo/Mailchimp si un export est plausible.
Deux listes qui se recouvrent mal
La table clients CMS (commandes, comptes) et la liste Brevo / Mailchimp / un plugin d'opt-in ne sont pas le même fichier. Un hack site peut lire la première sans toucher la seconde (clé API intacte). Une clé API lue peut exporter la seconde sans SQL. Inventoriez les deux. « On a Wordfence donc la newsletter est bonne » ne tient pas. Fuite, Brevo.
Indices : plaintes, désabonnements, campagnes fantômes
Une campagne que vous n'avez pas créée, un pic de plaintes spam, des désabonnements massifs, des bounces sur une liste « propre ». Ça oriente vers une clé ou un compte emailing pris — pas forcément vers un SQL. Inversement, un silence Brevo et un dump `wp_users` lu : la liste n'a pas bougé, le risque est ailleurs (phishing ciblé plus tard). Ne fusionnez pas les deux histoires dans le mail clients.
- Historique des campagnes (auteur, IP).
- Logs d'export / API.
- Users du compte emailing.
Opt-in de confirmation : quand oui, quand non
Si un export liste est plausible : un recueil de consentement (re-opt-in) réduit le risque de continuer à écrire à des gens dont l'adresse a fuité chez un spammeur — et documente un nouveau consentement. Ce n'est pas obligatoire dans tous les cas ; c'est souvent sage. Si seule une table commandes a été lue et que l'emailing n'a pas bougé, un re-opt-in de toute la liste peut être excessif — votre DPO tranche. N'envoyez pas le re-opt-in depuis un domaine encore blacklisté : il n'arrivera pas. Emails spam.
Prévenir le prestataire d'emailing
Brevo, Mailchimp, Sendinblue historique : ticket, révocation des clés, 2FA, campagnes suspectes à stopper. Ils peuvent geler un compte qui envoie du spam « à votre nom ». Mieux vaut votre ticket qu'un signalement tiers. Canal security, pas le chat onboarding.
RGPD : ce que le constat doit dire
Périmètre (quelle liste, quels champs : email seul vs + nom + tags + historique d'ouverture), fenêtre, plausibilité d'export vs certitude. L'email est une donnée. Une liste de 80 000 contacts n'est pas « moins grave » qu'une table commandes de 2 000. Notification CNIL / personnes : selon le risque (souvent plus bas qu'un skimmer CB, pas nul). Vous déclarez. Guide fuite.
Ne pas « racheter » une liste ni relancer froid
Après incident, la tentation de « rattraper le CA » avec un achat de fichiers ou un cold massif brûle le domaine et le contrat emailing. Interdit côté RGPD en plus. Reprenez sur les consentants, petit volume, domaine propre.
Hygiène : clés, rôles, exports
Une clé API par usage, lecture seule si le site ne fait que pousser des inscrits, pas de clé master dans le CMS. Rôles emailing (le stagiaire n'exporte pas). Pas de CSV dans `uploads`. Relire à J+30 les users Brevo. Créer un compte si site + liste + CB se mélangent dans le même week-end.
- Clés et users emailing tournés.
- Campagnes fantômes stoppées.
- Re-opt-in décidé, pas automatique-panique.
- CSV hors web.
Double opt-in cassé et inscriptions forcées
Un attaquant qui a la clé API peut pousser des milliers d'adresses (spamtraps) dans votre liste, puis envoyer. Votre domaine brûle, Mailchimp vous suspend, vous n'avez « rien demandé ». Regardez les inscriptions de la fenêtre : volumes, pays, absence de confirmation. Purgez ces cohortes, ne les « relancez » pas. Un double opt-in rétabli après coup ne lave pas les spamtraps déjà confirmés par un bot.
Inversement, désactiver le DOI « pour convertir » pendant l'incident est la pire idée : vous ajoutez du froid à une réputation déjà sale. Emails après piratage.
Les formulaires du site (popup, checkout opt-in) peuvent aussi avoir été détournés : le POST part vers un tiers en plus de Brevo. Relisez le HTML des formulaires comme un checkout. Un second `action` ou un pixel d'écoute, c'est une collecte parallèle — volet fuite.
Comment une liste « sort » vraiment
Admin CMS / employé, phpMyAdmin, plugin d'export, clé API emailing (`list` + `read`), webhook qui pousse chaque inscrit vers un tiers, un Zap. Les journaux Brevo (exports, connexions) et les users du compte emailing datent mieux qu'un scan de thème. Révoquez les users inconnus là-bas aussi.