Désinfection WordPress : nettoyer les fichiers uploads compromis

Quand un site WordPress se met à agir “bizarrement”, la tentation est de courir partout, supprimer des fichiers ici, changer des mots de passe là, puis espérer que tout rentre dans l’ordre. Sur le papier, ça paraît logique. Dans la réalité, une désinfection réussie dépend d’un point trop souvent négligé: comprendre d’où vient la compromission, puis nettoyer ce qui a réellement été modifié, surtout dans le dossier uploads.

Parce que oui, le chemin le plus fréquent vers des dégâts se trouve parfois dans un endroit banal: les fichiers médias. Le dossier wp-content/uploads est fait pour recevoir des images, des PDF, des vidéos. Les attaquants savent très bien en profiter. Ils y glissent des fichiers détournés, parfois avec une extension trompeuse, parfois en jouant sur la façon dont WordPress et le serveur interprètent le contenu. Résultat: une “désinfection WordPress” incomplète donne souvent un faux sentiment de sécurité. On redémarre le site, les symptômes baissent, puis ils reviennent, parfois quelques heures ou jours plus tard.

Je vais vous guider dans une approche pratique: comment repérer les signaux, ce qu’il faut contrôler spécifiquement dans uploads, comment décider du bon niveau d’action, et quelles erreurs évitent de tomber dans le piège des nettoyages partiels.

Comprendre ce qui se cache dans uploads

Le dossier uploads n’est pas juste un répertoire de stockage. Il est à la fois une zone de confiance “faible” et une zone d’exposition. “Faible” parce qu’il reçoit des entrées via le formulaire WordPress ou via des processus automatisés, et parce que, selon la configuration du serveur, certains fichiers peuvent être interprétés autrement que prévu.

Une image malveillante, un fichier qui contient un script, un PHP “déguisé” en document, un webshell qui s’exécute via une règle serveur, tout cela n’a rien de théorique. J’ai vu des campagnes où l’attaquant ne touche pas immédiatement aux fichiers PHP classiques de WordPress. Il commence par déposer un truc dans uploads, puis il met en place ailleurs la façon de déclencher le chargement et l’exécution.

Ce que cela implique en pratique, c’est que vous devez traiter uploads comme une surface d’attaque. Pas comme une simple corbeille à “nettoyer au feeling”. Une suppression trop agressive peut casser une partie de votre contenu, et une suppression pas assez profonde laisse un artefact actif qui reviendra hanter le site.

Les symptômes qui orientent vers une compromission liée aux fichiers

Tous les sites compromis ne se ressemblent pas. Pourtant, certains symptômes donnent des indices solides vers un problème de fichiers, dont une partie peut se trouver dans uploads.

Quand vous observez une redirection vers une page de spam, une injection de contenu dans le thème, ou des visiteurs qui tombent sur des pages inattendues, vous pensez “fichier PHP modifié”. Mais j’ai souvent vu le scénario où les fichiers PHP “semblent” intacts au premier coup d’œil, et où la vraie source est dans le chargement dynamique de médias, dans des scripts dissimulés, ou dans des fichiers qui servent ensuite de relais.

Des signaux plus discrets existent aussi:

Une hausse anormale de la taille de wp-content/uploads sur une période courte, sans publication correspondante. Des fichiers récents avec des noms aléatoires, parfois sans extension claire, parfois avec des extensions qui ne matchent pas votre historique éditorial. Des erreurs 403 ou 404 inhabituelles, corrélées à des requêtes externes. Par exemple, des tentatives de chargement répétées d’un fichier “image” qui n’a jamais été publié. Un comportement étrange après que vous avez “juste” mis à jour un plugin. Parfois, la compromission ne se déclenche pas au même moment que l’infection initiale.

Le point important: ne partez pas du principe que parce que l’interface ne ressemble à rien d’anormal, tout est propre. Une désinfection sérieuse s’appuie sur des preuves, pas sur des impressions.

Préparer le terrain avant de nettoyer

Avant de toucher aux fichiers, je recommande toujours de mettre votre organisation en mode “intervention”. Cela réduit le risque d’aggraver la situation et de perdre des informations utiles.

