Supprimer malware WordPress : supprimer les fichiers .php dissimulés

Quand un site WordPress est touché, on croit souvent que le problème se résume à “un fichier à supprimer”. Dans les faits, le malware se comporte comme un caméléon: il se cache, se renomme, se mélange aux dossiers du thème, ou profite d’une faille d’identifiants. Le résultat ressemble à autre chose, parfois à une simple lenteur, parfois à une redirection étrange, parfois à des Continuer la lecture injections de contenu sans logique apparente.

Ce qui revient le plus souvent dans les cas que je vois sur le terrain, ce sont des fichiers .php “dissimulés” quelque part dans l’arborescence, avec des noms peu parlants, parfois dans des dossiers qui n’existent pas normalement, ou dans des chemins qui ne devraient contenir que des assets. L’objectif de cet article est simple et concret: vous aider à repérer ces fichiers, comprendre pourquoi ils existent, et les supprimer proprement, sans casser le site ni laisser derrière vous une porte d’entrée.

Les signes qui orientent vers des .php dissimulés

Avant de toucher aux fichiers, il faut regarder les indices. Les attaques ne se manifestent pas toujours par une page “piratée” évidente. Souvent, le site continue de fonctionner, mais il fait des choses en arrière-plan.

Quelques signaux typiques:

du contenu injecté dans certaines pages (scripts, iframe, liens “étranges”) des redirections vers des sites externes, parfois seulement sur certaines URL des tentatives de téléchargement ou d’ouverture de fichiers inhabituels des emails générés depuis WordPress sans action de l’utilisateur une augmentation brutale des requêtes, du trafic sortant, ou des erreurs 404 liées à des paramètres bizarres

Le lien avec les fichiers .php dissimulés est fréquent quand vous observez des accès au serveur sur des chemins qui ne vous disent rien. Les logs serveur (Apache ou Nginx) sont souvent plus révélateurs que l’interface WordPress. Si vous voyez des requêtes vers des scripts que vous n’avez jamais créés, ou vers des noms de fichiers en apparence aléatoires, c’est un bon motif pour investiguer le système de fichiers.

Pourquoi le malware se cache dans WordPress

WordPress a une structure assez prévisible, ce qui est une bonne nouvelle pour le nettoyage, mais aussi une “signature” que les attaquants apprennent à contourner. Ils peuvent:

déposer un fichier .php dans un dossier qui n’a rien à faire là, puis l’appeler via un lien ou un script injecté se cacher dans un répertoire déjà toléré par WordPress (thèmes, uploads, parfois même dans des sous-dossiers ignorés par votre routine de maintenance) utiliser des noms de fichiers proches de l’existant pour passer inaperçus, par exemple un fichier avec un nom très long ou composé de caractères “banals” modifier des fichiers “légitimes” (index.php, functions.php, des composants chargés tôt) pour exécuter le malware indirectement

Même si vous supprimez le premier fichier trouvé, si vous laissez une modification dans un fichier fonctionnel, l’infection peut revenir. C’est pour cela que le nettoyage doit être méthodique, surtout autour des .php “cachés”.

La méthode qui évite la casse: d’abord regarder, ensuite décider

Je recommande de commencer par préparer un environnement de travail. Supprimer au hasard, c’est le meilleur moyen d’abîmer un thème, un plugin, ou un fichier dont vous ignoriez l’usage. Sur un site actif, chaque changement peut impacter des visiteurs.

Concrètement, avant toute suppression:

Faites une sauvegarde complète (fichiers + base de données) Identifiez le moment où l’anomalie apparaît (sur quelles pages, pour quels utilisateurs, à quelle fréquence) Repérez l’étendue probable (un dossier complet infecté, un seul fichier, des modifications multiples) Gardez un relevé de ce que vous trouvez (chemins exacts, dates de modification, tailles approximatives)

Dans les cas les plus pénibles, le malware a modifié plusieurs fichiers .php, pas seulement un. Parfois, il touche aussi des fichiers dans wp-content/uploads ou dans des répertoires que vous n’avez jamais examinés de près.

Repérer les fichiers .php dissimulés: indices dans le nom, le chemin, la date

Les “fichiers .php dissimulés” ne se limitent pas à des noms en clair. Souvent, ils ressemblent à des fichiers temporaires, ou à des noms sans rapport avec votre activité. La dissimulation peut aussi être liée au contexte:

