Site inaccessible après une tentative de nettoyage : que faire
Un `.htaccess` vidé, un `index` écrasé ou un plugin de sécurité trop agressif suffisent à tuer le site après un « nettoyage ». Repartez de la copie d’avant votre intervention, pas d’une réinstallation. Le piratage était un problème. Le Kärcher en est un second, souvent plus urgent pour les visiteurs.
Un .htaccess vidé, un index écrasé ou un plugin de sécurité trop agressif suffisent. Repartez de la copie d'avant votre intervention, pas d'une réinstallation.
Deux incidents empilés, un seul réflexe
Site inaccessible après une tentative de nettoyage : les clients voient une 500 ou une blanche, vous aussi, et le malware n’est pas forcément parti. On traite d’abord la casse que vous venez de créer — parce qu’elle est réversible si une copie d’avant vos gestes existe — puis on reprend l’infection avec de la méthode. Fusionner les deux dans « on réinstalle tout » perd les deux chronologies.
Le réflexe utile : stopper tout delete, lister ce que vous avez touché (même approximatif : « htaccess, dossier plugins, repair Wordfence »), sortir la copie de 16 h 02 si elle est d’avant le Kärcher. Si votre seule copie est d’après le massacre, sortez un backup hébergeur plus ancien, en sachant qu’il peut être infecté — vous restaurez pour avoir un site qui boot, vous ne « finissez pas le nettoyage » par ce restore.
Personne n’est nul d’avoir cassé. Les tutos « delete all suspicious » y poussent. On change de méthode maintenant. Ne pas supprimer au hasard.
- Stop aux gestes supplémentaires.
- Inventaire de ce que vous avez touché.
- Copie T-avant-vous, sinon backup froid.
Ce qui casse le plus souvent (inventaire)
`.htaccess` vide ou trop Deny. `index.php` vide ou absent. `wp-config.php` mal recollé (guillemet, salts à moitié). Dossier `plugins` renommé et oublié. Thème enfant `functions.php` vidé par un repair. Permissions 000 sur `wp-content`. `auto_prepend` qui pointe vers un fichier que vous avez isolé (Fatal au boot). Base : `siteurl` faux, option trop coupée.
Moins fréquent : quota (vous avez uploadé trois zips de backup dans `public_html`). PHP version changée « pour le malware ». DNS touchés « au cas où ».
Le journal PHP dit lequel. Comment pour une 500 « naturelle » : erreur 500. Ici, l’horloge dit « juste après nous ». Priorisez les fichiers d’entrée.
Revenir à T-avant-vous, pas à T-avant-le-hack
La copie de constat (état infecté mais bootable) est souvent le meilleur restart. Vous perdez vos deletes, vous regagnez un front, vous recommencez à isoler un fichier à la fois. La sauvegarde d’il y a quinze jours peut être plus propre… et déjà trouée, et sans les commandes de la semaine. Lisez restaurer : ici on restore pour défaire le Kärcher, périmètre étroit (fichiers d’entrée, pas tout le compte mail).
Si le panel a un « undo » de file manager, parfois. Ne restorez pas le compte entier cPanel : logs et FTP repartent en arrière, parfois les secrets aussi.
Nommez ce restore : `retour-avant-karscher-27-16h`. Pour ne pas le confondre avec un point propre plus tard.
Le `.htaccess` et l’index : premiers ouverts
Stub WordPress officiel (RewriteBase, index.php). L’ancien pirate à côté, pas à la poubelle. `index.php` du zip de votre version. Rechargez. Si ça boot, vous avez gagné l’accès pour travailler. Si ça 500 encore, log : prepend, wp-config, memory.
`.user.ini` / `php.ini` local : si vous avez isolé le prepend sans retirer la directive, chaque hit Fatal. Commentez la ligne, ne deletez pas tout le ini si vous ne savez pas.
Nginx (pas de htaccess) : le vhost a peut-être été édité. Snapshot / conf précédente chez l’hébergeur. Plus rare en mutualisé classique.
Wordfence / « repair » / chmod 000
Désactiver le plugin (rename dossier) si c’est lui qui 403/500. Restaurer les fichiers « repaired » depuis votre copie d’avant repair, ou depuis le zip thème. chmod : remettre 644 fichiers / 755 dossiers sur le tree CMS, 600 sur `wp-config`, pas 777. Demandez à l’hébergeur un reset perms s’ils ont un bouton — après copie.
Imunify quarantine : liste, restore sélectif des fichiers cœur, pas des `radio.php`. Email malware.
Un plugin « white screen fix » ajouté dans la panique : retirez-le. Une couche de plus.
Base à moitié nettoyée, fichiers à moitié morts
Vous avez vidé `wp_options` autoload « pour le JS » et cassé `rewrite_rules` / `active_plugins` / `template`. Restaurez ces lignes depuis le dump de constat, pas toute la base d’il y a six mois. Ou `wp rewrite flush` une fois l’admin de retour, pour les rewrite.
`siteurl` mis à `http://localhost` par un tuto : corrigez les deux options, cookies, HTTPS. Loop login classique.
Ne réimportez pas un dump entier par-dessus « pour être sûr » si le dump est l’état pirate + vos DELETE hasardeux. Choisissez la table.
Ne pas réinstaller par-dessus le désastre
Un WP neuf dans le même dossier laisse les prepend, les uploads PHP, la base sale, et ajoute un CMS vide. Les visiteurs ? Selon le vhost, l’infecté ou le vide. Réinstaller : après un tree qui boot, cœur seulement, si besoin.
Changer d’hébergeur maintenant : vous migrez un site mort + sale. Migration. Non.
Si la honte pousse à « tout jeter » : dormez une heure, ou déléguez. Le désastre de 18 h est réparable à 20 h avec la copie de 16 h. Demain sans copie, moins.
Reprendre un nettoyage propre ensuite
Site bootable → tests visiteurs (le malware est peut-être encore là) → un fichier, comparer, isoler → entrée → secrets si pas faits. Horloge plus longue, méthode plus courte au total que trois Kärcher.
Écrivez ce que le premier passage a déjà retiré de juste (un vrai `wp-core.php`). Ne le remettez pas avec le restore T-avant-vous… sauf si ce restore le ramène. Alors ré-isoler tout de suite, documenté.
Créer un dossier à ce stade est fréquent, et raisonnable : on hérite d’un incident plus d’une casse. Dites les deux. Ça change le devis, ça évite qu’on accuse le malware d’une 500 que vous avez créée — on la répare quand même.