Une migration WordPress a ramené l'infection

La migration n'est pas un nettoyage

Changer d'hébergeur, passer en HTTPS, « tout remettre à neuf » : si le paquet source est sale, le nouveau compte l'est à la première extraction. L'hébergeur neuf suspend parfois en 24 h (malware detect). Vous avez brûlé un compte propre pour déplacer un shell. L'ordre utile est toujours : constater et nettoyer (ou extraire un sous-ensemble relu), puis migrer, puis revérifier.

Les dossiers que nous reprenons ont souvent deux incidents collés : le piratage d'origine, et la réinfection post-migration. Le second a l'air d'« un problème d'hébergeur ». C'est le même fichier `wp-tmp.php` dans le zip.

Si vous migrez pour fuir une blacklist IP, le domaine reste le vôtre. Les listes mail et Safe Browsing suivent le nom plus que la machine. Migrer sale aggrave les deux. Voir réputation d'IP pour le cas où l'IP, elle, est vraiment en cause.

Ce que transportent Duplicator et All-in-One

Ces outils packagent fichiers + base + un installateur PHP. L'installateur est puissant par design : il écrit où on lui dit. Laissé en ligne après bascule (`installer.php`, `dup-installer/`, `ai1wm-backups/*.wpress` téléchargeable), c'est une porte. Les archives `.wpress` ou `*_installer.php` dans `wp-content` se googledent.

Le paquet contient mu-plugins, drop-ins, uploads PHP, options sales. Un scan « après migration » qui ne lit que le cœur officiel est vert et faux. Traitez le zip comme un site infecté : listez les PHP hors cœur, grep la base extraite, comparez les thèmes.

Un All-in-One « pour gagner du temps » depuis un site encore redirigé copie la redirection. Vous venez de payer un prestataire pour déplacer le symptôme. Coupez la cause sur une copie isolée, puis rempaquetez, ou mieux : déployez cœur + plugins officiels + contenus relus.

• Supprimer installateurs et archives une fois la bascule OK.
• Interdire le téléchargement de `*.wpress`, `*.sql`, `*.zip` sous le web.
• Revérifier mu-plugins sur le nouveau disque.

Le zip de l'agence n'est pas une référence

« Le zip de 2022, au cas où » a souvent déjà le backdoor, ou un admin fantôme, ou un SMTP en clair. Demandez plutôt : export XML des contenus, export produits / commandes, zip de `uploads` images seulement, liste des plugins avec versions. Recollez sur un WordPress neuf. C'est plus long d'un après-midi, plus court qu'un second piratage.

Si l'agence refuse de fournir autre chose que « l'archive complète », ouvrez-la hors production (VM sans réseau sortant si le risque est élevé). Ne l'explosez pas dans `public_html` pour « voir ».

Migrer fichiers et base comme deux risques

Fichiers propres + base sale : le nouveau thème officiel affiche le script des `theme_mods`. Base propre + fichiers sales : le mu-plugin réécrit la base dès le premier hit. On valide les deux côtés. Un dump relu (options critiques, users, posts récents) et un arbre de fichiers comparé au cœur / plugins officiels.

Les tables WooCommerce (commandes, HPOS) se migrent pour le métier. Elles peuvent contenir des notes, des meta, des webhooks. Relisez les URLs de webhook et les clés API après bascule : elles pointent encore vers l'ancien hôte, ou vers un hôte que le pirate a mis. Voir clés REST WooCommerce.

Installateurs PHP laissés après coup

Duplicator, Softaculous, migrate guru, un `restore.php` maison : cherchez-les par date et par nom le lendemain de la bascule. Un cron de l'ancien prestataire qui « finit la migration » peut les recréer. Listez crontab et plugins de migration, puis retirez-les.

L'installateur connaît souvent les identifiants de la nouvelle base : il les a écrits. Quiconque le relance écrase le site. Ce n'est pas une relique inoffensive.

Secrets qui voyagent (SMTP, Stripe, SSH)

Le `wp-config` et les options transportent SMTP, clés Stripe, tokens Jetpack, access keys AWS. Une migration est une fuite interne : le zip a transité par email, Drive, le laptop du freelance. Tournez ces secrets sur le nouveau socle comme après un incident, pas « si on a le temps ». Le journal d'envoi du nouveau serveur doit partir à zéro avec un secret neuf.

Les clés SSH et les users FTP créés « le temps de la bascule » se révoquent le jour J+1. Un user `migrate` oublié est un employé fantôme.

Vérifier le nouveau serveur comme un visiteur

Home, une fiche, le checkout, `site:`, Search Console inspection, source HTML. Mobile et navigation privée. Le DNS peut encore servir l'ancien serveur à une partie des clients (TTL). Pendant ce split-brain, vous pouvez croire le nouveau propre et voir encore le malware chez les autres. Forcez le DNS, purgez le CDN, attendez le TTL ou les deux hôtes doivent être propres.

Comparez le HTML du checkout à ce que vous attendez. Un skimmer voyage très bien dans un zip. Skimmer WooCommerce.

L'ancien serveur qui continue d'écrire

Cron, webhook, plugin de sync, un `wp-cron` encore hit par un monitoring : l'ancien hôte réécrit la nouvelle base si elle est encore partagée, ou renvoie des mails. Fermez l'ancien vhost une fois le DNS basculé, révoquez ses clés, coupez son SMTP. Ne le gardez pas « au cas où » ouvert sur le même domaine.

Les webhooks Stripe doivent pointer vers le nouvel URL. Un double hit (ancien + nouveau) crée des commandes en double ou des statuts incohérents — et un ancien hôte infecté qui reçoit encore les événements de paiement est un incident à part.

Recommencer depuis un export propre

Si la bascule a déjà eu lieu et que le malware est là : ne « remigrez » pas le même zip. Repartez d'une install neuve + contenus relus, ou d'un nettoyage sur copie isolée puis rempaquetage. Deux migrations sales de suite épuisent l'hébergeur et l'index.

Pour un passage fichiers / base / secrets sans emporter le shell, ouvrez un espace. Le prix s'affiche avant l'accès.

• Source relue (fichiers + options + users).
• Installateurs et archives hors web.
• Secrets tournés après copie.
• Ancien hôte fermé, webhooks recollés.