Nettoyage malware WordPress : supprimer les fichiers infectés proprement

Quand un site WordPress se fait infecter, le problème dépasse souvent la simple “suppression d’un fichier”. J’ai déjà vu des équipes supprimer le répertoire visible, puis retrouver le même comportement quelques heures après. La cause n’était pas toujours “un autre malware caché”, mais une combinaison de réinfection (fichier relancé par un mécanisme déjà en place), d’identifiants compromis, ou d’extensions qui n’avaient pas été traitées.

Le nettoyage malware WordPress qui tient sur la durée repose sur un principe simple: on ne nettoie pas seulement des traces, on supprime la source, puis on verrouille ce qui a permis l’intrusion. Dans la pratique, ça veut dire travailler à trois niveaux, souvent en parallèle: les fichiers, la base de données, et l’accès (comptes, clés, tâches planifiées).

Comprendre ce que signifie “supprimer les fichiers infectés” (et ce que ça ne garantit pas)

Un “fichier infecté”, dans un cas WordPress, peut être plusieurs choses:

un fichier ajouté dans l’arborescence du site (par exemple dans wp-content, uploads, ou parfois des emplacements qui ressemblent à des dossiers normaux); un script qui se déguise dans le thème ou un plugin; un fichier qui n’est pas malveillant en lui-même, mais qui sert de déclencheur (un bout de PHP minuscule, un chargement dynamique, ou une redirection); du code injecté dans un fichier existant, sans ajout visible de nouveaux fichiers.

Le piège, c’est que supprimer ce que vous voyez ne suffit pas si la réinfection est alimentée par ailleurs. Un exemple fréquent: un attaquant dépose un petit fichier dans wp-content puis modifie un hook ou un mécanisme (cron, planificateur, option en base) qui recrée le malware. Dans ce cas, vous pouvez supprimer le fichier trois fois, et il revient à chaque visite ou à chaque exécution de tâche.

Autre piège: il arrive que le malware ne soit pas dans les fichiers, mais dans la base (options, scripts stockés, comptes). Pourtant, la demande du jour parle bien de fichiers infectés, donc l’objectif sera de les traiter proprement, sans faire “à la hache” qui casse le site ou supprime des modifications légitimes.

Les premiers signaux: repérer sans aggraver

Avant de toucher au code, il faut observer. Pas besoin d’un audit long, mais quelques repères changent tout.

Sur WordPress compromis, on voit souvent:

du spam généré, pages de redirection, ou injections de liens dans le contenu; des charges système inhabituelles (CPU, requêtes répétées, pics d’erreurs PHP); des alertes Google Search Console, ou des mentions dans les journaux d’activité; des changements côté apparence, même mineurs, comme des scripts dans le header ou un thème “légèrement” différent.

Là où il faut faire preuve de prudence, c’est dans l’accès au site pendant que vous analysez. Si vous laissez tout ouvert, le malware peut continuer à s’exécuter et à se propager, surtout s’il s’appuie sur des accès volés (compte admin, tokens, API). Dans un cadre de réponse rapide, je préfère généralement:

couper le risque pour les visiteurs (mode maintenance ou page statique temporaire); éviter les exécutions “en boucle” pendant que vous explorez les fichiers.

Si vous travaillez sur un environnement de staging, c’est idéal. Sinon, prenez au moins une copie des fichiers et de la base avant toute suppression.

Préparer le terrain: sauvegardes, captures, et séparation des responsabilités

Un nettoyage propre a besoin de deux choses: des copies et une chronologie.

Commencez par faire une sauvegarde complète des fichiers et un export de la base. Ensuite, conservez vos preuves: journaux d’accès, erreurs PHP, et si possible un export des tables (au moins celles qui semblent modifiées). Le but n’est pas la nostalgie. Quand vous découvrez un fichier suspect, vous voulez savoir s’il est apparu après une installation d’extension, une mise à jour, ou une connexion anormale.

J’ai déjà travaillé sur des cas où plusieurs intervenants ont “nettoyé” en parallèle, chacun modifiant des fichiers, sans conserver la version précédente. Le résultat: impossible de déterminer ce qui était réellement malveillant et ce qui venait d’une configuration légitime. Avec WordPress, ce genre de confusion arrive vite, parce que beaucoup de fichiers sont similaires, et que certaines lignes ajoutées peuvent ressembler à du code valide.