Commencez par sécuriser l’accès. Si vous avez des identifiants d’administration potentiellement compromis, ils ne sont plus fiables. Révoquez les sessions, changez les mots de passe depuis une connexion saine, et vérifiez si des comptes utilisateurs ont été créés sans que vous l’ayez décidé. Même si le sujet principal ici est uploads, la compromission touche souvent plusieurs couches.

Ensuite, faites un diagnostic qui vous servira pendant le nettoyage. Les meilleurs nettoyages que j’ai menés avaient tous un point commun: j’ai conservé des traces. Une liste des fichiers récemment modifiés, un relevé des tailles, une capture des erreurs applicatives, et la preuve de ce qui a été supprimé ou remplacé.

Enfin, travaillez sur une copie quand c’est possible. Si vous avez accès à un environnement de staging, mieux vaut y reproduire. Sur un hébergement mutualisé qui ne permet pas de tout, au minimum, gardez une sauvegarde complète. Je parle d’une sauvegarde restaurable, pas juste d’une export “contenu” de WordPress.

Contrôler ce qui a changé, au bon endroit

Le cœur de votre demande, c’est la désinfection des fichiers uploads compromis. Pour y arriver, il faut une méthode de tri. Sinon, vous allez scroller des milliers de fichiers et finir par “choisir au hasard”. Et c’est précisément le genre d’erreur qui laisse un webshell ou un fichier actif derrière.

L’idée est simple: repérer les fichiers et signatures anormales, puis décider si on supprime, remplace, ou isole.

En pratique, vous pouvez vous appuyer sur plusieurs axes sans avoir besoin d’un outil magique:

D’abord, l’âge. Si votre site publie régulièrement des images, vous verrez des dates cohérentes avec l’activité éditoriale. Un lot de fichiers dont les dates sont concentrées sur une fenêtre très courte, sans correspondre à une campagne, doit attirer l’attention.

Ensuite, la forme. Les médias ont des extensions attendues. jpg, png, gif, webp, pdf, mp4, zip parfois si vous distribuez des ressources. Les fichiers “en trop” avec des extensions inattendues, ou des noms qui ressemblent à des identifiants, posent question.

Enfin, le contenu et la signature. Un script dans un fichier déguisé n’a pas forcément l’air d’un script vu de l’extérieur, mais il laisse souvent des chaînes de code ou des motifs reconnaissables. C’est là que votre méthode devient plus technique, et que le serveur (PHP interprété ou non) joue un rôle.

Je vous donne une approche de tri orientée opération, avec un minimum de listes.

Checklist de tri rapide sur uploads

Vérifier l’évolution de la taille du dossier wp-content/uploads et repérer les périodes de croissance sans production éditoriale. Lister les fichiers modifiés récemment dans wp-content/uploads, puis comparer aux heures de publication connues. Repérer les extensions hors catégorie, et les fichiers dont les noms ne correspondent à aucun modèle habituel. Inspecter le contenu des fichiers suspects (recherche de motifs de code, balises PHP, fonctions d’exécution, appels réseau). Faire attention aux fichiers “à la marge”, comme ceux situés à la racine de uploads alors que vous n’y stockez normalement rien.

Cette checklist n’est pas un rituel, c’est un filtre. Elle vous évite de confondre “fichier récent” et “fichier malveillant”, car parfois un média est importé, ou une migration a été faite.

Inspecter sans casser: quoi chercher exactement

Quand vous inspectez uploads, gardez une idée en tête: l’attaquant cherche l’exécution ou le déclenchement. Les fichiers “scripts” peuvent être stockés avec des extensions trompeuses. Mais même sans extension exécutable, ils peuvent être servis ou manipulés par d’autres scripts présents sur le serveur.

J’ai déjà vu des cas où l’upload était une étape. Le webshell était dans uploads, mais c’était une autre pièce ailleurs qui déclenchait l’appel. Inversement, il peut y avoir un fichier “outil” dans uploads et une modification de WordPress (ou du thème) ailleurs.

Donc, dans vos recherches, regardez:

