Installer.php de Duplicator resté en ligne après une migration

Ce que le fichier permet

L'installateur déploie l'archive, écrit `wp-config.php`, crée les tables, parfois un compte admin. Accessible en HTTP, c'est une réinstall pour n'importe qui qui trouve l'URL — et les bots la trouvent (`/installer.php`, `/duplicator-installer`, variantes).

Ce n'est pas un « reste cosmétique ». C'est une console. Autant qu'un File Manager, avec un zip du site en prime. File Manager.

`installer.php` + l'archive `.zip` / `.daf` = une console de réinstall et une copie du site, wp-config compris, en HTTP. Les bots tapent `/installer.php`, `installer-backup.php`, `dup-installer/`. Ce n'est pas un reste cosmétique. Cherchez aussi Ai1WM et les autres migrateurs : même famille. Téléchargez le log `installer-log.txt` s'il existe : une date après votre migration dit que quelqu'un d'autre a lancé l'assistant.

Ajoutez la suppression de l'installateur à la checklist de fin de migration, au même titre que « changer les salts ». Les bots trouvent `/installer.php` en minutes. Un 404 aujourd'hui ne dit pas qu'il n'a pas servi hier : lisez le log s'il est encore là, puis delete. L'archive à côté est le site entier.

Les noms à chercher

`installer.php`, `installer-backup.php`, `installer-log.txt`, `database.sql`, `dup-installer/`, des hashes `installer_1234.php`. Racine surtout, parfois un sous-dossier `migrate/`. Grep `dup-` et `installer`.

Les paquets « thème + site prêt » laissent la même famille de fichiers, Duplicator ou non.

Cherchez `installer.php`, `installer-backup.php`, `installer-log.txt`, `dup-installer/`, `database.sql` à la racine et dans un dossier `migrate/`. Les packs « site + thème » laissent la même famille sans le logo Duplicator. Grep `dup-` et `installer` sur tout le compte.

L'archive à côté

Un `.zip` de 200 Mo à la racine : le site entier, wp-config compris. Téléchargeable. Retirez-le du webroot. Stockez hors serveur. Wordfence hurle à raison. Un `.daf` Duplicator : pareil.

Les backups Updraft / Ai1wm dans `wp-content` : même logique, autre article ; ici, l'installateur est le détonateur.

Un zip de 200 Mo à la racine se télécharge. C'est le site, secrets compris. Sortez-le du webroot le jour même, stockez hors serveur. Wordfence qui hurle sur l'archive a raison ; « réparer » un zip de 400 Mo, non.

Savoir si ça a déjà servi

Logs : GET/POST `installer.php` en 200, pas seulement des 404 de bots. Un `installer-log.txt` daté après votre migration. Un user admin créé ce jour-là. Un `wp-config` dont les clés ont changé sans vous. Un second dossier `wp-old`.

Si oui : incident complet, pas un delete de deux fichiers. Par où commencer.

Un user admin créé le lendemain de votre migration, des clés AUTH différentes de votre gestionnaire de mots de passe, un second dossier `wp-old` : l'installateur a servi. Passez en chasse complète, pas en delete de deux fichiers. Par où commencer.

Un run après votre migration : user admin, clés AUTH, parfois un second WP dans un sous-dossier, parfois un googleXXXX.html. Chasse complète. GSC : utilisateurs et sitemaps. Staging : mêmes secrets = porte de prod.

Après une migration « propre »

La checklist Duplicator officielle dit de supprimer l'installateur. C'est l'étape oubliée. Ajoutez-la à votre runbook : delete + recherche + Deny futur.

Un `.htaccess` qui interdit `installer.php` aide, le delete est mieux (une MAJ ou un extrait le recrée).

Duplicator vs All-in-One vs WP Migrate

Même famille de risque : un script d'install + une archive. Ai1WM laisse `installer.php` aussi selon les flux. Cherchez tous les noms, pas le logo Duplicator seulement.

Ne pas le laisser « pour la prochaine fois »

Vous migrerez dans six mois : vous recréerez le paquet. Entre-temps, c'est une porte. Pas de « on ne sait jamais ».

Chasse courte obligatoire

Delete installer + archive. Users. wp-config. mu-plugins. PHP uploads. Dates racine. Si les logs montrent un usage : élargissez.

Guide WP, backdoor, créer un espace.

Delete + recherche (users, wp-config, mu-plugins, PHP uploads, dates racine). Si les logs montrent un POST 200 : incident complet, pas deux fichiers à jeter. Un staging avec le même secret est une porte du prod. Guide WordPress, créer un espace.

Pro n'autorise pas le HTTP. Recréez le paquet dans six mois. Ai1WM : mêmes noms à chercher. L'hébergeur « clean » laisse souvent l'installer : pas dans leurs signatures.

Staging, autres migrateurs, et Search Console

Ai1WM et WP Migrate laissent parfois le même genre d'installateur. Cherchez tous les noms. Un staging `dev.` avec installer.php et les mêmes secrets que la prod est une porte de la prod. Auth HTTP + delete après usage.

Une réinstall via l'installer a pu déposer un `googleXXXX.html` et un user GSC. Vérifiez sitemaps et utilisateurs. Sitemap pirate. L'hébergeur qui a « nettoyé le malware » laisse souvent l'installer : ce n'est pas dans leurs signatures.

Duplicator Pro n'autorise pas à le laisser en HTTP. Recréez le paquet dans six mois si besoin ; entre-temps, c'est une porte. Créer un espace.

Runbook post-migration (à coller dans l'agence)

Delete installer.php, installer-backup.php, dup-installer/, archive zip/daf, installer-log.txt après lecture. Recherche variantes. Users + wp-config + GSC. Auth HTTP sur le staging. Pas de « on le laisse pour la prochaine fois ». Ai1WM : mêmes gestes.

Si le log montre un run après votre migration : chasse complète. Par où commencer. Créer un espace.

• Delete + log lu.
• Archive hors web.
• Users / clés.
• GSC.
• Staging fermé.