Dans une approche disciplinée, vous travaillez toujours sur une base figée: sauvegarde, analyse, puis suppression ciblée.

Cartographier les fichiers suspects dans WordPress

Quand on parle de fichiers infectés, le réflexe est de chercher des “eval”, “base64_decode” ou des chaînes obscures. C’est utile, mais ce n’est pas suffisant. Certains malwares modernes se contentent de déclencher une action en fonction de conditions très spécifiques, comme une variable de requête, un user agent, ou une session.

Votre objectif est de repérer:

les nouveaux fichiers ou dossiers apparus récemment; les modifications de fichiers existants (date de modification incohérente, taille inhabituelle, contenu ajouté); les fichiers PHP contenant un mécanisme de chargement ou d’exécution dynamique; les accès en écriture hors des chemins attendus.

Concrètement, vous pouvez vous appuyer sur la surveillance des dates et sur des recherches de motifs dans l’arborescence. Sur un site WordPress, les emplacements où les surprises sont fréquentes sont wp-content (notamment themes et plugins), mais aussi parfois wp-includes, des dossiers à la racine (index.php modifié), et des uploads si l’attaque a utilisé des formats détournés.

Ne vous limitez pas à wp-content. Une compromission peut aussi viser les fichiers “fonctionnels” de WordPress, ou ajouter des inclusions dans des fichiers déjà connus.

Analyse du code: comment déterminer si c’est vraiment malveillant

Le code suspect n’a pas toujours l’air “malade”. Une simple ligne d’inclusion peut suffire à faire basculer un site, sans que le reste du fichier semble choquant.

Ce que je cherche en premier, c’est la structure du script:

y a-t-il une logique pour échapper à une analyse simple, avec des conditions et des décodages? le fichier tente-t-il d’écrire sur le disque, de télécharger une ressource distante, ou de modifier des options en base? le code est-il “générique” (fonction utilitaire) ou “ciblé” (comportements orientés vers l’URL actuelle, l’utilisateur, ou un paramètre précis)?

Le contexte compte. Si vous voyez un fichier ajouté dans un chemin inattendu, avec un nom qui ressemble à un composant interne, et un contenu qui conditionne un chargement dynamique, le risque est élevé.

À l’inverse, j’ai aussi vu des faux positifs: des fichiers de performance, des outils d’optimisation, ou des bibliothèques vendues par des plugins premium. Le https://gardewp.fr/ bon réflexe est de comparer le fichier à sa version attendue (quand c’est possible) et de vérifier si son code correspond à ce que l’éditeur annonce.

Étape essentielle: isoler le site pour éviter la réinfection

Avant de supprimer des fichiers, il faut réduire les chances que l’attaquant continue.

Si le site est accessible publiquement, le malware peut se relancer à la moindre requête. En réponse, mettez en place une page de maintenance, ou bloquez l’accès au site le temps de l’analyse. Sur beaucoup d’hébergeurs, on peut désactiver temporairement l’exécution PHP dans un environnement de test, ou servir une page statique, pendant que vous nettoyez.

Cette mesure ne remplace pas le nettoyage, mais elle donne une fenêtre stable. Vous pouvez ainsi:

inspecter les fichiers sans “effets de bord” constant; éviter que le malware s’adapte à votre présence; limiter le trafic envoyé vers des destinations externes.

Supprimer les fichiers infectés proprement: une méthode ciblée

“Supprimer les fichiers infectés” doit vouloir dire: supprimer ce qui a été modifié ou ajouté de manière malveillante, sans casser le site.

La méthode que j’utilise le plus souvent ressemble à une chaîne logique:

Identifier précisément le chemin du fichier suspect; Vérifier s’il est nouveau ou s’il a été modifié par rapport à une version attendue; Mesurer ses dépendances apparentes (est-ce qu’il est inclus par un autre fichier? Est-ce qu’il est appelé par une route?); éliminer la source (fichier) et les mécanismes de réactivation (injections dans des options, cron, hooks); Remonter une version saine si un fichier de WordPress ou un thème a été altéré.