Les fichiers avec du code au sein du contenu. Même s’ils portent une extension “image” ou “pdf”, un test de contenu peut révéler des morceaux de PHP, ou des chaînes typiques de chargement dynamique.
Les fichiers avec des noms dont la structure ne ressemble pas à vos habitudes. Par défaut, WordPress renomme souvent en ajoutant des suffixes numériques. Si vous voyez des noms aléatoires très spécifiques, ça peut venir d’un outil.
Les fichiers dans des sous-dossiers inattendus. Par exemple, vous avez peut-être vos médias dans uploads/2024/05/. Si vous trouvez une arborescence non habituelle, ou des fichiers directement dans uploads/ racine, c’est un drapeau.
Les “petits fichiers” suspects. Un script en PHP peut faire quelques kilo-octets. Un média image, lui, a un poids qui suit des tailles réalistes. Évidemment, il existe de très petites images (logos), mais combinées avec une extension bizarre et une date récente, ça suffit.

Le piège des suppressions partielles

Nettoyer “tout ce qui a l’air suspect” est satisfaisant, mais risqué si la détection est approximative. Un excès de prudence peut laisser un fichier actif. Un excès de zèle peut casser des médias légitimes, et surtout, vous priver de la preuve nécessaire si l’incident revient.

Un bon réflexe que j’ai appris sur le terrain: commencez par neutraliser ce qui peut exécuter du code, puis élargissez le nettoyage.

Pour la partie uploads, neutraliser ne veut pas dire juste “supprimer”. Cela peut vouloir dire restreindre l’interprétation côté serveur, rendre les fichiers non exécutables, ou isoler les éléments suspects dans un dossier temporaire.

Selon votre configuration d’hébergement, la façon exacte de procéder change. Sur un serveur qui exécute PHP dans uploads (ce qui n’est pas censé arriver si les règles sont bonnes), un fichier webshell aura une capacité directe. Sur un serveur bien configuré, il peut rester comme un outil inactif, mais déclenchable via d’autres vecteurs.

Le point clé: comprendre le modèle de risque de votre serveur, pas seulement ce que WordPress a “déposé”.

Une méthode de désinfection WordPress centrée uploads

Je vais vous donner une séquence pratico-pratique. L’idée n’est pas d’être “parfait” dès la première passe. Elle est d’être fiable, reproductible, et capable d’absorber les surprises.

Étapes concrètes, dans l’ordre qui limite les dégâts

Mettre le site en mode maintenance, révoquer les sessions et sécuriser l’accès admin (mots de passe, comptes créés, plugins inconnus). Faire une sauvegarde complète incluant wp-content/uploads et les fichiers WordPress concernés, même si vous finissez par tout restaurer. Identifier les fichiers suspects dans wp-content/uploads (dates, extensions, contenu), puis isoler les plus dangereux (au minimum, ceux qui contiennent des marqueurs de code). Supprimer ou remplacer proprement les fichiers confirmés malveillants, puis vérifier que les URLs incriminées ne renvoient plus de contenu actif. Recontrôler après redéploiement (nouveaux fichiers apparus, recréations, requêtes répétées), puis seulement ensuite restaurer la disponibilité normale du site.

Ce que j’aime dans cette approche, c’est qu’elle sépare l’urgence de la preuve. On ne “nettoie” pas aveuglément avant d’avoir neutralisé l’accès et figé une base. Vous évitez ainsi de détruire ce que vous auriez dû analyser, ou pire, de laisser le temps à l’attaquant de rejouer les mêmes actions pendant que vous travaillez.

Après le nettoyage: vérifier qu’on n’a pas juste “effacé le symptôme”

Un incident de sécurité ressemble parfois à une maladie. Vous pouvez supprimer les cellules infectées visibles, mais si le mécanisme de propagation existe encore, la rechute arrive.

Pour savoir si uploads était réellement la source, surveillez:

Les nouveaux fichiers créés après votre nettoyage. Si, dès que vous remettez le site en ligne, vous observez à nouveau des fichiers récents dans uploads, c’est un signe que la porte reste ouverte. Les mêmes erreurs dans les journaux serveur. Par exemple, des tentatives récurrentes sur des chemins identiques peuvent indiquer que quelqu’un cherche un fichier précis. Les comportements côté application, pages transformées, scripts injectés, redirections. Le nettoyage d’un dossier peut avoir l’air suffisant, mais un autre vecteur peut être présent. Les changements sur les fichiers PHP “au-delà” de uploads. Même si votre focus est là, un attaquant obtient souvent un accès qui touche aussi des fichiers de configuration, des thèmes ou des plugins.

Sur des sites plus exposés, vous pouvez aussi constater des tentatives venant d’IP connues, et parfois des patterns d’attaques qui consistent à vérifier si un webshell est encore disponible.

Distinguer “media corrompu” et “compromission de compte”

Parfois, les admins pensent: “on a un fichier upload compromis, donc c’est uniquement un problème de fichiers”. La réalité est plus nuancée. Les fichiers compromis sont souvent une conséquence d’un accès obtenu.

Si un compte admin a été pris, l’attaquant peut uploader des scripts, créer des comptes, modifier des options, ou installer un plugin. Dans ce cas, même si vous nettoyez uploads, l’attaquant peut ré-uploader à la prochaine connexion.

À l’inverse, il arrive qu’un incident soit plus “technique” et moins “humain”: une faille de plugin ou une erreur de configuration autorise un upload non autorisé. Là, la question devient: comment fermer le vecteur d’entrée. Sinon, votre suppression sera une course sans fin.

Ce diagnostic fait gagner du temps. Il vous évite de passer deux jours à nettoyer uploads pendant que le vrai problème est un plugin vulnérable, ou un compte laissé en mot de passe faible, ou une règle serveur trop permissive.

Durcir l’environnement pour que uploads ne redevienne pas une porte

Nettoyer, c’est indispensable. Mais si vous ne durcissez pas, vous demandez à la compromission de revenir.

Je ne vais pas vous promettre une règle unique, parce que cela dépend de votre hébergement et de votre stack. En revanche, vous pouvez viser des garde-fous de bon sens:

S’assurer que PHP n’est pas interprété dans wp-content/uploads. Si votre serveur interprète PHP dans ce répertoire, c’est un problème majeur. La façon de corriger dépend du serveur web (Apache, Nginx) et du niveau d’accès que vous avez. Mettre en place des restrictions d’upload, selon vos besoins. Si vous n’acceptez pas de .php, .phtml, .phar, même si WordPress ne devrait pas les exécuter, il vaut mieux éviter de les stocker. Surveiller les plugins installés et les mises à jour. Les vecteurs d’attaque viennent souvent de là, même si l’objet final finit dans uploads. Passer en revue les droits et la politique d’accès aux fichiers. Les configurations “trop ouvertes” augmentent les risques. Utiliser une surveillance de fichiers et des logs. Une alerte sur modification de certains chemins donne un avantage énorme: vous agissez avant que l’attaquant ait le temps de réinstaller.

Sur les sites qui ont déjà connu une compromission, je conseille aussi d’examiner les règles de cache et de CDN. Parfois, le contenu “malveillant” semble revenir, mais il revient parce qu’il a été mis en cache. On supprime pourtant le fichier, mais un cache distribué le sert encore. Ça se traite, mais si vous ne le savez pas, vous allez nettoyer deux fois.

Cas fréquents: ce qui se passe quand vous trouvez un fichier suspect

Un fichier suspect dans uploads, qu’est-ce que ça signifie? Pas forcément un script exploitable, mais souvent un indice sérieux.

Voici les cas les plus courants que j’ai rencontrés:

Vous trouvez un fichier dont le contenu contient des marqueurs de code exécutable. Là, la décision est généralement nette: suppression et vérification des déclencheurs ailleurs. Vous trouvez des fichiers avec des extensions inattendues mais du contenu inoffensif. Là, vous devez vérifier si le fichier est juste “mal classé” ou si un traitement ultérieur le rend dangereux. Sans déclencheur, le risque peut être faible, mais sur un site déjà touché, je privilégie l’élimination prudente des éléments anomalies, au lieu de laisser un doute. Vous trouvez une série de fichiers identiques avec des tailles proches, déposés sur une fenêtre courte. Ce pattern ressemble à un dépôt automatisé. Dans ce cas, l’attaque a probablement une partie répétable, et vous devez aussi chercher la faille d’entrée. Vous supprimez, puis le fichier réapparaît. Ça confirme que l’accès initial n’est pas corrigé. Là, la priorité change: fermeture du vecteur, rotation d’identifiants, audit des plugins, durcissement serveur.