un .php dans wp-content/uploads, alors que vous n’y stockez généralement que des images, PDFs et médias un .php dans un dossier de thème ou plugin, là où vous n’avez pas ajouté de code récemment un fichier dans un dossier que WordPress n’utilise pas explicitement, ou que vous utilisez peu des dates de modification très proches du moment où le site a commencé à dérailler des tailles très petites pour un fichier soi-disant “utile”, ou au contraire énormes pour une page “sur mesure”

La date de modification est particulièrement utile, à condition que votre hébergement enregistre correctement ces métadonnées. Sur certains systèmes, la date peut être moins fiable, notamment après des mises en place de sauvegardes, des déploiements automatiques, ou des outils de copie.

Outils et approches possibles, sans dépendre d’un seul angle

Il existe plusieurs façons d’inspecter. L’idée est de ne pas dépendre d’une seule méthode, car un malware peut contourner un outil spécifique.

Vous pouvez combiner:

un scan de sécurité côté WordPress avec un plugin de détection, utile pour repérer des signatures ou des comportements un examen “fichier par fichier” via SFTP ou le gestionnaire de fichiers de l’hébergement l’analyse des logs pour découvrir quels chemins sont appelés la vérification des fichiers modifiés récemment dans wp-content et wp-admin

J’ai souvent vu des cas où un plugin de sécurité liste des “suspicious files” mais ne comprend pas le contexte, et inversement des cas où l’examen manuel rate le fichier, mais les logs révèlent son existence parce qu’il est exécuté régulièrement.

Avant de supprimer: vérifier si le fichier sert de point d’entrée

Suppression ne veut pas dire “action immédiate sans réflexion”. Un fichier .php dissimulé peut être le point d’entrée direct, ou juste un composant appelé par autre chose.

Quand vous repérez un fichier suspect, ouvrez-le en mode lecture, ne le modifiez pas. Souvent, vous verrez:

un code qui s’exécute et fait une requête sortante des appels à base64 decode, gzinflate, eval, strrot13, ou des chargements dynamiques une logique conditionnelle basée sur l’URL, l’utilisateur, l’agent, ou des paramètres GET une écriture de fichiers, une commande système, ou une tentative d’exfiltration

Si vous êtes dans un environnement contraint où vous ne pouvez pas lire facilement le contenu (hébergement très verrouillé, restrictions), au moins notez taille et chemin, et utilisez un outil de scan. Mais idéalement, voir le contenu aide énormément à décider si c’est un vrai malware ou une “fausse alerte”.

Checklist de triage: quoi faire dès maintenant

Voici une mini check-list réaliste pour rester efficace, surtout quand vous êtes face à un site qui ne répond plus correctement.

Téléchargez une sauvegarde complète avant de toucher aux fichiers Notez les chemins suspects et les dates de modification Ouvrez le contenu des .php suspects pour comprendre leur rôle (sans les exécuter) Vérifiez les logs pour voir quels fichiers sont appelés récemment Confirmez que vos accès WordPress et FTP sont sécurisés (mots de passe, comptes)

Ce triage vous évite d’entrer dans un “nettoyage au doigt mouillé” qui finit souvent en boucle.

Supprimer les fichiers .php dissimulés: procédure propre, du plus simple au plus sûr

Une fois que vous avez identifié des fichiers .php réellement suspects, la suppression doit être précise. Le principal piège est de supprimer trop large. Par exemple, supprimer un répertoire complet peut casser un thème personnalisé. À l’inverse, supprimer un fichier sans corriger l’origine (modifications sur functions.php, ajout de cron, backdoor dans un plugin) peut laisser le malware revenir.

La procédure que je conseille dans la plupart des cas:

Isolez le site si nécessaire (mise en mode maintenance si l’impact est fort) Supprimez uniquement le ou les fichiers confirmés comme malveillants Remettez à l’état sain les fichiers modifiés (si vous avez une référence avant infection) Vérifiez et supprimez les points d’entrée indirects (cron, fichiers injectés, scripts appelés) Redémarrez en surveillant les logs, au minimum pendant quelques heures

Cette approche limite les dégâts et vous donne un signal clair: si les requêtes et la charge retombent, vous avez probablement coupé le flux principal.

Où chercher en priorité (sans supposer que “c’est forcément là”)