Dans certains cas, remplacer un dossier complet est plus fiable que de supprimer quelques lignes. Par exemple, si un thème officiel ou un plugin connu a été modifié, le plus sûr est de réinstaller cette partie depuis une source propre. Pour WordPress et ses composants, la réinstallation peut être nécessaire si wp-admin ou wp-includes a été touché. Pour les thèmes et plugins, c’est souvent la meilleure approche aussi, parce que vous évitez de rater une petite injection dans un fichier secondaire.

Le trade-off: remplacer peut réécraser des personnalisations. Si vous avez un thème sur mesure, remplacez uniquement la partie qui a été infectée, ou récupérez le thème depuis votre base de code et comparez. Dans le doute, vous faites un diff ou vous revenez à une version connue.

Quand les fichiers semblent “propres”, mais que le site reste compromis

Si, après suppression, le site se comporte encore anormalement, c’est souvent un signe que la compromission n’était pas uniquement “file-based”.

Trois sources reviennent très souvent:

Des comptes WordPress compromis, ou des utilisateurs ajoutés; Des clés ou tokens utilisés pour se reconnecter, parfois stockés dans des options; Des injections en base de données, scripts dans des options, ou liens ajoutés dans des entrées.

Même si votre mission initiale est “les fichiers infectés”, ne négligez pas le reste. Sinon vous nettoyez la surface, pendant que la base garde la capacité de réinfection.

Dans la pratique, je fais toujours un contrôle après suppression:

vérifier les utilisateurs existants et leur historique récent; inspecter les options sensibles et les tâches planifiées; surveiller la réapparition de fichiers suspects.

Si un fichier revient, vous avez un mécanisme de réactivation quelque part. Dans ce cas, la suppression seule ne suffit pas, il faut identifier ce qui réécrit.

Contrôle de cohérence: utilisateurs, extensions, et accès

Un nettoyage sérieux implique une vérification des points d’entrée. Le but n’est pas de “faire peur”, c’est de couper la voie.

Vérifiez:

les comptes administrateurs et auteurs, et leurs dates de création; les rôles inattendus (un rôle “Admin” donné à un utilisateur sans raison); les connexions récentes anormales, quand votre hébergeur ou WordPress fournit ces informations; les extensions installées récemment, surtout celles qui ont des permissions élevées ou qui manipulent du code.

S’il y a un doute sur un plugin ou un thème, je préfère le désactiver et le supprimer, puis le réinstaller depuis une source fiable, ou le remplacer. Beaucoup de compromissions commencent par un plugin vulnérable, pas par une brute qui scanne au hasard.

Liste courte de vérifications après suppression des fichiers (1 de 2)

Voici ce que vous pouvez faire sans vous éparpiller, dans l’ordre, après avoir supprimé les fichiers suspects.

Recharger le site en surveillant les logs PHP, erreurs et événements inhabituels. Vérifier dans WordPress les utilisateurs, puis supprimer ceux qui n’ont pas de justification. Désactiver temporairement les extensions ajoutées récemment et tester le comportement. Contrôler les tâches planifiées et la présence d’entrées non attendues. Refaire une recherche ciblée dans le répertoire wp-content pour confirmer qu’aucun fichier suspect n’est revenu.

Cette mini-séquence évite l’erreur classique: “on supprime, tout semble mieux, on oublie de vérifier”, puis le site se re-dégrade.

Rechercher des hooks et déclencheurs invisibles

Quand le fichier https://gardewp.fr/nettoyage-malware-wordpress/ malveillant est retiré, mais que la compromission persiste, on revient à la logique. L’attaquant cherche souvent un déclencheur.

Sur WordPress, les déclencheurs typiques sont:

des hooks dans le thème ou dans des fichiers de plugin; des injections dans des fichiers d’apparence (header, footer, fonctions); des tâches cron planifiées qui exécutent un script à intervalle régulier; des options WordPress modifiées qui stockent des scripts ou des paramètres pour une exécution ultérieure.

Le travail consiste à trouver ce qui appelle votre “fichier suspect”, ou ce qui fait la même chose sans que vous l’ayez identifié. Parfois, le fichier initial est supprimé, mais un second script, moins évident, continue.

