Désinfection WordPress : sécuriser les permissions de dossier

Quand on parle de désinfection WordPress, on pense souvent au code malveillant dans des fichiers évidents: un plugin qui n’est plus le bon, un thème modifié, un script caché dans un dossier chelou. Ce qui est moins visible, et pourtant aussi déterminant, c’est la façon dont WordPress et votre serveur ont le droit d’écrire dans vos dossiers. Des permissions trop larges peuvent transformer une “désinfection” en opération temporaire. On nettoie aujourd’hui, on se fait recontaminer demain, parfois sans même s’en rendre compte.

Je l’ai vu sur des sites hétérogènes: un WordPress très simple hébergé sur une plateforme mutualisée, et un autre plus complexe sur un environnement avec déploiement automatisé. Dans les deux cas, le point commun était la même fragilité: des dossiers où l’écriture restait autorisée bien au-delà du nécessaire. Une porte ne sert pas seulement à entrer, elle sert aussi à revenir.

Pourquoi les permissions de dossier comptent autant après une attaque

Sur WordPress, l’attaque a souvent deux objectifs: exécuter du code et garder un accès persistant. Le code se glisse dans un fichier, mais la persistance se joue dans les mécanismes d’écriture. Si le serveur a des droits d’écriture trop étendus, un intrus n’a pas besoin de “repasser par la case” injection initiale. Il peut déposer à nouveau un webshell, un fichier .php déguisé, ou modifier un thème et s’appuyer sur des chemins qui seront ensuite traités par PHP.

Même si vous avez supprimé les fichiers suspects, vous pouvez laisser une configuration qui rend l’environnement trop permissif. Un plugin peut mettre à jour automatiquement des actifs, un thème peut écrire des caches, ou simplement WordPress peut régénérer des miniatures. Si, dans ce contexte, un autre morceau de code malveillant trouve un moyen d’exploiter ces écritures, il peut reconstituer sa présence.

Il faut aussi regarder le chemin inverse: un site trop “serré” peut bloquer des opérations légitimes, puis vous pousser à corriger à la hâte en redonnant des permissions plus larges. C’est là que beaucoup de nettoyages échouent, parce que la désinfection devient une lutte permanente entre sécurité et fonctionnement.

Comprendre le couple “propriétaire” et “droits” (avant de modifier)

Les permissions Unix sur les dossiers reposent sur trois notions qui se mélangent facilement pendant un incident:

le propriétaire (l’utilisateur Unix qui possède le dossier) le groupe (le groupe Unix autorisé) les droits (lecture, écriture, exécution)

Sur un dossier, l’exécution est particulièrement importante. Sans le droit “exécuter” sur un répertoire, on ne peut pas parcourir ce répertoire, même si on a la lecture. Pour WordPress, cela a des impacts concrets: PHP doit pouvoir parcourir les chemins que WordPress consulte, et il doit pouvoir écrire dans certains emplacements spécifiques.

L’autre piège est de confondre “dossier” et “fichiers”. Beaucoup de gens changent les permissions sur toute l’arborescence sans distinguer ce qui doit être modifiable en permanence (typiquement quelques dossiers de cache et uploads) et ce qui ne doit pas l’être (le cœur WordPress, les thèmes propres, les fichiers de configuration).

Enfin, il faut faire attention à un détail pratique: sur des hébergements mutualisés, vous n’avez parfois pas la main sur les propriétaires Unix. Vous pouvez alors modifier des permissions via cPanel, Plesk ou un client FTP, mais vous ne contrôlez pas toujours parfaitement le couple propriétaire/groupe. Dans ce cas, la stratégie doit être plus prudente, et on privilégie les endroits où vous avez réellement la maîtrise.

Les emplacements WordPress qui ont besoin d’écrire (et ceux qui ne devraient pas)

WordPress n’a pas besoin d’écrire partout. Il fonctionne comme un moteur qui lit surtout, et qui écrit seulement dans des zones ciblées. Concrètement, les emplacements les plus sensibles sont:

wp-content/uploads pour les médias certains sous-dossiers de wp-content selon vos plugins (caches, logs, temp) éventuellement wp-content/upgrade lors des mises à jour les dossiers de cache si vous utilisez des extensions de performance

Le cœur WordPress, lui, devrait être en lecture seule dans une configuration “propre”. Les fichiers de configuration comme wp-config.php doivent être très stricts. Le but est simple: après désinfection, vous voulez réduire la surface où un intrus pourrait déposer du code.

Il y a toutefois une nuance importante. Certains plugins d’optimisation ou de sécurité ont des besoins spécifiques: écriture de fichiers dans un dossier de cache, mise à jour de .htaccess via une stratégie de règles, ou utilisation de fichiers temporaires. Bloquer trop fort peut casser le site, puis vous aurez tendance à ouvrir trop large. La bonne approche consiste à identifier les besoins réels de votre pile (plugins actifs, mode de déploiement, présence ou non d’automatisation).

Symptômes d’un problème de permissions après une désinfection

Quand les permissions sont en cause, l’inquiétude se manifeste rarement sous la forme d’un écran “hacké” immédiat. Souvent, c’est plus discret. Quelques signaux que j’ai appris à surveiller:

les plugins se réinstallent ou se modifient “trop facilement”, parfois sans déclencheur utilisateur des fichiers récemment modifiés réapparaissent dans des dossiers inattendus des erreurs intermittentes de création de fichiers ou d’écriture apparaissent dans les logs des pages qui fonctionnent, puis cassent, puis refonctionnent après un changement de droits des tâches planifiées qui échouent puis “se réparent” automatiquement en ouvrant des permissions plus larges

Ces symptômes ne prouvent pas à eux seuls un problème de permissions. Mais si, après désinfection WordPress, vous observez des modifications qui ressemblent à une répétition, la piste “droit d’écriture trop permissif” devient très plausible.

Valeurs de référence: ce qui est généralement acceptable (sans faire de promesse universelle)

Les valeurs numériques exactes dépendent de votre environnement (mutualisé, VPS, propriétaire/groupe, présence de ACL). On trouve souvent des recommandations du type “dossiers à 755, fichiers à 644”. Pour la sécurité, c’est un bon repère. Mais je préfère parler en logique plutôt qu’en formule magique.

L’idée directrice est la suivante:

les dossiers qui doivent être parcourus, mais pas modifiés par défaut, sont en lecture + parcours, sans écriture les fichiers qui doivent être consultés par PHP, sans être modifiés par le web, sont en lecture seule pour le web seuls quelques dossiers doivent rester en écriture, et encore, idéalement avec le minimum requis

Pour les uploads, un dossier doit pouvoir accepter de nouveaux fichiers. C’est normal. En revanche, il faut limiter la capacité d’écrire ailleurs, et surveiller les sous-dossiers créés par des plugins.

Sur beaucoup d’hébergements, le web server tourne avec un utilisateur système (par exemple www-data ou autre). Si l’utilisateur PHP peut écrire dans des emplacements où il ne devrait pas, votre durcissement devient théorique.

La méthode “propre”: corriger permissions, propriétaire, puis repasser par une désinfection ciblée

Une bonne séquence évite de faire plusieurs allers-retours qui compliquent l’analyse forensique. Sans faire un processus “labo”, vous pouvez garder une logique simple:

1) vous nettoyez ce qui est clairement malveillant

2) vous verrouillez l’environnement pour que le même vecteur ait beaucoup plus de mal à se reproduire 3) vous surveillez et vous ajustez uniquement ce qui casse le site, en revenant au minimum nécessaire

Quand on change les permissions avant d’avoir fini le tri des fichiers, on peut masquer des preuves: un intrus a pu déposer un fichier, mais vous perdez l’accès pendant votre investigation ou votre outil de scan n’arrive plus à vérifier certains chemins.

