WP Mail SMTP détourné : vos devis partent, le spam aussi

Le plugin n'est pas le malware

WP Mail SMTP, Fluent SMTP, Easy WP SMTP ou Post SMTP remplacent `wp_mail()` par un envoi authentifié (OVH, Gmail, Microsoft 365, Brevo, SES). L'identifiant vit dans les options, parfois en clair, parfois chiffré avec une clé locale. Un admin, un dump, un backup Updraft ou un voisin de compte suffit à l'extraire.

Réinstaller le plugin, le « scanner », ou le remplacer par un concurrent ne révoque rien. Le pirate continue d'envoyer depuis le vrai serveur SMTP, avec le vrai From de vos devis. C'est pour cela que les clients reçoivent à la fois votre confirmation de commande et une offre de crypto signée du même nom. Le symptôme est mail ; l'entrée est ailleurs — souvent un WordPress déjà compromis.

Avant de toucher aux réglages, copiez le site et la base. Les options SMTP et la date de modification datent l'exfiltration mieux qu'un antivirus.

Ce que montrent vraiment les journaux d'envoi

Trois sources se recoupent. Le journal du plugin (s'il est activé) liste destinataire, sujet, heure, parfois le code de réponse SMTP. Le journal d'envoi de l'hébergeur mail (cPanel, Plesk, Exchange, Google Admin) montre le volume, l'IP source et les rejets. La file du relais (Brevo, Mailgun, SES) ajoute les webhooks de bounce et les campagnes que vous n'avez pas créées.

Demandez le journal d'envoi à l'hébergeur pour la fenêtre suspecte, pas « les logs d'accès PHP ». Un pic à 3 h, des destinataires inconnus, un From identique au vôtre : c'est le compte qui envoie, pas un script `mail()` isolé. Distinguez les deux — le traitement n'est pas le même. Un abus de `php mail()` se coupe côté PHP ; un SMTP volé se révoque chez le fournisseur.

Gardez un export. Il sert au constat, à Spamhaus, parfois à l'assureur. Sans volume ni dates, un ticket « on a été piratés » ne lève aucune liste. Voir aussi emails en spam après un piratage.

• Volume horaire et pic inhabituel.
• From / Return-Path réellement utilisés.
• IP d'émission (serveur web vs autre).
• Codes 550 / 554 et mentions de blacklist.

Devis légitimes et spam collés dans la même file

Le client qui vous envoie une capture « votre devis est en indésirables » et le client qui a reçu un phishing à votre nom parlent du même secret. Les filtres notent le domaine et l'IP, pas l'intention. Tant que le spam part, chaque devis légitime aggrave le score.

Ne « relancez » pas la file, ne désactivez pas le plugin pour « tester », et n'envoyez pas une newsletter « on est de retour » depuis le même compte. Coupez d'abord l'identifiant volé. Les messages transactionnels (reset de mot de passe, commande) peuvent attendre quelques heures ; un nouveau batch de spam ne le peut pas.

Si WooCommerce ou un formulaire de devis est le seul expéditeur légitime, notez-le. Après révocation, vous saurez quoi recoller. Inversement, une file qui envoie vers des milliers d'adresses hors CRM n'est pas un « souci de SPF » : c'est un usage frauduleux du compte.

Changer le secret chez l'hébergeur mail, pas dans WordPress

L'ordre inverse est le plus fréquent et le plus inutile : on ouvre WP Mail SMTP, on tape un nouveau mot de passe, on enregistre. Si le pirate a encore un admin, un mu-plugin ou une copie de `wp-config`, il relit le nouveau secret dans l'heure. Changez d'abord chez OVH, Microsoft, Google, ou le relais. Puis seulement, recollez le nouveau secret dans le plugin — une fois les accès WordPress repris.

Pour Gmail / Google Workspace, un « mot de passe d'application » se révoque dans le compte Google, pas dans WordPress. Pour Microsoft 365, même logique. Pour un relais Brevo ou Mailgun, révoquez la clé API et les SMTP keys listées ; une clé oubliée dans un vieux staging vaut un employé fantôme.

Si le même mot de passe sert à la boîte du dirigeant, au panel et à WordPress, partez du principe que tout a été lu. Trois secrets distincts, ensuite. Le détail pour les CMS voisins est dans compte SMTP du CMS volé.

• Révoquer / tourner chez le fournisseur mail.
• Fermer les sessions admin WordPress (tous les users).
• Recoller le nouveau secret dans le plugin.
• Relire le journal d'envoi 24 h plus tard.

App password, OAuth et Fluent SMTP

Fluent SMTP et WP Mail SMTP Pro savent parler OAuth à Google et Microsoft. L'écran WordPress affiche « connecté » ; le jeton vit en base. Révoquer l'app côté Google (accès des applications tierces) casse le jeton. Changer uniquement le mot de passe du compte Google, selon les réglages, ne suffit pas toujours.

Un app password créé en 2022 pour « le prestataire » et jamais listé est une session permanente. Listez-les tous, révoquez ce que vous ne pouvez pas nommer. C'est le même réflexe que pour les mots de passe d'application WordPress : ils survivent au mot de passe principal.

Si le plugin a un mode « log des emails », exportez-le avant de le vider. Vider pour « faire propre » efface la fenêtre de dates dont vous aurez besoin pour Spamhaus ou pour un client qui conteste un message.

Ce que le pirate a pu lire dans le plugin

Selon le plugin et la version, le mot de passe SMTP est en clair, encodé en base64, ou chiffré avec une clé locale. Dans les trois cas, un accès lecture à la base ou aux fichiers suffit. Traitez-le comme un secret exposé, pas comme « peut-être illisible ».

Le pirate n'a pas besoin de garder le plugin. Il envoie depuis un client SMTP externe, de chez lui, avec vos identifiants. C'est pourquoi désactiver WP Mail SMTP ne stoppe pas le spam si le secret n'a pas été tourné. Le journal d'envoi côté fournisseur le montre : l'IP d'émission n'est plus celle du site.

Cherchez aussi un second canal : un script `mail()` à la racine, un cron qui envoie, un compte SMTP dupliqué dans un thème enfant. Un seul secret tourné et un second oublié, et la blacklist revient. Voir php mail() abusée.

Couper sans casser les mails transactionnels

Vous pouvez, le temps du doute, pointer le plugin vers un compte SMTP jetable à volume zéro, ou désactiver l'envoi authentifié. Les formulaires afficheront une erreur ; c'est moins grave qu'un nouveau batch. Un bandeau « les emails de confirmation peuvent tarder » vaut mieux qu'un silence.

Ne videz pas la file WooCommerce / devis en attente pour « nettoyer ». Ces messages sont légitimes. C'est le secret qui est sale, pas le contenu de la file. Une fois le nouveau compte en place, relancez ce qui est encore pertinent — pas les milliers de destinataires inconnus.

Si l'hébergeur a déjà coupé l'envoi du compte (abuse), ne demandez pas « rouvrez le SMTP » tant que le secret n'est pas tourné et le site inspecté. Un ticket factuel avec dates et volume accélère ; un « c'est bon maintenant » sans constat le retarde.

Refermer : clés, sessions, et file SMTP

Après le secret mail : sessions WordPress, utilisateurs inconnus, application passwords, clés REST, FTP. Un SMTP propre avec un admin fantôme encore là, et le secret est relu demain. L'ordre panel d'hébergement → FTP → admin CMS → SMTP est le même que pour tout premier geste.

Vérifiez les webhooks du relais (Brevo, Mailgun) : une URL de notification changée envoie les bounces ailleurs, et parfois permet de créer des listes. C'est silencieux. Les commandes « marchent » encore ; les événements partent chez un tiers. Voir webhooks de paiement détournés pour le même réflexe côté boutique.

Surveillez le journal d'envoi 48 à 72 heures. Un seul pic après révocation signifie qu'un second secret (staging, ancienne clé SES, plugin abandonné) est encore vivant.

• Secret mail tourné chez le fournisseur.
• Aucun utilisateur admin non nommé.
• Pas de second plugin SMTP actif (Fluent + WP Mail SMTP).
• Journal d'envoi plat sur 48 h.

Quand la délivrabilité met plusieurs jours

Couper la source ne « réchauffe » pas le domaine. Spamhaus, les listes d'opérateur, Gmail et Outlook notent l'historique. Recoller SPF / DKIM / DMARC aide les messages suivants à être authentifiés ; ça n'efface pas le volume déjà envoyé. L'ordre : source coupée, listes demandées, authentification recollée, puis attente. Inverser, c'est relancer du légitime dans un tuyau encore marqué. Détail dans domaine listé chez Spamhaus et SPF, DKIM, DMARC après un hack.

Un test vers votre propre Gmail ne dit rien. Regardez les codes de rejet, les en-têtes Authenticated-Results, et le volume résiduel. Si vous voulez déléguer le constat et le recollement, créez un espace : le prix s'affiche avant tout accès serveur.