Quand on parle de “site WordPress infecté”, on pense souvent à une porte d’entrée évidente, un plugin compromis, un mot de passe réutilisé. Dans la vraie vie, la contamination laisse rarement un seul indice. Elle s’installe, persiste, et surtout elle exploite des endroits précis où WordPress et le système peuvent laisser passer autre chose que du contenu.
Parmi ces endroits, il y a deux thèmes qui reviennent tout le temps lors des interventions: les permissions du dossier d’upload, et la manière dont le serveur traite les fichiers “placés là”. Un attaquant peut certes déposer une charge utile via un formulaire, une API, un script ou une faille applicative. Mais il gagne du temps (et du contrôle) dès qu’il peut uploader un fichier puis le faire exécuter dans un contexte web.
Dans ce billet, je vais détailler une approche pratique pour reprendre la main, en tenant compte des compromis, des erreurs fréquentes, et de ce que vous pouvez raisonnablement exiger de votre hébergeur.
Le piège classique: “upload” et exécution
WordPress s’appuie sur un dossier comme wp-content/uploads/ pour stocker des images, des PDF, des vidéos, des fichiers et des médias. L’administration le fait via l’interface, et le serveur sert ensuite ces fichiers via HTTP.
Le problème survient quand le dossier d’upload a des permissions trop larges, ou quand la configuration du serveur autorise l’exécution de fichiers qui ne devraient pas l’être. Selon la stack, ça peut vouloir dire PHP exécuté depuis un sous-répertoire censé accueillir des médias, ou scripts interprétés d’une manière inattendue.
Un “site WordPress infecté” se repère souvent au comportement: des pages qui changent sans raison, des redirections, des fichiers qui apparaissent sans que personne n’ait téléversé. Mais la cause racine est parfois plus technique: le serveur ne devrait pas exécuter ce qui arrive dans uploads. Si c’est possible, l’attaquant transforme chaque upload réussi en point de persistance.
Je me souviens d’un cas où le site ne montrait pas de spam immédiatement. On voyait surtout un volume de requêtes anormal, puis des fichiers inconnus dans uploads. Les premiers correctifs auraient pu se limiter au nettoyage. Pourtant, dès qu’on rétablissait le contenu, l’attaque revenait. La raison était simple: les permissions et la configuration donnaient trop de latitude, donc l’attaquant recyclait la même mécanique en quelques heures.
Comprendre ce qui peut “exploser” dans les permissions
Les permissions Unix, ou leur équivalent sur votre hébergeur, ne sont pas juste une formalité. Elles déterminent qui peut écrire, qui peut lire, et ce que le serveur a le droit d’interpréter.
Sur beaucoup d’hébergements Linux, le modèle classique est le suivant:
- le serveur web tourne avec un utilisateur (souvent www-data, apache, ou un utilisateur dédié), WordPress tourne en tant que le même utilisateur, ou via PHP-FPM avec un pool, les fichiers téléchargés sont écrits par PHP dans uploads.
Si uploads est trop “écrivable” par tout le monde, ou si le serveur a des règles de traitement trop permissives, l’attaquant n’a pas besoin d’être très ingénieux. Il peut déposer une charge utile et la rendre exécutable.
Dans l’autre sens, un piège inverse existe aussi. Si vous “durcissez” trop vite et cassez l’accès en écriture, WordPress peut ne plus pouvoir uploader. Cela ressemble à un problème de sécurité, mais en réalité vous venez de créer une indisponibilité fonctionnelle. Dans un incident, c’est souvent ce qui complique la reprise: vous tenez un bon diagnostic, puis vous faites un durcissement trop brutal, et vous perdez la capacité de tester proprement.
Le bon équilibre dépend du serveur. Les consignes ne sont pas universelles au sens strict, et je préfère vous donner une méthode de décision plutôt qu’un chiffre unique.
Ce qu’il faut vérifier avant de “changer les droits”
Avant de toucher aux permissions, j’ai une règle d’or: observez le système avant de le modifier. Sur un site en cours d’infection, toute intervention modifie légèrement l’état, et vous pouvez masquer un indice.
Voici ce que je vérifie en premier, par ordre de priorité, quand c’est possible:
- présence de fichiers inattendus dans wp-content/uploads/ (extensions inhabituelles, noms aléatoires, tailles incohérentes), traces de modification dans WordPress et le système (horodatage des fichiers, historique des uploads, logs PHP et web), configuration serveur qui pourrait permettre l’exécution de fichiers dans uploads (notamment via AddType, ou une interprétation PHP trop large), cohérence des droits entre dossiers WordPress et médias.
Selon l’accès dont vous disposez, vous pouvez avoir une console SSH, un accès via cPanel/Plesk, ou seulement un panneau d’hébergement. Le niveau de contrôle change, et donc la stratégie aussi. On peut durcir sans SSH, mais on doit s’adapter.
Les indicateurs que l’infection exploite les uploads
Un attaquant qui s’intéresse à uploads ne le fait pas “par hasard”. Les tentatives de compromission qui finissent en dépôt de fichier se verront tôt ou tard dans le contenu web accessible.
Quelques signes typiques, que j’ai vus revenir, parfois dissimulés dans des sous-dossiers:
- des fichiers .php ou .phtml dans wp-content/uploads/ (même si l’upload d’extensions PHP est censé être bloqué), des fichiers avec des extensions masquées ou “double extension”, par exemple .jpg.php, .png.php, ou des archives qui contiennent des scripts, des sous-dossiers créés et remplis rapidement, avec des dates de création concentrées sur une plage courte, des requêtes web anormales qui cherchent exactement ces chemins, souvent avec des paramètres répétitifs.
Je traite aussi le “silence” comme un indice. Quand l’attaque ne montre pas de page défigurée, mais que des fichiers apparaissent dans uploads, c’est parfois un mécanisme de chargement différé: l’exécution se fait via un script ailleurs, qui ensuite inclut un fichier dans uploads. Dans ce cas, corriger uniquement les templates WordPress ne suffit pas.
Voici une mini check-list utile, sans prétendre remplacer l’enquête:
- apparition de nouveaux fichiers dans wp-content/uploads/ hors contexte, présence d’extensions et types inattendus dans ces dossiers, logs PHP indiquant des accès ou exécutions depuis uploads, tentatives répétées de requêtes vers des chemins de fichiers déposés, comportement du site qui “revient” après nettoyage, malgré un assainissement partiel.
Le point clé: empêcher l’exécution dans le dossier d’uploads
L’objectif n’est pas seulement de bloquer certains types. L’objectif réel est de faire en sorte que le serveur ne puisse pas interpréter du code déposé dans uploads. Autrement dit, même si un fichier dangereux est uploadé, il doit rester un fichier inerte.
Deux approches cohabitent souvent:
Empêcher l’upload de certains types (côté WordPress et côté serveur), Empêcher l’exécution côté serveur (côté configuration web), ce qui couvre le scénario où l’upload a déjà “passé”.Dans un incident, je préfère la seconde car elle amortit des erreurs. Si l’attaquant a déjà réussi à déposer une charge utile, un blocage purement applicatif peut être trop tardif.
Le “comment” dépend de votre serveur. Sur Apache, l’inertie de fichiers peut être obtenue via des règles comme php_admin_flag et des directives qui neutralisent l’interprétation. Sur Nginx, c’est encore plus direct: vous pouvez empêcher l’exécution PHP dans un chemin donné en configurant location et fastcgi. Sur les plateformes gérées, l’hébergeur peut le faire via des options globales.
Si vous n’avez pas accès à la configuration, vous pouvez parfois obtenir un équivalent via un fichier .htaccess dans uploads, ou via des options sur le panneau. Mais attention, un .htaccess ne garantit pas toujours le même niveau d’impact selon les réglages du serveur et la présence de directives de sécurité prioritaires.
Durcir les permissions sans casser WordPress
Quand on durcit, le risque principal est la régression: WordPress n’arrive plus à écrire dans uploads, et vous perdez l’usage légitime du site. Sur un site infecté, ça a aussi un impact opérationnel. Les tests d’assainissement deviennent plus difficiles.
Dans la pratique, je vise une stratégie progressive:
- limiter l’écriture au strict nécessaire, conserver la capacité de WordPress à uploader, empêcher l’exécution dans les dossiers de médias, vérifier que les permissions ne sont pas incohérentes d’un sous-dossier à l’autre.
Le sujet “permissions” a souvent un historique. Par exemple, quelqu’un a peut-être corrigé un problème précédent en mettant 777 par erreur, ou en “héritant” d’un paramètre via un plugin ou une procédure manuelle. Ce genre d’héritage se voit dans les permissions actuelles.
Sans entrer dans des valeurs universelles, une bonne logique est celle-ci: WordPress doit pouvoir écrire là où il écrit, mais le système doit refuser que des droits trop larges donnent une surface d’attaque. En clair, un dossier d’upload n’a pas besoin d’être accessible en écriture pour tout le monde. Il a besoin d’être écrivable par le bon utilisateur de service.
Si vous avez accès à SSH, vous pouvez aussi vérifier l’utilisateur effectif, l’ownership et l’existence de drapeaux de permissions inhabituels. Si vous êtes en environnement géré sans SSH, l’hébergeur peut souvent ajuster la politique par défaut.
Le scénario réaliste: l’attaque a déjà eu lieu
Quand l’incident est présent, vous devez agir sur deux axes en parallèle:
- nettoyer ce qui a été déposé, empêcher la persistance via le mécanisme d’upload et d’exécution.
Sinon, vous voyez le classique: un nettoyage suivi d’un retour. L’attaquant ne “réinvente” pas tout, il réutilise les mêmes failles de configuration. Ce retour peut être rapide.
Dans ce contexte, gérer les permissions d’upload n’est pas une mesure cosmétique. C’est une barrière “anti-reinfection”.
Mais il faut aussi éviter de croire que corriger seulement les uploads suffit. Les attaquants peuvent injecter du code via d’autres points, ou abuser d’identifiants, ou exploiter un plugin. Les permissions d’upload sont une pièce essentielle, mais pas l’unique pièce.
Procédure de reprise orientée “uploads” (et qui respecte le contexte)
Je vous propose une procédure pragmatique. Elle ne remplace pas une enquête complète, mais elle donne une trajectoire claire quand vous êtes face à un site WordPress infecté, avec des fichiers déposés côté médias.
Bloquez l’accès à l’upload pendant l’assainissement, au moins temporairement (via un mode maintenance ou une restriction applicative) pour éviter les dépôts supplémentaires pendant que vous analysez. Identifiez et supprimez les fichiers inconnus et les entrées suspectes associées, en vérifiant aussi les fichiers PHP qui pourraient exister dans ou autour de uploads. Durcissez la configuration serveur pour interdire l’exécution de PHP et autres langages dans le dossier wp-content/uploads/ et ses sous-dossiers. Ajustez les permissions pour garantir l’écriture uniquement par l’utilisateur de service approprié, et supprimez les droits trop ouverts qui ont pu être laissés après un précédent incident. Re-testez avec un upload légitime (un fichier inoffensif) et surveillez les logs pendant une période courte, pour confirmer que vous n’avez pas cassé WordPress et que l’activité malveillante ne “revient” pas.Cette approche a un avantage: elle traite simultanément la cause technique et la persistance. Et elle limite les erreurs de timing, car vous évitez de nettoyer un espace pendant qu’il se remplit à nouveau.
Le détail qui change tout: que faire si vous ne pouvez pas modifier la configuration serveur
Sur certaines offres, vous ne contrôlez pas php.ini, ni Nginx ou Apache. Vous avez parfois uniquement la couche WordPress et quelques fichiers .htaccess.
Dans ce cas, vous pouvez toujours améliorer la situation:
- filtrer les types autorisés côté WordPress, vérifier si WordPress bloque réellement les extensions risquées (et si un bypass est possible via les MIME types ou via double extensions), empêcher l’exécution via des règles .htaccess si elles sont prises en compte, et surtout, demander à l’hébergeur le durcissement serveur correspondant.
Le point à ne pas perdre de vue: un durcissement “applicatif” ne suffit pas si le serveur exécute quand même. Donc si vous êtes bloqué sur la configuration, le meilleur “levier” reste l’hébergeur, car c’est lui qui pilote le moteur web.
J’ai déjà vu un .htaccess en place, très propre, mais ignoré parce que la politique serveur a des directives plus hautes. Résultat, l’équipe a eu l’impression de corriger alors que rien n’avait changé. Ce genre d’écart se repère en testant réellement, ou en consultant les règles effectives.
L’erreur de perception: confondre sécurité et “propreté” des fichiers
Nettoyer un dossier d’uploads peut sembler suffisant, mais ce n’est qu’un instantané. Un site infecté peut contenir:
- des fichiers malveillants déposés, des fichiers légitimes mais modifiés (ex: un fichier image remplacé par une version “binaire” contenant une charge, ce qui n’est pas toujours simple à repérer), des mécanismes ailleurs, qui ne vivent pas directement dans uploads, mais qui s’appuient sur ce répertoire.
C’est pour ça que je recommande de traiter uploads comme un couloir, pas comme la maison entière. Vous verrouillez le couloir d’entrée, et vous cherchez aussi d’où vient la clé.
Permission d’upload: les compromis qu’on doit assumer
Quand on durcit, il y a toujours une zone grise. Quelques exemples concrets.
- Si vous bloquez trop d’extensions, vos utilisateurs ne pourront plus importer des PDF, des SVG ou d’autres formats que le site utilise réellement. Si vous empêchez l’exécution trop largement, vous pouvez impacter des scripts nécessaires à certains plugins qui génèrent des ressources dynamiques dans uploads (cas rares, mais pas impossibles). Si vous modifiez les permissions trop agressivement, vous risquez des erreurs d’uploade, des médias qui ne s’affichent plus, et des formulaires de contact qui échouent si des plugins s’appuient sur des traitements de fichiers.
La bonne approche consiste à mesurer. Vous pouvez garder une permissivité sur les formats, tout en gardant l’inertie du contenu côté serveur. C’est le compromis qui protège le plus.
Et si vous avez un besoin légitime d’un format particulier, vous le traitez comme un cas à part: test de bout en bout, validation côté WordPress, et règle côté serveur pour éviter l’interprétation.
Surveillance après correction: confirmer que la persistance est cassée
Un assainissement réussi ne se lit pas uniquement à la fin. Il se confirme par l’observation.
Je m’attends, après correction des permissions et neutralisation de l’exécution, à voir:
- moins ou plus d’apparitions de fichiers suspects dans uploads, moins d’accès à des chemins inhabituels dans les logs web, une stabilité du comportement du site pendant une fenêtre de temps raisonnable.
La durée exacte varie. Sur une petite attaque automatisée, quelques heures peuvent suffire à voir si la persistance a été coupée. Sur des cas plus sophistiqués, il faut parfois surveiller plus longtemps. Je préfère parler en termes de fenêtre d’observation plutôt que d’une promesse absolue.
Questions pratiques à poser (avant d’aller trop loin)
Selon votre rôle, vous pouvez gérer plus ou moins. Dans une équipe, j’ai souvent vu les blocages venir d’un malentendu entre “sécurité” et “exploitation”.
Quelques questions simples changent la qualité du diagnostic:
- Quel type d’hébergement est en place, Apache ou Nginx, et avez-vous accès à la configuration web? PHP exécute-t-il des fichiers dans wp-content/uploads/ selon la règle actuelle? Les fichiers déposés l’ont-ils été via un accès WordPress compromis, un plugin, ou un compte admin? Les permissions actuelles indiquent-elles des droits trop ouverts hérités d’une ancienne action? Disposez-vous des logs au niveau PHP et du serveur web, et depuis quelle date?
Répondez à ces questions, même approximativement, et vous saurez si vous pouvez faire une correction “chez vous” ou si vous devez escalader à l’hébergeur.
Ce que je ferais en priorité si je devais agir vite
Si vous êtes en mode urgence, l’objectif est double: stopper l’infection et éviter de casser le site.
Je commence par neutraliser le chemin le plus dangereux, uploads, côté exécution, puis je sécurise les permissions pour éviter que “ça repasse” après nettoyage. Ensuite, je reviens sur WordPress et les plugins, car un site infecté n’est pas seulement une question de fichiers.
C’est souvent la combinaison qui fait la différence. Sans neutralisation, vous nettoyez un tiroir mais vous laissez la serrure ouverte. Sans permissions correctes, vous créez un retour de charge facile.
Deux pratiques qui réduisent drastiquement les récidives
Une fois le site stabilisé, il reste à empêcher que le scénario se reproduise.
D’abord, traiter les identifiants et le modèle d’accès, parce que les permissions ne protègent pas contre un compte qui téléverse. Ensuite, verrouiller les points qui permettent le dépôt et l’exécution, particulièrement dans les zones de stockage.
Je préfère aussi documenter ce que vous changez. Pas pour la paperasse, mais pour votre futur vous. La prochaine fois que vous voyez un dossier uploads qui grossit trop vite, vous saurez si une modification de permissions a été faite, et à quelle date.
Mini synthèse opérationnelle
Quand un site WordPress infecté implique des dépôts dans wp-content/uploads/, le couple permissions et exécution devient un levier central. Corriger l’aspect “propreté” des fichiers ne suffit pas si le serveur autorise l’interprétation de contenu dangereux depuis le répertoire des médias.
Une reprise solide se fait en deux temps: stopper la persistance potentielle via la neutralisation de l’exécution et la correction des permissions, puis reprendre l’assainissement et la vérification sur WordPress et les plugins. C’est moins spectaculaire qu’une suppression “à la main”, mais c’est plus fiable.
Si vous me donnez quelques détails sur votre hébergement (Apache ou Nginx, présence de SSH, possibilité de modifier php.ini ou .htaccess, et ce que vous observez dans wp-content/uploads/), je peux vous proposer une stratégie de durcissement adaptée à votre configuration, sans vous faire courir le risque de https://gardewp.fr/ casser l’uploade légitime.