Ce type d’enquête demande des comparaisons avec une base saine. Si vous pouvez remonter à une version WordPress saine (même juste les fichiers du core), c’est un gain énorme. Sinon, au minimum, faites une comparaison avec un site similaire ou une copie “propre” que vous auriez avant l’incident.

Le dilemme: réinstaller WordPress, ou corriger au cas par cas?

C’est une question que je vois revenir dès que wp-includes ou wp-admin a été touché.

Si les fichiers WordPress de base semblent modifiés (dates incohérentes, contenu anormal), réinstaller le core est souvent le choix le plus rationnel. Le risque de laisser une petite injection derrière est trop grand. Si seuls certains plugins ont été altérés, la réinstallation ciblée de ces plugins peut suffire, surtout si vous avez la capacité de restaurer les fichiers depuis des versions connues.

Le cas compliqué, ce sont les thèmes personnalisés et les modifications “à la main”. Dans ce contexte, réinstaller peut écraser votre travail. Je recommande alors une approche hybride: restaurer ce qui est standard, et corriger ce qui a été custom, mais uniquement après vérification. Vous remplacez les fichiers que vous ne pouvez pas justifier, vous conservez ceux dont vous pouvez expliquer l’historique.

Exemples concrets de “fichiers infectés” typiques (sans tomber dans le théâtre)

Je ne vais pas vous lister des signatures “universelles”, car elles changent et un attaquant peut les contourner. En revanche, je peux décrire des comportements observés sur le terrain.

Un cas fréquent: un petit fichier PHP dans wp-content, souvent en dehors de dossiers attendus. Le fichier est petit, mais il charge du code depuis une chaîne codée. L’exécution ne se déclenche pas forcément à chaque page. Parfois, elle s’active seulement quand un paramètre est présent, ce qui rend l’infection difficile à diagnostiquer si vous testez “normalement”.

Autre cas: un fichier existant du thème est modifié. Le thème semble fonctionner, le site s’affiche, mais l’éditeur a ajouté un bloc discret, souvent au niveau de la partie qui rend le header ou qui assemble une variable. La conséquence est progressive: au bout de quelques visites, des redirections se mettent en place, ou des scripts externes sont chargés.

Enfin, j’ai déjà vu des attaques où les fichiers sont “propres” pour un visiteur lambda, mais deviennent problématiques pour des robots spécifiques. C’est plus rare, mais ça arrive, surtout quand l’objectif est de pousser du spam SEO ou des pages générées.

Ce que ces exemples illustrent: l’inspection doit aller au-delà du “ça ressemble à du malware”. On cherche la logique d’exécution, pas seulement les mots.

Gérer les cas limites: thèmes et plugins légitimes qui ressemblent à des malwares

Il existe un risque réel de suppression excessive. Certains plugins utilisent du chargement dynamique, compression, minification, ou base64 pour des raisons techniques. Si vous supprimez au hasard, vous pouvez casser un site sans corriger l’incident.

Dans les cas limites, je fais deux choses:

je vérifie le comportement et le contexte d’appel, qui inclut quel fichier, quand, et sous quelles conditions; je compare avec la version attendue du plugin ou du thème.

Quand la comparaison n’est pas possible, la règle pratique est la suivante: si vous ne pouvez pas justifier le rôle du fichier, et qu’il est dans un endroit non standard pour WordPress, vous le considérez comme suspect et vous basculez vers une restauration depuis une source propre.

Après la suppression: nettoyer aussi les traces qui facilitent le retour

Une fois les fichiers malveillants retirés, il reste à faire en sorte que l’attaquant ne retrouve pas le même chemin.

La partie “verrouillage” est souvent plus importante que la partie “fichier”. Je dis ça parce que le malware ne vit généralement pas tout seul, il profite d’une fragilité:

plugin non mis à jour, mots de passe faibles ou réutilisés, manque d’authentification à deux facteurs pour les comptes sensibles, permissions trop larges sur certains dossiers.

Sans entrer dans une longue liste, l’idée est d’améliorer la surface d’attaque. Si vous ne sécurisez pas l’accès, le prochain nettoyage sera juste une répétition du même scénario.

