Compte SMTP du CMS volé : WordPress, PrestaShop, Joomla
L'identifiant SMTP vit dans un plugin WordPress, un module PrestaShop ou Joomla. Changez-le chez le fournisseur (OVH, Google, Brevo), pas seulement dans le CMS. Révoquez les mots de passe d'application. Le CMS n'est pas « l'infection » : le secret l'est.
L'identifiant est dans un plugin ou un module. Changez-le chez le fournisseur, pas seulement dans le CMS. Révoquez les mots de passe d'application.
Un secret, trois CMS, le même ordre
WordPress : WP Mail SMTP, Fluent, Easy WP SMTP. PrestaShop : Paramètres → Avancé → E-mail, ou un module. Joomla : Global Configuration → Server, ou un plugin. L'ordre ne change pas : copie, panel d'hébergement, révocation chez le fournisseur mail, sessions CMS, puis recollement du nouveau secret. WP Mail SMTP détaille WordPress ; ici le commun. Sur un même domaine, trois CMS peuvent partager la même boîte : un seul roll chez OVH, trois écrans à recoller le même jour, sinon le troisième continue d'écrire l'ancien secret dans ses logs et parfois de l'afficher à un prestataire.
Réinstaller le CMS ne révoque rien chez OVH. Changer le mot de passe « dans l'écran SMTP » pendant qu'un admin fantôme regarde, non plus.
Où le mot de passe est réellement stocké
Options / configuration en base (parfois base64, parfois clair), `wp-config`, `parameters.php`, `configuration.php`, un `.env`. Un dump Updraft, un phpinfo, un voisin qui lit le fichier : le secret est lu. Traitez-le comme exposé. Grep `smtp`, `password`, `apikey` dans la copie, pas en production à coups de `find` public.
Tourner chez le fournisseur d'abord
Chez l'hébergeur mail : nouveau mot de passe boîte, révocation des sessions, 2FA. Chez Google / Microsoft : app passwords listés et révoqués, apps tierces. Chez Brevo / Mailgun / SES : clés SMTP et API. Puis le CMS. Brevo.
- Fournisseur : secret neuf, sessions mortes.
- CMS : admin propre, puis nouveau secret collé.
- Un seul module SMTP actif.
App passwords et OAuth
Un mot de passe d'application « prestataire 2021 » survit au mot de passe du compte. Listez, révoquez. OAuth : révoquez l'app tierce chez Google / Microsoft, pas seulement « Disconnect » dans le plugin. Application passwords WP — autre tiroir, même hygiène.
Journaux : IP d'émission hors du site
Le pirate envoie depuis chez lui avec VOS identifiants. Le journal du fournisseur montre une IP qui n'est pas le web. Désactiver le plugin ne stoppe pas ça. Seule la révocation le fait. Exportez le journal pour Spamhaus et le constat. Journal.
Second canal : mail() encore ouvert
Après le SMTP, cherchez `mail()`. Les deux coexistent souvent. php mail. Un secret tourné et un `radio.php`, la blacklist revient.
Staging, backups, et le zip de l'agence
Le même mot de passe dans un staging, un `.env` git, un zip WeTransfer. Tournez, et considérez ces copies comme des fuites. Staging, migration.
Recoller un seul plugin / module
Deux plugins SMTP actifs = deux secrets, un oublié. Test d'un mail transactionnel, journal plat 48 h. SPF/DKIM : le From doit matcher ce que le fournisseur signe. SPF DKIM. Créer un compte si trois CMS sur le même domaine partagent la même boîte — un roll les touche tous.
- Secret tourné à la source.
- Copies (staging, zip) considérées fuites.
- mail() et SMTP, les deux contrôlés.
- Un seul connecteur SMTP.
Joomla et PrestaShop : les écrans à ouvrir
Joomla : Système → Configuration globale → Serveur (mailer SMTP, user, mot de passe). Des plugins (AcyMailing, un SMTP tiers) ajoutent un second secret : listez-les. PrestaShop : Paramètres avancés → E-mail, plus la config de chaque module qui « envoie une notification ». Un module transporteur ou paiement qui a son propre SMTP est un troisième compte. Magento : Stores → Configuration → Advanced → System / Mail, et les modules transactionnels.
Dans les trois cas, le mot de passe affiché en points n'est pas une preuve qu'il est sain. Tournez-le chez le fournisseur. Si l'écran CMS refuse d'enregistrer le nouveau (plugin cassé), changez quand même chez le fournisseur : l'envoi hostile s'arrête, le CMS se plaindra jusqu'à ce que vous recollez. C'est l'ordre utile.
Les journaux d'envoi du CMS (PrestaShop « E-mails » / logs Magento) sont incomplets. Le journal du fournisseur reste la source. Un pic à 4 h avec un From `contact@` et une IP ukrainienne n'apparaîtra pas dans l'écran « derniers emails envoyés » de PrestaShop. Demandez le journal, joignez-le au constat Spamhaus.