Quand un site WordPress se fait “prendre”, on imagine souvent le pire tout de suite: redirections bizarres, spam dans les formulaires, pages qui s’affichent avec un contenu illisible. Pourtant, dans les cas réels, le premier indice est parfois plus discret. Un plugin qui disparaît, des images qui ne se chargent plus, un thème qui refuse de s’afficher, ou un noyau WordPress qui semble incomplet. Et c’est là que le nettoyage virus WordPress devient un travail de restauration, autant que de suppression.
Je l’ai vécu plusieurs fois sur des sites clients, et la difficulté revient toujours au même point: supprimer “ce qui est suspect” ne suffit pas si des fichiers légitimes ont été effacés, remplacés ou partiellement corrompus. Un serveur peut même se comporter “presque normalement”, mais avec assez de trous pour que l’injection se cache plus longtemps que prévu. Restaurer les fichiers manquants ou corrompus devient alors une étape clé pour repartir proprement, vérifier l’intégrité, et réduire le risque de réinfection.
Le tableau de bord qui ment parfois
Sur WordPress, on a tendance à regarder l’interface d’administration en premier. C’est logique. On veut savoir quel plugin est installé, quel thème est actif, et si des utilisateurs ont été ajoutés. Mais il existe des scénarios où le back-office n’est pas fiable.
Par exemple, j’ai vu des cas où le tableau de bord restait accessible, mais où l’affichage public était contaminé. L’injection se faisait via des fichiers dans des répertoires du thème ou via des scripts placés au mauvais endroit, avec une logique qui ne se déclenchait qu’à certaines requêtes. A l’inverse, il y a des cas où le front affiche une erreur 500 ou des pages vides, alors que le “diagnostic” initial laisse croire à une seule extension cassée.
Dans ces situations, le symptôme peut être “corrompu” plus que “infecté”. Un fichier manquant peut provoquer un écran blanc, puis l’équipe pense à un problème de permissions ou de cache. Puis, une fois la restauration faite, on découvre que la cause racine était ailleurs: un morceau de core WordPress remplacé, ou une action sur le système de fichiers qui a laissé des traces, mais aussi des dégâts collatéraux.
Ce qui compte, c’est d’assembler un puzzle à partir de plusieurs signaux: comportements web, logs serveur, cohérence des fichiers, et historique des changements.
Symptômes concrets: reconnaître un chantier de restauration
Tous les sites infectés ne se comportent pas pareil, mais on retrouve souvent des indices typiques. Certains sont visibles, d’autres demandent un peu d’observation.
Voici les signes qui, à mon avis, orientent vite vers des fichiers manquants ou corrompus, pas seulement vers un “malware” classique:
- erreurs 403 ou 404 sur des fichiers qui devraient exister, surtout après une mise à jour ou un incident thème ou plugin qui refuse de charger avec des erreurs PHP, sans changement volontaire apparition de redirections depuis des pages précises, alors que l’interface WordPress semble “normale” pages qui contiennent du code bizarre dans le HTML, ou des portions répétées sans logique éditoriale augmentation brutale des erreurs dans les logs, notamment liées à include, require, ou fichiers introuvables
La logique est simple: quand un attaquant modifie un site, il le fait via des fichiers. S’il a des droits insuffisants, il peut échouer partiellement. S’il a des outils d’automatisation, il peut remplacer des fichiers entiers. Dans les deux cas, on obtient des trous. Ces trous, eux, peuvent casser le site et rendre les symptômes plus “techniques”.
Et quand le site casse, beaucoup de gens réinstallent vite, puis pensent que c’est fini. Or, si on remplace trop tôt sans vérifier l’origine de la corruption, on peut écraser ce qui reste et relancer un mécanisme de réinfection.
Diagnostiquer sans aggraver: ce que je fais en premier
Avant de toucher aux fichiers, j’essaie de répondre à trois questions, avec le minimum de mouvements:
1) Est-ce que le problème ressemble à une corruption de fichiers, ou à une modification de contenu via la base de données? 2) Est-ce que l’incident a affecté le noyau WordPress, ou uniquement des plugins et des thèmes? 3) Est-ce que l’élément supprimé est réellement “manquant”, ou juste “non chargé” par une configuration cassée?
La première étape pratique consiste à isoler un environnement pour tester. Si vous avez une sauvegarde récente, parfait. Sinon, l’idée est de créer un clone du site (même temporaire) sur un environnement de staging, ou au minimum une copie des fichiers et de la base. Sur un hébergement mutualisé, ça peut être plus délicat, mais c’est souvent faisable, surtout si vous avez accès à un gestionnaire de fichiers ou un accès SSH.
Ensuite, je regarde les logs. Sur Apache ou Nginx, les patterns utiles apparaissent vite: requêtes vers des scripts bizarres, appels à des fichiers dans des chemins anormaux, erreurs PHP récurrentes, et heures qui correspondent à des pics de trafic. Je cherche aussi les erreurs liées aux inclusions: require, include, ou “failed to open stream”. Ce genre de message montre que WordPress ou PHP essaye d’appeler un fichier qui n’est pas là.
Enfin, je vérifie l’ampleur côté système de fichiers. Un “ls” ou un relevé de tailles de dossiers peut révéler des anomalies: un plugin devenu énorme, des fichiers récemment https://gardewp.fr/ modifiés dans des répertoires inhabituels, ou des dates qui ne collent pas à l’historique.
Restaurer les fichiers manquants ou corrompus: l’approche qui évite les pièges
Restaurer ne veut pas dire “copier-coller tout le monde”. Sur un site potentiellement compromis, l’erreur fréquente est de remplacer aveuglément des fichiers tout en gardant des restes de la compromission dans la base ou dans des répertoires contaminés.
La bonne méthode que j’utilise se base sur une séparation claire:
- le noyau WordPress (les fichiers du core) les fichiers d’extensions (plugins) les thèmes la configuration (wp-config.php, parfois .htaccess) et la base de données
La restauration la plus sûre, en général, concerne le core WordPress. Même si un attaquant a mis la main dessus, vous pouvez réintroduire les fichiers du core propres à partir d’une version officielle. Cela ne supprime pas à lui seul les scripts injectés ailleurs, mais ça remet le cadre en état.
Pour les fichiers manquants, la question est “manquant où ?”. Si des fichiers de core ont disparu, WordPress ne peut pas charger certaines classes. Si un dossier de plugin ou de thème a été partiellement supprimé, vous verrez souvent des erreurs “Class not found” ou “Call to undefined function”, parce que le plugin attendu n’est plus cohérent.
Le point clé, c’est que la restauration doit être couplée à une vérification. Autrement, vous restaurez une partie du problème, puis vous repartez avec l’autre moitié cachée.
Restaurer le core WordPress sans écraser la configuration
Dans beaucoup d’interventions, on fait une réinstallation “propre” du core:
- vous téléchargez la même version exacte de WordPress que vous avez sur le site, ou à défaut une version proche, mais l’idéal reste l’exactitude vous remplacez les fichiers du core (wp-admin, wp-includes, certaines racines) en conservant wp-config.php et les contenus de wp-content vous gardez aussi les fichiers de configuration spécifiques au serveur, selon leur contenu
La partie “exacte version” compte plus qu’on ne le pense. WordPress évolue, et remplacer avec une version légèrement différente peut créer des écarts, surtout si le thème ou certains plugins reposent sur une API précise.
Une fois la restauration effectuée, je redémarre sur une vérification minimale: est-ce que l’administration se charge, est-ce que les pages de test fonctionnent, est-ce que les erreurs “fichiers introuvables” cessent.
Si elles continuent, ce n’est pas seulement du core manquant. Alors je bascule vers wp-content.
Quand les fichiers corrompus viennent de wp-content
Wp-content est souvent l’épicentre. Les plugins et les thèmes sont des points d’entrée très “naturels” pour un attaquant: ce sont des fichiers PHP chargés souvent, avec des permissions variables.
Le réflexe “on supprime le plugin suspect et on le réinstalle” fonctionne dans beaucoup de cas. Mais il y a une nuance importante si le plugin a été altéré en profondeur.
J’ai déjà vu une situation où un plugin légitime était présent, mais son fichier principal avait été modifié, puis le reste du plugin avait été laissé intact. Dans ce cas, la suppression puis réinstallation peut suffire, à condition d’être sûr que vous retirez bien le bon dossier et que vous ne conservez aucun fichier réécrit “à l’intérieur” (par exemple, un fichier caché dans le répertoire du plugin).
Autre cas plus sale: des fichiers ajoutés à des emplacements non attendus. Un attaquant peut déposer du code dans un sous-répertoire qui n’est pas le dossier du plugin lui-même, puis utiliser un include mal placé depuis un fichier connu.
Si vous restaurez le core mais laissez wp-content tel quel, l’incident peut continuer, mais avec des symptômes différents. On ne doit donc pas considérer la restauration du core comme une fin en soi, plutôt comme un “rétablissement de base” pour nettoyer ensuite proprement.
Définir une stratégie: purge ciblée ou mise à nu
Sur un site déjà suspect, j’adopte deux stratégies selon l’état de wp-content:
- Si le site reste exploitable et que seules certaines fonctions sont cassées, je fais une purge ciblée: je désactive, supprime ou remplace uniquement les éléments qui ont des signatures évidentes (fichiers récemment modifiés, patterns dans le code, comportements anormaux). Si le site est trop instable, ou si les traces sont partout, je fais une mise à nu contrôlée: je remplace l’ensemble des thèmes et je garde uniquement les éléments nécessaires pour remettre le site en état, puis je réintroduis plugin par plugin.
Cette deuxième méthode est plus lourde, mais elle évite de rester dans le doute. Le compromis, c’est le temps, car il faut remettre en route la configuration et vérifier les dépendances. Dans la pratique, elle est utile sur les incidents répétitifs ou quand la compromission a laissé trop de dégâts.
Contrôler wp-config.php et la couche d’accès
Wp-config.php n’est pas un simple fichier de paramètres. Il peut devenir un support de modification, notamment via des clés modifiées, des variables ajoutées, ou des altérations de chemins.
Quand je “restaure” je vérifie surtout:
- la présence de constantes attendues l’absence de lignes inattendues ajoutées dans des zones où elles n’ont aucune raison la cohérence avec votre environnement (bref, pas de “const” inventées)
Je regarde aussi .htaccess quand le serveur Apache est utilisé. Un incident peut ajouter des règles qui forcent des redirections, bloquent des chemins, ou masquent des fichiers. Si vous restaurez le core mais laissez .htaccess contaminé, vous pouvez garder des comportements étranges même après le nettoyage.
Et côté permissions, c’est souvent le détail qui change tout. Un site compromis a parfois eu des permissions trop larges sur certains dossiers. Si vous restaurez les fichiers mais que les permissions restent mauvaises, un incident futur aura un chemin plus facile.
Vérifications qui donnent des réponses, pas juste des impressions
Après la restauration et la purge de fichiers, il faut confirmer que la surface d’attaque a réellement reculé. Dans mon expérience, les tests utiles ne demandent pas des outils exotiques. Ils demandent de la rigueur.
Je vérifie:
- que WordPress charge bien les fichiers core sans erreurs visibles que l’administration n’affiche pas d’avertissements ou d’échecs liés à des includes manquants que les pages publiques qui redirigeaient ailleurs reviennent à un contenu attendu que les performances ne repartent pas avec des pics d’erreurs immédiatement après restauration
Si vous avez la main sur les logs, c’est encore mieux. Les requêtes malveillantes ont souvent un motif. Si ce motif continue, ce n’est pas forcément que les fichiers sont encore infectés, mais ça peut indiquer qu’un autre mécanisme déclenche toujours la même réponse.
Un piège classique: la base de données
Restaurer des fichiers manquants ou corrompus ne règle pas toujours tout, parce que l’injection peut aussi vivre dans la base de données.
Une base contaminée peut contenir:
- des options modifiées des pages ou contenus ajoutés en base des utilisateurs créés et masqués des redirections configurées via des plugins ou des mécanismes internes
C’est pour ça que je fais un aller-retour entre fichiers et base, même si je commence par les fichiers. Une fois le core restauré, si le site reste “bizarre”, je reviens vers la base.
Selon votre niveau d’accès, vous pouvez aussi utiliser un outil de comparaison ou une approche manuelle via phpMyAdmin, mais sans chercher à “tout supprimer”. Si vous retirez des lignes utiles par erreur, vous cassez des réglages légitimes. Sur WordPress, la meilleure approche reste de cibler ce qui a été modifié en dehors du contexte habituel.
Sécuriser après la restauration, sinon vous payez deux fois
Nettoyage virus WordPress, ce n’est pas seulement une chirurgie. C’est une remise en conformité, puis une prévention.
Les postes d’attaque les plus fréquents ne sont pas toujours le malware en lui-même. Souvent, c’est:
- un mot de passe faible un plugin abandonné une mise à jour trop tardive une erreur de droits sur des dossiers une machine compromise en accès FTP ou en accès admin
Je préfère traiter ça après une restauration réussie, parce que tant que vous n’êtes pas sûr que le site fonctionne “proprement”, sécuriser peut vous compliquer la tâche de diagnostic.
Concrètement, j’effectue un verrouillage progressif:
- je change les mots de passe des comptes administrateur et des comptes techniques si vous en avez je force une vérification des utilisateurs: pas de nouveaux comptes sans raison, pas de rôles étranges je mets à jour ce qui peut l’être, mais pas tout en une fois si vous êtes encore dans l’incertitude je vérifie les permissions, notamment sur wp-content/uploads et sur les fichiers de configuration
Si vous avez un accès SSH, je n’ignore pas la question des umask et de la structure de permissions.
Cas fréquents et décisions de terrain
“Le site affiche une erreur 500, mais je ne vois rien de suspect”
Souvent, c’est un fichier manquant dans un plugin ou un thème, ou une classe appelée qui n’existe plus. En pratique, vous pouvez restaurer le core et désactiver tous les plugins pour vérifier. Si l’erreur disparaît après désactivation, vous savez que la cause est en général dans wp-content.
Puis vous réactivez plugin par plugin, avec un test à chaque étape. Oui, c’est lent, mais ça réduit les suppositions.
“Un plugin populaire a été modifié”
Si le plugin est modifié mais encore présent, je le supprime et je le réinstalle depuis une source fiable, puis je compare ce que j’obtiens. Ce point est important, car une version téléchargée “par-dessus” peut laisser des fichiers résiduels.
“Le thème a disparu partiellement”
Là, WordPress peut se retrouver avec un thème incomplet. La restauration d’un thème depuis une version officielle est souvent plus efficace que de réparer au hasard. Si des changements personnalisés étaient nécessaires, vous devrez récupérer la version précédente (par exemple depuis une sauvegarde) pour ne pas perdre les modifications légitimes. Sinon, vous repartez sur une base saine et vous réappliquez petit à petit.
Une séquence d’intervention réaliste (sans se raconter d’histoires)
Je garde cette séquence quand je dois agir vite, mais sans courir derrière des hypothèses.
Je duplique le site (fichiers et base si possible), ou je travaille sur un environnement de test. Je restaure le core WordPress proprement, en conservant wp-config.php et le contenu de wp-content. Je neutralise wp-content suspect: désactivation, suppression, remplacement depuis des sources fiables pour les éléments les plus problématiques. Je vérifie les logs et je teste les pages qui redirigeaient ou cassaient. Je reviens sur la base de données si les symptômes persistent.Cette démarche limite les erreurs du type “on nettoie à l’aveugle puis on perd la preuve”. Et elle évite le scénario où vous remplacez les fichiers du core alors que le problème principal est dans un plugin altéré, ce qui masque l’essentiel.
Comment savoir quels fichiers ont réellement été corrompus
Il y a des outils qui comparent, mais même sans outil sophistiqué, vous pouvez avoir des indices solides en observant les timestamps et la structure.
Quand j’inspecte, je cherche:
- des fichiers PHP récemment modifiés dans des dossiers qui ne devraient pas changer des tailles incohérentes, par exemple un petit fichier qui devient énorme des fichiers ajoutés dans des sous-répertoires qui ne servent normalement pas au plugin ou au thème des erreurs “fichier introuvable” côté logs qui pointent vers un chemin précis
Si vos sauvegardes sont disponibles, la comparaison devient encore plus puissante. Le but n’est pas de devenir expert en forensic, c’est de réduire la surface à contrôler. Un chemin suspect identifié dans un log, puis retrouvé comme manquant dans le système de fichiers, vous donne une piste actionnable.
Les sauvegardes: garder un historique, même si ça gêne
Je sais que ça peut sembler contre-intuitif pendant une crise. Mais conserver une copie horodatée est vital. Une sauvegarde peut contenir à la fois des fichiers “propres” et des fichiers “suspects”. Et dans une enquête, c’est utile.
J’ai déjà vu des équipes supprimer des fichiers “pour aller plus vite”, puis regretter quand une restauration partielle a réintroduit un problème. En gardant une trace, on peut comparer et revenir en arrière.
Si votre hébergeur ne garde qu’une seule sauvegarde, essayez de figer votre état avant toute modification majeure. Même une copie manuelle des fichiers et un export de base, ça peut sauver des heures.
Quand faire appel à quelqu’un, et quand vous pouvez avancer seul
Il y a des cas où l’approche maison suffit, et d’autres où vous risquez de tourner en rond.
Si vous avez une sauvegarde fiable, si le site s’effondre avec des erreurs claires (fichiers manquants, plugin désactivé qui rétablit le service), vous pouvez mener l’intervention en interne.
En revanche, si vous n’avez aucune sauvegarde, que le site est régulièrement réinfecté après nettoyage, ou que les logs montrent des signaux de compromission plus large (accès anormaux, comportements réseau suspects, multiples fichiers touchés), il vaut mieux demander une aide spécialisée.
La question n’est pas “est-ce que vous pouvez”, c’est “combien de temps vous allez perdre”. https://gardewp.fr/nettoyage-malware-wordpress/ Le nettoyage virus WordPress prend moins de temps quand l’objectif est net, que le diagnostic est méthodique, et que l’on travaille avec des restaurations cohérentes.
Mini check “restauration” avant de rouvrir au public
Je termine par un contrôle rapide, basé sur ce que je veux voir avant de redonner du trafic au site:
- le site s’affiche sans erreur PHP côté pages qui étaient touchées l’administration se charge sans erreurs et sans réapparition immédiate d’éléments cassés les plugins et thèmes réinstallés correspondent à une version connue fiable wp-config.php et .htaccess n’ont pas de contenu inattendu les logs sur les dernières minutes ne montrent pas les mêmes patterns de requêtes malveillantes
Ce dernier point est crucial, parce que certaines injections se déclenchent seulement après un certain délai ou après un volume de requêtes. Si vous remettez le site en ligne trop tôt, vous pouvez voir la contamination revenir sous un autre angle, puis perdre le fil sur ce qui a été réellement supprimé.
Si votre objectif est de restaurer des fichiers manquants ou corrompus, gardez cette idée en tête: on restaure pour retrouver un état cohérent. Et une fois la cohérence revenue, on nettoie le reste, on sécurise, puis on observe. C’est cette combinaison, plus que le “supposer le malware”, qui fait la différence entre un retour temporaire et un site réellement assaini.