Le malware adore wp-content, surtout parce que c’est là que votre site “se personnalise”. Pourtant, certains attaquants peuvent agir ailleurs. J’ai tendance à prioriser les zones où il y a le plus souvent des points de mélange entre “code exécutable” et “contenu”.

En pratique, les emplacements qui reviennent souvent quand on parle de .php dissimulés:

wp-content/uploads: surtout s’il y a des fichiers .php, .phtml ou des extensions qui ne devraient pas être là wp-content/themes ou wp-content/plugins: si vous voyez un fichier qui n’a pas de raison d’exister la racine WordPress (parfois): rarement mais possible, si des scripts ont été déposés ou si des fichiers initiaux ont été modifiés des sous-dossiers inattendus dans wp-content: répertoires “créés à la volée” ou à noms peu cohérents

La règle d’or reste la même: on ne supprime pas parce que “ça ressemble”. On supprime après recoupement avec les dates, le contenu, et l’observation du comportement.

Surveiller après suppression: les logs ne mentent pas

Une fois le ou les fichiers malveillants supprimés, attendez-vous à un effet immédiat… ou à une disparition progressive. Si le malware avait plusieurs chemins d’exécution, il peut continuer un peu avant de se calmer.

Regardez principalement:

les requêtes répétées vers des chemins disparus les erreurs 404 nouvelles (elles peuvent indiquer que quelqu’un essaie encore d’atteindre le script supprimé) la charge CPU et la fréquence des appels “anormaux” les redirections si elles étaient déclenchées par un script

Si les requêtes continuent vers des fichiers que vous avez supprimés et que le comportement se poursuit, il y a de grandes chances que d’autres éléments soient encore en place. Dans ce scénario, vous reprenez l’analyse: quel autre fichier .php est appelé, où est la chaîne de détection, et quel composant a pu rester.

Nettoyer la source: mots de passe, comptes, et accès FTP/SFTP

Un point souvent sous-estimé: supprimer les fichiers .php dissimulés ne suffit pas si les identifiants sont encore compromis. Si quelqu’un a la main sur le serveur, il pourra réinjecter le malware en quelques minutes, parfois sans même vous laisser le temps de comprendre.

Donc, après le nettoyage de fichiers:

changez tous les mots de passe WordPress, et aussi ceux des comptes d’hébergement si vous avez utilisé les mêmes vérifiez l’apparition de nouveaux utilisateurs WordPress supprimez les comptes inconnus, même s’ils semblent “inactifs” contrôlez les sessions actives si votre hébergement ou votre plugin de sécurité le permet révoquez les clés API et revalidez les connexions FTP si vous en avez

Le but est de fermer la porte, pas seulement de retirer l’outil.

Base de données: quand supprimer ne suffit pas

Le malware peut aussi laisser des traces dans la base de données: options modifiées, champs d’options injectés, schedules (cron) ajoutés, utilisateurs ajoutés, ou contenu inséré dans des pages.

Vous pouvez trouver des indices dans:

les options qui contiennent des scripts ou des données suspectes les posts/pages qui contiennent du code injecté la présence d’un événement cron qui déclenche un script

Sans faire d’inventaire “au hasard” dans la base, je recommande d’associer la base à ce que vous avez vu côté fichiers et logs. Si vous avez repéré une injection sur certaines pages, regardez le contenu de ces pages dans WordPress. Si un fichier .php suspect était appelé, cherchez s’il existe une trace d’appel dans une option, une action, ou un cron.

En cas de doute, vous repartez d’une sauvegarde propre, vous comparez, et vous ne cherchez pas à “réparer” une base infectée en direct si le risque est élevé.

Edge cases qui compliquent la suppression

Certaines situations font dérailler les nettoyages “standards”.

Votre thème ou plugin a été remplacé

Parfois le malware ne crée pas seulement un fichier, il remplace un fichier existant. Dans ce cas, supprimer le nouveau fichier ne règle pas le fond. Il faut restaurer la version saine de ce composant, depuis un dépôt fiable ou une sauvegarde.

Des fichiers générés automatiquement

WordPress peut générer des fichiers, et certains plugins produisent du code à l’exécution ou des caches. Un .php dans un dossier d’upload peut être légitime dans un cas très spécifique, mais c’est rare. La différence se joue dans la cohérence avec votre configuration et l’historique des modifications.

Des permissions et blocages

