Réinstaller WordPress après un piratage : bonne idée ?
Réinstaller WordPress par-dessus sans chercher l’entrée remet souvent l’infection. On compare le cœur, on retire les ajouts, on conserve contenus et réglages. Un « reset » n’est une bonne idée que dans un cas étroit — et ce n’est pas le bouton que l’on croit.
Réinstaller par-dessus sans chercher l'entrée remet souvent l'infection. On compare le cœur, on retire les ajouts, on conserve contenus et réglages.
Réinstaller n’est pas nettoyer
Réinstaller WordPress après un piratage paraît définitif : « on remet une version propre ». Le cœur officiel, oui, si le bouton ne touche qu’à ça. L’infection, elle, vit dans `wp-content`, dans la base, dans `.htaccess`, dans un cron, dans un voisin, dans `wp-config` lu et réécrit. Réinstaller par-dessus sans ce travail, c’est peindre le salon alors que la serrure est encore limée.
Les dossiers « on a tout réinstallé deux fois » sont notre quotidien. Home propre une soirée. Mu-plugin toujours là. Ou restore de `wp-content` depuis Updraft juste après — réinjection. L’idée n’est pas mauvaise. Le périmètre l’est.
Donc : bonne idée comme geste ciblé sur les fichiers cœur, après copie. Mauvaise idée comme unique geste, comme « reset et on oublie », comme substitut à trouver si c’est vraiment un hack.
- Avant tout bouton : copie hors serveur.
- Réinstall cœur ≠ wipe `wp-content` ≠ dump SQL neuf.
- L’entrée (extension, compte, voisin) survit au cœur neuf.
Ce que le bouton panel écrase vraiment
Souvent : fichiers de `wp-admin`, `wp-includes`, les PHP racine du cœur (`index.php`, `wp-settings.php`…). Parfois `wp-config.php` est préservé (tant mieux pour les clés, tant pis si on y a collé un prepend). Parfois un `.maintenance` reste. Rarement la base. Rarement `uploads`.
Vérifiez après : dates et tailles des fichiers cœur vs le zip de la version. Si `wp-includes/canonical.php` est encore à la date d’hier, le bouton n’a rien fait ou a échoué. Relisez le journal du panel.
Certains « reset » d’hébergeur remettent un WordPress vide sur le même dossier : vous perdez contenus, et les fichiers hors inventaire officiel (`radio.php`) peuvent rester à côté. Vous avez un WP neuf et un shell. Victoire apparente.
Ce qu’il laisse intact (donc souvent la porte)
`wp-content/plugins`, thèmes, uploads, mu-plugins, `wp-config.php`, `.htaccess`, `.user.ini`, la base (`options`, users, posts), les crons panel, les comptes FTP, les autres vhosts. C’est la liste des lieux préférés. Réinstall cœur + scan plugin = encore la même liste oubliée.
Une extension vulnérable réinstallée « parce qu’elle est dans le backup » ramène l’entrée. Un thème nulled réinstallé ramène le backdoor du thème. Le geste cœur ne décide pas de ça. Vous si.
Backdoor : lisez cette liste comme checklist post-réinstall, pas comme option.
Le bon usage : réaligner le cœur seulement
Cœur sale (fichiers `wp-includes` retouchés) : réinstall ciblée ou upload du zip officiel par-dessus, après copie. C’est propre, lisible, rapide. Puis diff de `wp-content`, puis base, puis secrets. L’ordre compte : un cœur neuf avec un prepend dans `.user.ini` fatal encore, ou charge encore le loader.
Ne cochez pas « vider la base » sauf décision de reconstruction. Les contenus récents sont là. Un rewind SQL est un autre article : restaurer une sauvegarde.
Version : réinstallez la même version majeure que celle qui tournait, puis mettez à jour une fois propre. Sauter de 5.8 sale à 6.6 en une passe sur un site infecté mélange les Fatal et les symptômes.
Reset total : quand ça se discute
Site vitrine sans contenus irremplaçables, backups inexploitables, tree tellement mélangé (dix « clean », thèmes empilés) que le diff coûterait plus cher qu’une reconstruction. Alors oui : nouveau vhost, WP neuf, contenus recollés à la main, DNS à la fin. Pas : même dossier, bouton reset, mêmes secrets, même compte multi-sites sale.
Boutique, 5 000 articles, membres : le reset total est un projet de migration, pas un geste d’incident. Refusez le prestataire qui le propose en 2 h.
Nouveau domaine : encore un autre sujet, rarement une bonne idée SEO. Ce n’est pas un reset, c’est un abandon d’historique.
La sauvegarde que l’on réinjecte après
Le scénario raté : réinstall cœur, « ça marche », restore Updraft « pour récupérer les pages », infection de la veille. Si vous restorez `wp-content` et la base, vous annulez le cœur propre au premier mu-plugin de l’archive. Ouvrez, filtrez, ou n’utilisez la save que pour extraire des médias / un XML d’articles.
Les migrations All-in-One, Duplicator, encore branchées : un click « import » après réinstall est une réinfection en un fichier. Désinstallez ces outils une fois le site stable, ou au moins leurs archives publiques.
Traitez toute archive post-incident comme sale jusqu’à lecture. C’est la même discipline que sauvegarde déjà infectée.
PrestaShop / autres CMS : même illusion
« Réinstall propre du CMS » sur PrestaShop sans comparer `modules/` et `override/` : même pièce. Magento : `app/code`, cron, admin users. Le mot reset rassure les non-techniciens. Le filesystem, lui, n’est pas impressionné.
Un installateur officiel (WordPress.org, Prestashop) sur un dossier non vide laisse les fichiers inconnus. Videz ce que vous voulez perdre, consciemment, après copie. Ne croyez pas que l’installateur « remplace tout ».
Page WordPress pour les portes. La réinstall n’y figure pas comme étape 1.
Après la réinstall : la liste qui reste
Utilisateurs, applications passwords, `.htaccess`, `.user.ini`, mu-plugins, uploads PHP, options JS, cron, FTP, panel, autres sites, clés AUTH régénérées, extension d’entrée à jour ou hors. Surveillance `site:` 48 h / 7 j. Sans cette liste, la réinstall était un placebo.
Si vous l’avez faite trop tôt et que ça recommence : ne réinstallez pas une troisième fois. Changez de méthode. Déléguer ou checklist backdoor complète.
Le bouton n’est pas tabou. Il est étroit. Utilisez-le étroitement.