Ce sont des décisions “terrain”. Elles ne se prennent pas en lisant une règle théorique, elles se prennent en observant le comportement.

En pratique, quels fichiers dans uploads faut-il traiter en premier

Si votre uploads contient des milliers de médias, vous allez avoir besoin d’un ordre de priorité.

Sans vous noyer dans une liste interminable, je recommande de commencer par:

Les fichiers les plus récents. Les fichiers à extension inhabituelle au regard de votre historique. Les fichiers dont le contenu n’est pas cohérent avec la fonction annoncée (par exemple un fichier censé être une image, mais qui contient des chaînes de code). Les fichiers placés à des emplacements non attendus (racine de uploads ou arborescences inattendues). Les fichiers provoquant des erreurs dans les logs quand ils sont demandés.

Le but est de maximiser le rapport effort-risque. Plus vous avancez avec des preuves, plus votre nettoyage devient “chirurgical”.

Traiter les traces ailleurs que dans uploads

Même si votre objectif est “nettoyer les fichiers uploads compromis”, je ne conseille pas de s’arrêter aux médias. Les attaques réussies laissent souvent des traces dans des endroits qui complètent l’action.

Vous devez regarder, au minimum, les zones suivantes: fichiers de configuration, thèmes et plugins récents, fichiers qui changent souvent, et base de données pour certains marqueurs d’injection (si vous avez des indicateurs de contenu modifié).

Pourquoi je le dis? Parce qu’un fichier dans uploads peut n’être qu’une pièce d’un puzzle. Si vous ne vérifiez pas le puzzle entier, vous pouvez supprimer la pièce visible, mais laisser le mécanisme de déclenchement, qui finira par réinjecter ailleurs ou redéposer la pièce.

Comment savoir que vous êtes “revenu à l’état sain”

Une bonne désinfection ne se mesure pas uniquement au retour du site en ligne. Elle se mesure à la capacité à rester stable.

Je vise trois signaux:

D’abord, l’absence de nouveaux fichiers suspects dans uploads après une période d’observation. Le timing dépend de votre trafic, mais même quelques heures peuvent révéler une réinfection rapide.

Ensuite, la disparition des requêtes anormales les plus visibles dans les logs, ou au moins une baisse nette et durable.

Enfin, la cohérence fonctionnelle: pages normales, formulaires qui fonctionnent, pas de redirections, pas de contenu injecté. Et si vous avez un outil de surveillance (uptime, sécurité, WAF, logs centralisés), vous devez voir une normalisation, pas un “calme provisoire”.

Conclusion sans slogan: une désinfection WordPress utile est une désinfection prouvée

Si vous devez retenir une idée, c’est celle-ci: nettoyer wp-content/uploads est souvent indispensable, mais ce n’est efficace que si vous associez la suppression https://gardewp.fr/nettoyage-malware-wordpress/ à un diagnostic et à une fermeture de la porte d’entrée.

La désinfection WordPress qui tient sur la durée, c’est celle où vous traitez les fichiers compromis, mais aussi où vous sécurisez l’accès, contrôlez les vecteurs possibles (plugins, thèmes, comptes), et vérifiez que de nouvelles anomalies n’apparaissent pas. uploads est un endroit discret, mais pas un endroit “mineur”. Quand il devient la base d’une compromission, il faut agir vite, mais avec une logique claire.

Si vous êtes en train de faire ce travail sur un site en production, commencez petit mais propre: tri par dates et extensions, inspection du contenu des fichiers vraiment suspects, isolement puis suppression ciblée. Ensuite, observez. C’est cette phase qui transforme un nettoyage “au ressenti” en une désinfection réellement maîtrisée.