Liste courte pour confirmer que la réinfection ne se produit pas (2 de 2)

Pour savoir si votre nettoyage malware WordPress tient, vous pouvez surveiller sur une fenêtre de temps raisonnable, souvent quelques heures à 24 heures selon la taille du site et l’intensité des visites.

Surveiller les journaux d’erreurs et les pics d’exécution PHP. Rechercher à nouveau les motifs et les fichiers que vous venez de supprimer. Vérifier les fichiers fraîchement créés par rapport à votre historique. Tester plusieurs pages, y compris celles qui servaient de “cible” à l’attaque (home, archives, pages populaires). Contrôler l’apparition de nouveaux utilisateurs ou des changements de rôles.

Si vous constatez de nouveaux fichiers suspects ou des comportements identiques, vous n’êtes pas encore au bout.

Mécanismes de prévention spécifiques après un incident

Après un incident, beaucoup d’équipes se contentent de “mettre à jour et fermer”. Ça aide, mais ce n’est pas une stratégie complète.

Je recommande d’envisager, au minimum:

la rotation des mots de passe des comptes administrateurs et des utilisateurs à privilèges; l’activation de l’authentification à deux facteurs, surtout pour les comptes qui peuvent installer des plugins; la réduction des permissions et la vérification des droits sur les dossiers d’upload et les répertoires où WordPress écrit; la revue de la liste des plugins et thèmes installés, avec suppression de ce qui n’est pas indispensable.

Le but est de réduire les opportunités d’exécution, et de rendre plus difficile la réinstallation furtive d’un fichier.

Quand faire appel à un spécialiste, et quand vous pouvez gérer en interne

Il y a des cas où vous gagnez du temps en confiant le nettoyage à quelqu’un qui a l’habitude de ce type de compromission. Typiquement:

site très complexe, trop de dépendances custom; impossibilité d’accéder aux logs ou à la base de données; réinfection observée malgré plusieurs cycles de suppression; suspicion d’intrusion via le serveur (au-delà du contenu WordPress), comme des modifications au niveau du hosting.

De votre côté, si vous avez un accès raisonnable à l’hébergement, des sauvegardes, et la capacité d’analyser et de comparer des fichiers, vous pouvez souvent gérer le nettoyage.

Ce que je conseille, dans tous les cas, c’est de documenter. Même une note interne, horodatée, avec “ce qui a été retiré et pourquoi”. Cela rend la reprise ou la vérification bien plus simple si un symptôme revient.

Remettre le site en ligne: un retour progressif plutôt qu’un saut

Remettre le site en ligne ne doit pas se faire au hasard.

Une approche pratique consiste à:

restaurer d’abord la stabilité (site accessible, pages principales fonctionnelles); tester des pages et des comportements critiques; surveiller ensuite les logs pour détecter une réactivation.

Quand un site est réinfecté, le retour en ligne déclenche souvent rapidement le comportement malveillant, donc votre période d’observation compte beaucoup.

Si vous avez un mode maintenance, vous pouvez l’utiliser en gardant un accès restreint à l’équipe. Le temps d’un cycle de tests, l’objectif est de valider sans donner trop d’occasions à l’attaquant.

Garder le cap après l’incident: éviter que le prochain “nettoyage” devienne permanent

Un incident WordPress finit rarement par une simple suppression de fichier. La vraie victoire, c’est d’empêcher le prochain. Cela signifie apprendre de l’événement, même si vous ne connaissez pas toujours la cause exacte.

La question à se poser n’est pas seulement “quel fichier était infecté”, mais aussi “comment l’attaquant a obtenu l’accès et pourquoi il a pu écrire”.

Quand vous traitez le problème sous cet angle, la suppression devient un acte final, pas le seul acte. Vous renforcez ce qui protège, vous supprimez la source, puis vous sécurisez le contexte.

Si vous avez déjà eu ce type d’incident, vous savez à quel point il peut être frustrant de “corriger” et de voir revenir le même symptôme. En revanche, quand la démarche est propre, basée sur des sauvegardes, une analyse ciblée, et un verrouillage des accès, le nettoyage malware WordPress devient une correction durable, pas une course de nettoyage sans fin.