À l’inverse, si vous ne corrigez pas après, un intrus peut “réengraisser” la compromission dès que WordPress ou PHP a un droit d’écriture. Le bon compromis est de traiter les permissions juste après le nettoyage principal.

Vérifier l’état réel avant de toucher aux droits

Avant de modifier, je conseille de partir d’un état observé, pas d’une intuition. Selon votre niveau d’accès, vous pouvez combiner:

la date de modification des fichiers dans wp-content (repérer des choses “fraîches”) la liste des fichiers récemment créés (souvent dans uploads ou dans des dossiers inattendus) les erreurs dans les logs (PHP et serveur web), surtout les messages d’accès refusé la configuration de vos méthodes d’upload et de déploiement (FTP, accès direct au FS, CI/CD)

Si vous avez un accès SSH, c’est plus facile de gérer la logique propriétaire/groupe. Si vous êtes en FTP, vous devez accepter que vous modifiez des permissions sans connaître parfaitement l’utilisateur système qui exécute PHP.

Et puis, il y a un point qui m’a déjà fait perdre une heure: sur certains hébergements, les permissions ne sont pas les seules. Il peut exister des ACL, héritages, ou règles spécifiques du système. Si vous avez un comportement étrange (exécution refusée, écriture autorisée malgré ce que vous voyez), ne forcez pas en changeant tout. Il faut comprendre le modèle local.

Ajuster avec prudence: stratégie pour uploads et zones temporaires

La zone wp-content/uploads est le cœur de votre capacité à gérer des médias. Mais elle peut devenir aussi un vecteur d’exécution si des fichiers .php y sont déposés. En durcissant, vous n’empêchez pas l’upload légitime, mais vous réduisez le risque d’interprétation.

Sans entrer dans des réglages qui dépendent de votre stack (Apache, Nginx, présence de règles spécifiques), la logique générale est:

uploads doit être modifiable pour les fichiers, mais vous devez empêcher l’exécution de scripts dans les endroits qui ne devraient contenir que des médias les fichiers de configuration et le cœur de WordPress doivent rester en lecture seule les sous-dossiers créés par plugins doivent être identifiés, puis éventuellement restreints

Dans la pratique, sur un site compromis, on voit souvent des scripts déposés soit dans uploads, soit juste à côté, dans des répertoires temporaires. C’est pour cela que la désinfection WordPress doit s’accompagner d’une vérification fine des dossiers, pas juste de la suppression de “quelques fichiers”.

Un exemple concret de durcissement qui a fonctionné (et pourquoi)

Sur un WordPress que j’ai aidé à “remettre d’équerre”, le site affichait des comportements intermittents: après nettoyage, certaines pages revenaient avec une redirection, puis re-disparaissaient. Le scan trouvait des fichiers suspects de temps en temps, jamais de façon stable. En investiguant les droits, on a découvert un dossier dans wp-content avec une écriture trop large, probablement laissé à tort pendant une précédente intervention.

Le changement n’était pas “ouvrir tout en 777”. On a fait plus fin: on a ajusté les permissions du dossier concerné pour qu’il reste parcourable et lisible, mais pas modifiable par le contexte web, puis on a limité à nouveau l’endroit où WordPress et le plugin de cache pouvaient écrire. Résultat: le site a cessé de “recréer” la partie malveillante après nettoyage.

La leçon est simple, et elle se répète souvent: quand une compromission revient, ne cherchez pas seulement le fichier, cherchez aussi pourquoi le serveur a pu le régénérer.

Check rapide après désinfection: vérifier que les droits ne contredisent pas votre fonctionnement

Voici une mini check pratique, à faire après la désinfection WordPress, avant de remettre le site en production totale pour de longs délais.

