Quand un site WordPress commence à se comporter “bizarrement”, la première réaction est souvent de penser plugin compromis, compte administrateur volé, ou spam envoyé depuis le formulaire. Ces pistes sont justes, mais elles laissent parfois de côté une zone très concrète et pourtant souvent négligée: les fichiers présents dans les dossiers wp-content/uploads et parfois dans des chemins “sociaux” comme wp-content/users (ou des sous-dossiers liés à l’utilisateur selon les thèmes, plugins ou habitudes d’hébergement).
Le nettoyage de fichiers infectés WordPress n’est pas seulement une question de supprimer un fichier “malveillant” à l’aveugle. Dans la vraie vie, on gagne du temps quand on sait où regarder en premier, comment vérifier sans aggraver le problème, et comment distinguer une vraie infection d’un incident causé par des mauvaises permissions, un upload légitime mais mal associé à un fichier, ou une configuration qui rend des symptômes visibles.
Dans ce billet, je vais me concentrer sur le chemin qui m’a le plus souvent “raconté l’histoire”: vérifier ce qui traîne dans users et uploads, et relier les indices aux journaux côté serveur et aux comportements côté site.
Pourquoi uploads est si souvent impliqué
Le dossier wp-content/uploads est l’endroit où WordPress stocke les médias. C’est donc aussi l’endroit où un attaquant tente de se cacher avec le meilleur camouflage possible: un fichier qui ressemble à une image, un fichier qui se “déguise” en document, ou un script déposé via un vecteur d’upload (formulaire, plugin de médiathèque, endpoint exposé, compte compromis).
Le scénario classique ressemble à ceci: le site n’est pas “cassé” en continu. Il distribue parfois du contenu étrange, redirige certains visiteurs, ou affiche des scripts côté navigateur. Ensuite, plus tard, on constate une augmentation des requêtes vers des URLs inhabituelles, ou des erreurs 404 sur des chemins qui ne ressemblent à rien. Quand on ouvre uploads, on tombe sur des noms de fichiers incohérents, des extensions suspectes ou des fichiers qui n’ont pas la moindre raison d’exister à cette date.
Ce qui rend la vérification plus délicate que “supprime tout ce qui est bizarre”, c’est qu’il existe aussi des cas légitimes:
- des images dont le nom exact n’est pas identique à celui des médias d’origine (renommage automatique, optimisation, migration), des fichiers ajoutés par des outils d’optimisation d’images, des exports et caches qui se retrouvent parfois au mauvais endroit, des structures créées par des thèmes ou des plugins (par exemple des sous-dossiers dans uploads qui n’étaient pas là au début).
Le bon réflexe, c’est d’assembler les pièces: date de modification, taille, type réel du contenu, et corrélation avec le moment où les symptômes ont démarré.
Ce que signifie “vérifier les fichiers users”
Sur beaucoup d’installations WordPress, on ne rencontre pas un dossier wp-content/users “de base”. Alors pourquoi l’évoquer ici? Parce que dans les incidents réels, les attaquants utilisent souvent des chemins qui sortent de https://gardewp.fr/ l’ordinaire, et parce que certains environnements ou plugins peuvent générer des dossiers “utilisateur” ou des arborescences similaires.
Deux points importent: 1) Un attaquant peut cibler une arborescence que votre site utilise déjà pour du stockage ou de la génération de contenu, même si elle n’est pas “standard WordPress”.
2) Une investigation efficace ne s’arrête pas aux dossiers habituels. Si, dans votre hébergement, vous avez un chemin users, user-uploads, storage/users ou un équivalent créé par un plugin ou une personnalisation, il faut le traiter comme une zone à risque, au même titre que uploads.Ce que j’ai appris au fil d’incidents, c’est qu’un dossier “non standard” est souvent la trace la plus utile. Les attaques qui passent par l’upload ou par une extraction d’archives laissent parfois des empreintes dans ces répertoires-là, même quand l’interface du site semble “normale”.
Première étape: regarder au bon moment et avec le bon angle
Avant de supprimer des fichiers, j’aime établir un repère simple: quand les symptômes ont commencé. Si l’on peut lier le début du problème à une date ou une fenêtre horaire (par exemple, “depuis lundi matin”), on peut ensuite trier les fichiers par date de modification. Sur un site infecté, ce tri ne donne pas une vérité absolue, mais il réduit drastiquement la surface.
Ensuite, je vérifie l’URL ou le comportement qui a déclenché l’alerte:
- redirections vers des domaines inconnus, injection de JavaScript dans des pages précises, chargements de fichiers depuis des chemins bizarres, erreurs 500 récurrentes, tentatives de téléchargement ou d’exécution d’éléments.
Ce lien n’est pas académique. Si, par exemple, les redirections pointent vers un chemin qui existe aussi en tant que fichier dans uploads, on a souvent une piste “directe”. Si au contraire les symptômes proviennent de logique serveur, on regarde davantage les fichiers PHP ailleurs, mais on garde quand même uploads et users sous surveillance, car un script peut déclencher un comportement via une inclusion ou un appel dynamique.
Inspection concrète de wp-content/uploads
L’inspection n’a pas besoin d’être longue si elle est ciblée. Le but est de trouver ce qui ne colle pas.
En pratique, je commence par repérer:
- des fichiers récemment modifiés qui ne ressemblent pas à des médias, des extensions qui ne correspondent pas au contenu, des tailles anormales pour un dossier photo classique, des noms de fichiers trop “génériques” ou trop “structurés” pour être naturels.
Un détail qui revient souvent: des fichiers “image” mais avec un contenu qui n’est pas une image. Si vous ouvrez un fichier prétendument PNG et qu’il contient des lignes PHP, un en-tête étrange, ou des chaînes de caractères typiques d’un script, c’est presque toujours une pièce maîtresse.
Un autre indice utile est la structure du dossier. Un uploads/2024/05 rempli normalement d’images n’a rien à voir avec un dossier où apparaissent soudain des sous-répertoires “inventés” ou des fichiers qui n’ont aucun lien avec le média attendu.
Inspection concrète des chemins liés à users
Pour users, l’approche est la même, mais avec un peu plus de prudence. Si votre dossier users sert à autre chose qu’au stockage de données utilisateur, supprimer sans comprendre peut casser une fonctionnalité.
Je traite donc la vérification comme une enquête:
1) D’abord, identifier exactement où pointe ce dossier depuis WordPress ou vos plugins. Si rien ne l’explique, c’est encore plus probable que l’attaquant l’ait utilisé.
2) Ensuite, repérer les fichiers récents ou les arborescences créées soudainement. 3) Enfin, analyser les fichiers suspects avec une lecture “humaine” du contenu, pas uniquement leur nom.S’il y a des fichiers PHP présents dans un répertoire qui n’est pas censé exécuter du code, c’est un signal fort. Le plus souvent, l’attaque s’appuie soit sur une configuration serveur qui autorise l’exécution, soit sur une inclusion depuis un fichier PHP “légitime”. Les deux pistes se vérifient.
Comment vérifier sans casser, ni vous piéger
Le bon réflexe, c’est d’alterner entre vérification et sauvegarde. Avant toute suppression:
- je fais une sauvegarde complète ou, au minimum, un export des répertoires ciblés (uploads et le dossier users si présent), je garde une copie des fichiers suspects identifiés, je note les chemins exacts.
Il arrive qu’un fichier “suspect” soit en réalité un composant nécessaire à un plugin, surtout après migrations ou mises à jour. Supprimer trop vite, c’est le meilleur moyen d’obtenir une “restauration à la main” plus longue que le nettoyage lui-même.
Ensuite, je fais attention au piège fréquent: confondre un faux positif avec une infection active. Un dossier peut contenir un fichier mal placé mais non exécuté. L’infection active, elle, se manifeste par des inclusions, des appels, ou des comportements visibles. Si vous savez quels URLs déclenchent les symptômes, vous pouvez relier le chemin serveur à ces comportements.
Une checklist de terrain pour trier uploads et users
Voici la méthode courte que j’utilise quand je dois aller vite, sans faire d’erreur bête.
- Triez les fichiers par date de modification et repérez ceux apparus entre le début des symptômes et maintenant. Vérifiez les extensions et, surtout, le type de contenu (un “.jpg” qui contient du PHP n’est pas un média). Contrôlez la taille: des scripts font rarement la taille d’un vrai lot d’images. Recherchez des signatures lisibles dans le contenu (mots clés typiques de code d’attaque ou logique d’exécution), pas seulement dans le nom. Conservez une copie des suspects avant suppression, pour revenir en arrière si besoin.
Cette checklist ne remplace pas une analyse plus fine, mais elle évite de partir sur des suppositions.
Les signatures à chercher, sans tomber dans le délire
Je n’irai pas citer une liste “universelle” de signatures, parce que selon la campagne, la charge utile change beaucoup. Ce qui marche en revanche, c’est d’être attentif à la structure.
Un fichier malveillant dans uploads ou dans un dossier lié à users peut:
- contenir du code qui tente d’exécuter des fonctions serveur, récupérer des données, écrire dans des fichiers, ou appeler des URLs externes, “masquer” sa logique en jouant sur des encodages ou des constructions difficiles à relire.
Le plus simple est de lire le fichier suspect à la main. Si vous voyez https://gardewp.fr/nettoyage-malware-wordpress/ des blocs de logique et des appels qui n’ont aucun rapport avec un média, vous avez votre réponse. Si par contre c’est un fichier vraiment binaire ou un média normal, ne forcez pas.
Un exemple concret: sur un site, j’ai déjà vu des fichiers “.gif” avec un contenu texte. Le serveur répondait correctement aux requêtes image, mais derrière, un script se déclenchait via une inclusion depuis un autre fichier PHP. Tant qu’on ne reliait pas le comportement, on risquait de ne supprimer “que les images”, sans toucher la vraie porte d’entrée.
Relier l’infection aux requêtes réelles
Après la vérification des fichiers, il reste une question: “est-ce que ces fichiers sont réellement utilisés?”. C’est là que les logs valent de l’or.
Selon votre hébergement, vous pouvez accéder à:
- des logs d’accès (Apache/Nginx), des logs d’erreurs, parfois des logs PHP-FPM si configurés.
L’objectif n’est pas de lire tout. Je cherche plutôt:
- des requêtes vers des chemins dans uploads ou vers un chemin lié à users, des motifs de requêtes répétées, des réponses code 200 ou 404 cohérentes avec des fichiers présents.
Si un fichier suspect n’est jamais demandé, il peut être dormant, ou il peut être un résidu d’une attaque avortée. Dans ce cas, la décision de suppression dépend du risque et du niveau de certitude. Pour un site de production, je préfère supprimer ce qui est clairement malveillant, même si c’est “moins actif”, mais je garde toujours la sauvegarde.
Quand supprimer “tout uploads” devient tentant, mais risqué
On entend parfois “supprime tout uploads et restaure”. La tentation est compréhensible, mais c’est rarement propre.
D’un côté, uploads peut contenir suffisamment d’empreintes pour nettoyer vite. De l’autre, vous risquez:
- de supprimer des médias publiés (et donc de casser des pages), de supprimer des documents téléchargés, de perdre des pièces jointes indispensables.
Si votre site contient beaucoup de médias, la restauration après coup devient un projet en soi. Il vaut mieux une approche ciblée, sur les fichiers et sous-dossiers identifiés comme suspects, que de raser tout le répertoire.
Le bon compromis est souvent: sauvegarde, suppression uniquement des éléments clairement malveillants, puis surveillance quelques jours. Le nettoyage efficace est parfois un processus en deux temps.
Cas délicat: plugin de sécurité, cache, et faux positif
Un incident WordPress se mélange parfois à des effets secondaires d’outils de sécurité.
Certains plugins de sécurité créent des dossiers ou des fichiers de logs. D’autres mettent en place des règles qui modifient la façon dont les fichiers sont servis. Si vous supprimez un fichier “pas au bon endroit” sans vérifier s’il vient d’un plugin légitime, vous pouvez déclencher de nouveaux symptômes.
C’est pourquoi je conseille de lier l’incident à:
- la date exacte d’apparition des fichiers, la présence de code exécutable dans des fichiers qui ne devraient pas contenir de logique, les requêtes observées dans les logs.
Si un fichier suspect ressemble à un script et qu’il apparaît en corrélation temporelle avec les symptômes, l’action est plus claire. Si c’est un fichier “bizarre” mais muet dans les logs, je vérifie davantage avant suppression.
Comment traiter ce qui vient de uploads sans casser le site
Quand je décide de supprimer un fichier dans uploads, je le fais en gardant une logique simple:
- d’abord, retirer ce qui est clairement malveillant et non média, ensuite, vérifier que le site charge correctement les médias restants, enfin, recontrôler les logs pour voir si les requêtes suspectes cessent.
Il m’est arrivé de supprimer un fichier suspect, puis de constater que des redirections continuaient. Dans ce cas, ce n’était pas le point d’entrée. Le fichier avait probablement été un lien, une étape secondaire, ou une “charge” déployée par ailleurs. L’étape “uploads nettoyé” était juste une pièce du puzzle.
C’est aussi pour ça que vérifier users et uploads ne doit pas vous empêcher d’examiner d’autres zones si nécessaire, notamment la partie code qui gère les pages où l’injection se produit.
Exemple de trajectoire de réponse rapide (sans théâtraliser)
Sur un incident que j’ai géré, le site affichait des scripts ajoutés dans le HTML de certaines pages. Le premier diagnostic montrait une modification récente d’un fichier PHP dans un répertoire inattendu. Mais la trace la plus visible était dans uploads: un ensemble de fichiers dont les noms ressemblaient à des images, mais dont le contenu était du texte.
La suppression ciblée a stoppé une partie des symptômes, mais pas tous. Les logs montraient encore des requêtes vers des chemins dans le même répertoire, mais avec d’autres noms. Le second passage a révélé des fichiers additionnels, plus profonds, dans une arborescence liée aux utilisateurs. Une fois ces éléments supprimés et après réinitialisation des accès compromis, le comportement malveillant a cessé.
Le point à retenir: dans les infections qui touchent plusieurs emplacements, un nettoyage partiel peut sembler “réussir” puis échouer. Mieux vaut une stratégie progressive, documentée, et basée sur ce que les logs montrent.
Sécuriser après nettoyage, parce que le risque revient vite
Le nettoyage de fichiers infectés WordPress n’a de sens que si vous réduisez la probabilité de réinfection. Sinon, vous chassez le symptôme, pas la cause.
Après avoir inspecté uploads et users, je vérifie généralement:
- les comptes administrateurs (surnoms, dates de création, rôles inhabituels), les méthodes d’authentification et l’usage des comptes, la présence de fichiers de type “webshell” ailleurs que dans uploads.
Je reste volontairement prudent sur “ce qu’il faut faire absolument” parce que chaque hébergement a ses mécanismes. Mais une règle simple s’applique presque partout: tant que l’accès à la machine n’est pas verrouillé, la suppression des fichiers ne suffit pas.
Quand faire appel à un audit plus profond
Si, après nettoyage ciblé de uploads et de ce qui ressemble à users, les symptômes persistent, il faut changer d’échelle. Les causes possibles incluent une porte d’entrée ailleurs dans l’installation, une compromission d’identifiants, ou une configuration serveur.
Dans ces cas, je privilégie une approche d’audit:
- comparaison des fichiers modifiés avec une version attendue (selon thème, plugins et WordPress installé), recherche d’inclusions ou de liens entre fichiers suspects, analyse plus poussée des logs pour repérer les appels qui déclenchent l’injection.
Il y a des infections où uploads et users sont des conséquences, pas la cause. Les traiter reste utile, mais il ne faut pas s’enfermer dans une seule hypothèse.
Deux décisions à prendre avant d’appuyer sur “supprimer”
Beaucoup de dégâts arrivent après coup, parce qu’on a supprimé un élément sans avoir répondu à deux questions.
1) Est-ce que le fichier est clairement malveillant, ou est-ce un faux positif plausible?
2) Est-ce que le fichier est actif, c’est-à-dire présent dans les requêtes, ou seulement “là”, sans effet?Pour trancher, je reviens toujours à la combinaison: date, contenu, et logs. Une extension suspecte sans logique, ou un fichier ancien sans requêtes, ne pèse pas autant qu’un script récent demandé massivement.
Guide rapide des vérifications “logiques” après coup
Une fois que vous avez fait le tri et la suppression ciblée, il faut confirmer que le site est de nouveau stable.
Indicateurs simples à observer
- Les pages qui affichaient l’injection redeviennent normales, sans délai bizarre. Les erreurs 404 massives vers des chemins inconnus diminuent ou cessent. Les requêtes vers des fichiers présents dans uploads ou users suspects disparaissent des logs.
Si ces trois signaux ne bougent pas, il y a une chance réelle que l’entrée de l’attaque soit ailleurs.
Pour résumer sans simplifier à l’excès
Vérifier les fichiers users et uploads, c’est souvent là que se cache la trace la plus concrète de l’infection. uploads attire parce qu’il s’alimente en médias, et c’est justement ce qui rend un fichier caché dedans difficile à repérer. users (ou son équivalent non standard dans votre environnement) devient une zone stratégique quand l’attaquant détourne des répertoires déjà “acceptés” par le site ou le serveur.
Le nettoyage efficace de fichiers infectés WordPress repose sur une discipline: trier par date, lire le contenu au lieu de se fier uniquement au nom, et valider l’impact avec les logs. La suppression est ensuite une décision informée, avec sauvegarde pour éviter le pire scénario, celui où vous réparez un symptôme mais cassez le site.
Si vous voulez, vous pouvez me décrire votre contexte (type d’hébergement, comportement observé, présence d’un dossier users à quel emplacement exact, et ce que vous voyez dans uploads). Je peux vous proposer une démarche de vérification plus ajustée à votre cas, toujours en restant sur des actions prudentes et défendables.