Après suppression, si le fichier “revient”, ce n’est pas forcément un miracle. C’est souvent le résultat de permissions, d’outils de déploiement, ou d’un système de synchronisation (CI/CD, backup restore automatique) qui replante un fichier depuis une archive infectée. Pensez à l’origine des sauvegardes et au moment où vous avez pris le dernier bon snapshot.

DNS ou hébergement compromis

Si le serveur lui-même est compromis, vous pouvez supprimer le malware WordPress et voir le site se “reinfecter” via d’autres vecteurs. Dans ce cas, le nettoyage WordPress est nécessaire, mais pas suffisant. Il faut traiter l’incident côté infrastructure.

Ces cas ne sont pas des exceptions rares. Ils expliquent pourquoi certains “nettoyages” donnent un site propre le jour J, puis de nouveaux symptômes le lendemain.

Exemple concret de démarche sur un cas typique

Imaginons un site e-commerce qui commence à rediriger des visiteurs vers une page externe, seulement sur une poignée d’URL. Le plugin de sécurité détecte une alerte générique, mais la liste n’est pas claire.

En inspectant, vous trouvez un fichier .php dans wp-content/uploads, avec un nom qui ne correspond à aucun média réel. Sa date de modification tombe le jour où les plaintes ont commencé. En ouvrant le fichier, vous voyez qu’il lit l’URL demandée et renvoie une redirection en fonction de paramètres, puis tente une requête sortante.

Vous le supprimez, vous surveillez les logs pendant deux heures, et vous observez une baisse nette des requêtes vers ce chemin. La redirection, elle, diminue. Bonne nouvelle, mais ce n’est pas terminé, parce que les pages “injectées” dans le thème persistent. En recoupant, vous remarquez que functions.php a été modifié pour inclure le comportement sur certaines pages.

Dans ce scénario, vous comprenez la logique: un fichier .php dissimulé était le déclencheur ou l’étape technique, mais une autre modification assurait la persistance et l’injection. Le nettoyage efficace est celui qui coupe les deux.

Pourquoi je privilégie une suppression ciblée plutôt que “effacer tout”

Il peut être tentant de restaurer tout WordPress et ses thèmes “à zéro”. Parfois, c’est une bonne option. Mais si votre site est complexe, avec des customisations, des contenus et des plugins sur mesure, repartir à zéro peut coûter cher en temps, et parfois en fonctionnalité.

La stratégie la plus saine dépend de votre situation:

Si le site est modeste et que vous avez de bonnes sources pour restaurer, la réinstallation peut être rapide. Si le site est vivant et personnalisés, un nettoyage ciblé, avec sauvegarde et comparaison, évite de casser une chaîne de dépendances. Si le serveur est fortement compromis, même une suppression ciblée peut être une demi-mesure.

Dans tous les cas, l’objectif est le même: supprimer le malware WordPress, mais surtout supprimer ce qui permet au malware de revenir.

Remettre le site en ligne avec un minimum de risque

Avant de remettre complètement le site en production:

relancez en mode maintenance si vous avez la main dessus, le temps de vérifier les comportements testez les pages qui étaient touchées, depuis plusieurs navigateurs vérifiez que l’administration WordPress charge normalement surveillez les logs sur un créneau suffisant pour capter une éventuelle réinjection gardez une copie de ce que vous avez supprimé, si votre cadre interne le permet, pour comprendre et documenter l’incident

Ce dernier point sert même quand tout semble “réglé”. Si vous détectez plus tard une trace similaire sur un autre site, vous gagnez du temps.

Garder une hygiène de prévention réaliste

Supprimer les fichiers .php dissimulés, c’est la partie visible. La prévention, c’est la partie qui fait gagner des mois, parfois.

Je ne parle pas de “sécurité parfaite”, mais de bonnes habitudes qui réduisent la surface d’attaque:

mises à jour régulières de WordPress, thèmes, plugins suppression des plugins inutilisés mots de passe robustes, pas réutilisés limitation des tentatives de connexion et contrôle des accès sauvegardes testées, restaurables, pas juste “faites”

Et si votre hébergement propose des mécanismes de durcissement (limitation d’exécution, configuration sécurisée), c’est souvent là que vous évitez la prochaine infection.

Si vous voulez, décrivez votre cas en quelques détails (taille du site, emplacement suspect exact, comportement observé, si vous avez accès aux logs). Je pourrai vous proposer une démarche de triage plus ajustée, notamment pour décider entre suppression ciblée, restauration de thème, et inspection de la base de données.