Confirmer que wp-content/uploads reste modifiable, mais que les fichiers exécutables ne peuvent pas être interprétés dans ce contexte Vérifier que le cœur de WordPress et les thèmes actifs ne sont pas modifiables par le contexte d’exécution web Contrôler les dossiers temporaires de plugins (cache, logs, temp) pour éviter des écritures persistantes trop ouvertes Rechercher des fichiers récemment modifiés dans wp-content et comparer avec votre calendrier (mises à jour légitimes ou non) Surveiller les erreurs “permission denied” dans les logs quelques heures après le durcissement

Cette approche évite l’erreur classique, qui consiste à corriger les droits au hasard, puis à “corriger de nouveau” quand le site casse.

Comment changer permissions et propriétaires, sans vous tirer une balle dans le pied

https://gardewp.fr/nettoyage-malware-wordpress/

Je vais rester volontairement sur la logique, parce que les commandes exactes varient selon votre accès. Sur un serveur avec SSH, on utilise souvent find et chown/chmod pour appliquer des politiques sur des arborescences. Sur un panneau de contrôle, on change via l’interface. Dans les deux cas, la prudence est identique: procédez dossier par dossier, pas en “tout sur le site”, et gardez un moyen de revenir en arrière.

Le risque n’est pas seulement la sécurité, il est aussi opérationnel:

vous pouvez bloquer la mise à jour de WordPress vous pouvez casser l’écriture de miniatures si un plugin dépend de dossiers spécifiques vous pouvez provoquer une boucle de régénération de cache, avec des fichiers créés en permanence

Si vous devez agir globalement, faites-le par sous-ensembles, en commençant par les zones les plus critiques. Et avant d’enchaîner, gardez une sauvegarde des permissions initiales si votre environnement le permet, ou au minimum un relevé des droits sur les dossiers importants.

Le cas délicat: l’héritage, les permissions incohérentes et les plugins qui “écrivent partout”

Certains plugins ont un style d’administration très libre. Ils créent des fichiers dans des zones qui ne devraient pas être en écriture permanente, ou ils laissent des permissions “pour être tranquilles”. Si votre site a été construit ou modifié plusieurs fois, vous pouvez aussi hériter d’une arborescence où les permissions sont incohérentes.

Un dossier peut être en 755, mais un sous-dossier en 777. Ou un fichier peut être en 666, juste parce qu’il a été ajouté en urgence. Dans ces situations, l’objectif n’est pas de “mettre une valeur uniforme”, c’est de réconcilier chaque dossier avec son rôle.

J’utilise souvent un raisonnement en deux colonnes, mentale et très pratique:

dossiers qui reçoivent des uploads ou des écritures fonctionnelles dossiers qui doivent rester majoritairement en lecture seule

Si vous faites cela correctement, vous pouvez réduire la surface d’attaque sans casser l’écosystème.

Deux modèles courants d’environnement, deux approches

Pour rendre les choses plus concrètes, voici deux profils fréquents et la façon dont j’aborde la sécurisation des permissions dans chacun.

| Profil | Ce que je constate souvent | Approche permissions | |---|---|---| | hébergement mutualisé, accès limité | changements de permissions possibles via panneau, mais propriétaire système peu visible | durcissement ciblé sur wp-content/uploads, wp-content sensible, et verrouillage du cœur en lecture, puis surveillance des erreurs | | VPS/serveur avec SSH | contrôle plus fin sur propriétaire/groupe, possibilité de scripts et politique d’arborescence | correction avec logique propriétaire/groupe, rétablissement de permissions par sous-dossiers, et vérification sur le web user qui exécute PHP |

Le point commun reste le même: ne pas confondre “ce qui marche” avec “ce qui est durable”. Une permissivité qui fonctionne aujourd’hui peut redevenir une faille demain.

Surveillance après changement: le vrai durcissement, c’est la répétition contrôlée

Après avoir resserré les permissions, je recommande de surveiller. Pas besoin de mettre en place une usine à gaz, mais assez pour détecter un retour rapide.

Deux indicateurs utiles, parce qu’ils sont actionnables:

les logs d’erreurs liés à des permissions, qui montrent qu’un comportement légitime a besoin d’être adapté les fichiers récemment modifiés dans wp-content, qui montrent un dépôt inattendu

Une désinfection WordPress n’est pas un événement ponctuel. C’est un cycle: nettoyer, durcir, vérifier, puis maintenir. Les permissions sont votre barrière mécanique, les logs sont votre alarme.

Distinguer l’erreur “permissions” de la réinfection réelle

Quand quelque chose casse après durcissement, vous pouvez confondre deux scénarios:

le site casse parce que vous avez bloqué une écriture nécessaire le site casse parce qu’un morceau malveillant est revenu, et qu’il échoue parce que vous l’avez davantage verrouillé

Je l’ai déjà vécu: après correction, un script malveillant ne fonctionnait plus, et le site semblait “guéri”. Puis deux semaines plus tard, un autre fichier a réapparu dans un dossier qui avait pourtant été oublié. La seule manière d’éviter les faux sentiments de sécurité, c’est de combiner droits et contrôle des fichiers, avec une fenêtre de vérification.

Micro-durcissements utiles autour des dossiers sensibles

En plus des permissions, il y a des leviers complémentaires que je traite avec les droits plutôt qu’en remplacement:

empêcher l’interprétation de scripts dans les répertoires d’uploads s’assurer que les fichiers de configuration ne sont pas accessibles de façon excessive réduire les droits d’écriture des scripts d’administration non essentiels

Je fais attention à un point: certaines solutions “magiques” proposées en ligne recommandent des paramètres qui peuvent être incompatibles avec certains plugins. Dans un incident, la compatibilité compte. Si vous changez trop de choses d’un coup, vous ne saurez pas ce qui a réglé le problème et ce qui l’a provoqué.

Les risques d’une correction “trop agressive”

Il y a une limite à la paranoïa. Si vous verrouillez totalement wp-content, vous pouvez empêcher des opérations normales, par exemple:

écriture de miniatures gestion de documents multimédias création de fichiers de cache selon le plugin

Vous pourriez finir par ouvrir de nouveau des droits, mais cette fois dans l’urgence, sans revenir à une logique propre. C’est comme colmater une fuite en fermant la porte d’un ascenseur sans vérifier pourquoi il s’est mis à fuir. Cela marche peut-être pour la journée, mais ça n’empêche pas le problème structurel.

La bonne approche est de corriger au niveau le plus bas qui résout le risque, puis d’ajuster uniquement ce qui est nécessaire pour le fonctionnement.

Après coup: documenter pour éviter de refaire le même travail

Quand on gère une désinfection WordPress, on accumule des détails utiles: quels dossiers ont été modifiés, quels plugins étaient actifs, quelles erreurs ont été observées. Documenter ne sert pas à remplir un dossier, ça sert à accélérer vos prochaines interventions.

Je recommande au minimum de noter:

les dossiers qui ont des permissions d’écriture (et pourquoi) la règle de base appliquée au reste les plugins qui touchent aux dossiers de cache ou de logs

Vous réduisez ainsi les chances d’un “nettoyage répétitif” où l’on oublie le même angle mort à chaque fois.

Une dernière chose: ne repartez pas sans changer aussi vos pratiques d’accès

Les permissions de dossier sont une barrière. Mais une barrière n’a de valeur que si l’accès initial est sécurisé. Si la compromission revient, il faut aussi regarder le vecteur d’entrée: mots de passe, comptes admin, plugins obsolètes, rôles trop larges, accès FTP ou SSH partagés, configuration de l’authentification.

Le durcissement des permissions ne remplace pas la correction des causes. Il fait en sorte que, si un incident survient malgré tout, votre site ne se “répare” pas tout seul dans le mauvais sens.

Si vous ne deviez retenir qu’une phrase pratique, ce serait celle-ci: après une désinfection WordPress, verrouillez les endroits qui n’ont pas besoin d’écrire, et traitez les dossiers qui écrivent comme des portes, pas comme des couloirs sans contrôle.