Quand un WordPress est compromis, on pense d’abord au contenu: un fichier ajouté, un plugin “inconnus”, des redirections bizarres. Puis vient la réalité de l’administration système: la désinfection ne tient que si le système n’est plus dans un état “trop permissif”. Les permissions et les propriétaires des fichiers, c’est rarement le sujet le plus sexy, mais c’est souvent la différence entre une restauration qui tient et une restauration qui replante.
J’ai vu des sites “réparés” en passant l’antivirus du panneau d’hébergement, en changeant quelques mots de passe, puis en voyant réapparaître les symptômes en quelques heures. Dans la plupart des cas, le même mécanisme revenait: des fichiers avec des droits incohérents, des propriétaires qui ne correspondaient pas au compte d’exécution PHP, ou des répertoires accessibles en écriture au mauvais acteur. La désinfection avait effacé la porte, mais laissé la serrure ouverte.
Les permissions et propriétaires, c’est quoi exactement dans le contexte WordPress
Sur un serveur Linux, chaque fichier a trois propriétés qu’on confond souvent:
- le propriétaire (user), le groupe, et un jeu de droits (lecture, écriture, exécution) pour le propriétaire, le groupe et le reste du monde.
WordPress fonctionne dans une zone “hybride”: du contenu statique (images, thèmes, plugins) et du code exécutable côté serveur (PHP). PHP s’exécute sous un utilisateur système déterminé par votre configuration (souvent un compte dédié, parfois plusieurs selon le serveur). Si des fichiers PHP sont modifiables par un autre compte que celui attendu, ou si des répertoires critiques sont trop ouverts, alors un intrus peut remettre la charge malveillante après votre nettoyage, ou simplement conserver un accès.
Le point crucial, c’est que la compromission ne se résume pas à “il y a un script ajouté”. Elle inclut souvent le moyen de le reposer. Les permissions sont un excellent indicateur de ce “moyen”.
Pourquoi une mauvaise configuration facilite la rechute
Imaginons un scénario simple: un attaquant arrive à déposer un fichier PHP dans wp-content. Ensuite, il veut que ce fichier reste et qu’il puisse être réécrit.
Il a plusieurs options. Une option évidente est de voler les identifiants, puis de reposter depuis l’interface d’administration ou via un accès FTP. Mais même sans vol d’identifiants admin, il peut exploiter des permissions trop larges sur le système de fichiers.
Exemples typiques de portes laissées ouvertes:
- des répertoires de WordPress (par exemple wp-content/uploads) avec des droits d’écriture pour “tout le monde”, des propriétaires incohérents, où l’utilisateur web ne détient pas les fichiers qu’il devrait lire, et où un autre compte détient des droits d’écriture, des permissions de fichiers PHP trop permissives (par exemple modifiables par des comptes non attendus), des fichiers “exécutables” dans des zones qui ne devraient contenir que du texte.
Dans les cas réels, l’erreur est souvent une correction trop large faite pendant un dépannage. On voit parfois quelqu’un qui “corrige les droits” en mettant 777, le site redevient fonctionnel, puis on oublie le détail. Un mois plus tard, le même problème revient, parce que ce n’était pas une solution, c’était un compromis.
Identifier le compte d’exécution PHP et le propriétaire attendu
Avant de toucher aux permissions, il faut savoir qui doit “posséder” ou au minimum lire et écrire quoi.
Selon votre hébergement, le contexte varie. Sur beaucoup de serveurs, le processus web tourne sous un utilisateur dédié, par exemple www-data sur Debian/Ubuntu, apache sur certains environnements, ou un identifiant spécifique par domaine sur d’autres hébergeurs. Sur un hébergement mutualisé, vous n’avez parfois pas accès à une inspection complète, mais vous pouvez souvent déduire le compte via les logs d’erreur, le panneau, ou la configuration PHP.
Le point opérationnel est le suivant:
- Les fichiers PHP du thème, des plugins, et du core doivent être accessibles en lecture par le processus web. Les répertoires comme wp-content/uploads doivent permettre l’écriture pour que l’upload WordPress fonctionne. La plupart des autres répertoires ne doivent pas être réinscriptibles en permanence par “tous”.
Le piège, c’est de confondre “le site doit fonctionner” avec “le site peut être modifié par n’importe qui”. Tant que l’exécution reste possible et que les droits d’écriture sont limités à ce qui est nécessaire, vous vous donnez une chance de rendre la rechute plus coûteuse pour l’attaquant.
Ce qu’il faut vérifier pendant une désinfection
La désinfection, si elle se résume à supprimer des fichiers suspects, peut être incomplète. Vérifier les permissions et propriétaires transforme l’intervention en “désinfection durable”.
Le travail concret se fait en deux temps: repérer l’incohérence, puis comprendre si l’incohérence vient d’un usage normal ou d’une action malveillante ou accidentelle.
Les signaux d’alerte visibles dans les droits
Sans vous imposer une méthode universelle, il y a des indicateurs qui reviennent souvent:
- des fichiers PHP avec des droits d’écriture pour des groupes ou des “autres” inattendus, des propriétaires qui changent sur des fichiers du core, alors que seuls les uploads devraient changer, des répertoires qui ont des droits d’exécution alors qu’ils ne devraient pas, ou au contraire des fichiers qui perdent des droits de lecture, des timestamps anormaux sur des fichiers de plugins ou thèmes, parfois accompagnés de droits incohérents.
Je me souviens d’un chantier où des redirections malveillantes réapparaissaient après chaque nettoyage. Le scan trouvait bien le script, mais après suppression, il revenait. Le correctif n’était pas seulement côté WordPress: wp-content et plusieurs sous-dossiers avaient des propriétaires et un groupe différents, ce qui faisait que le mécanisme d’écriture d’un processus non prévu avait la possibilité de remettre le fichier. Une fois la propriété et les droits alignés, les redirections ont cessé de revenir, même après réindexation du site.
Mettre l’ordre dans les propriétaires, sans casser WordPress
Pour recalibrer, il faut viser un état cohérent, pas forcément “identique partout”. WordPress n’a pas besoin que chaque fichier ait exactement le même propriétaire, mais il a besoin que le processus web ait les accès requis et que les zones sensibles ne soient pas trop modifiables.
La correction typique consiste à:
- réattribuer la propriété des fichiers et répertoires à l’utilisateur correct, ajuster les groupes si votre serveur suit une convention, resserrer les droits sur les fichiers PHP et les répertoires qui ne doivent pas être accessibles en écriture, laisser uploads écrire, parce que l’upload est un besoin fonctionnel.
Le risque, c’est de “tout resserrer” au point de casser des fonctionnalités. Par exemple, si vous retirez les droits d’écriture de uploads ou d’autres répertoires que votre configuration utilise pour la mise à jour et les médias, vous déclencherez des erreurs d’upload ou de mise à jour. Le meilleur réflexe est de comparer avec un état sain ou avec un modèle de droits cohérent pour votre environnement.
La méthode pratique de triage (avant et pendant le nettoyage)
Quand je dois intervenir en production, je cherche un workflow qui réduit les allers-retours. L’idée n’est pas de multiplier les changements, mais d’en faire assez pour stopper la rechute et assez peu pour ne pas casser.
Voici https://gardewp.fr/nettoyage-malware-wordpress/ une approche de triage assez universelle, adaptable selon vos droits d’accès au serveur:
- dresser un inventaire rapide des fichiers PHP modifiés récemment dans wp-content (thèmes, plugins, fichiers à la racine), vérifier pour ces fichiers les propriétaires et les permissions, et comparer avec des fichiers “équivalents” non suspects, contrôler les permissions des répertoires où WordPress doit écrire, notamment wp-content/uploads, rechercher les incohérences extrêmes (droits trop larges, propriétaires inattendus) sur wp-content et ses sous-dossiers, après correction, re tester le comportement du site et surveiller les accès et erreurs pendant quelques heures.
Le triage évite une erreur fréquente, celle de passer directement à la suppression. Si vous supprimez un fichier malveillant, mais que vous laissez les droits “dans le mauvais sens”, l’attaque peut se reformer. À l’inverse, si vous corrigez les droits sans supprimer le code, vous risquez de conserver une capacité d’exécution ou de persistance.
Quels droits viser, sans promesse irréaliste
La question la plus fréquente est: “quelles valeurs exactes mettre?”. Le problème, c’est que ça dépend de la configuration serveur, du mode d’accès (FTP, shell), de l’utilisateur web, et parfois de la manière dont votre hébergeur standardise les droits.
Je peux toutefois donner des repères prudents, utiles pour décider. Sur un site WordPress classique:
- les fichiers PHP doivent rester lisibles par le processus web et modifiables uniquement par les administrateurs ou le mécanisme de déploiement, les répertoires doivent pouvoir être parcourus et, pour ceux qui contiennent des uploads, être écrits par WordPress, les exécutions ne doivent pas devenir “publics” sur des zones qui ne nécessitent pas l’exécution.
Évitez les configurations qui ouvrent l’écriture ou l’exécution à tout le monde, même si “ça marche”. L’objectif de désinfection, ce n’est pas seulement de rendre le site propre une fois. C’est de rendre la recontamination moins triviale.
Si vous avez une référence interne, par exemple un export d’un site sain ou une documentation d’hébergement, c’est souvent la meilleure boussole. Si vous n’en avez pas, comparez avec la structure existante en prenant garde aux exceptions normales (certaines cache, certains dossiers temporaires, éventuellement des configurations spécifiques).
Comment repérer une propriété “suspecte” sur les fichiers
La propriété “suspecte” ne se limite pas à “tout appartient à root” ou “tout appartient à un compte étrange”. J’ai vu des environnements où le propriétaire était volontairement différent pour des raisons d’exploitation ou de sécurité, mais dans le contexte d’une compromission, l’incohérence attire l’œil.
Un bon réflexe est de regarder:
- les fichiers du core (wp-admin, wp-includes) changent-ils de propriétaire ou de droits de manière incohérente? les thèmes et plugins ont-ils des droits d’écriture qui ne correspondent pas au processus web attendu? les fichiers récemment modifiés dans wp-content ont-ils un historique de droits différent des fichiers voisins?
Dans plusieurs interventions, l’écart le plus parlant était dans wp-content. Les uploads ont une logique d’écriture, les thèmes et plugins ont une https://gardewp.fr/ logique de déploiement. Si vous constatez que les thèmes ou certains plugins sont modifiables comme des uploads, c’est un drapeau rouge.
Les limites et cas où les permissions ne suffisent pas
Vérifier les permissions et propriétaires est essentiel, mais ce n’est pas une baguette magique.
Il y a des cas où l’attaque persiste même avec des droits “propres”:
- un identifiant admin compromis, où l’attaquant ajoute de nouveaux fichiers depuis WordPress, une porte côté base de données, où des modifications sont injectées directement via une faiblesse applicative, une vulnérabilité d’exécution distante non corrigée, où l’attaquant peut encore déposer du code malgré des restrictions, des mécanismes de cache ou d’optimisation qui régénèrent des fichiers et donnent une illusion de retour.
Dans ces situations, la stratégie doit combiner correction système et correction applicative. Les permissions jouent un rôle de barrière, mais elles ne remplacent pas la suppression du code malveillant et la sécurisation du vecteur d’entrée.
Corriger sans casser: l’équilibre opérationnel
Quand vous changez des permissions sur un site WordPress, il y a une tension immédiate entre sécurité et disponibilité.
Si vous resserrez trop, vous aurez:
- des uploads impossibles, des mises à jour de plugins en échec, des erreurs de création de dossiers temporaires, parfois des plantages silencieux dans le back-office.
Si vous resserrez trop peu, vous aurez une désinfection fragile, avec une rechute probable.
La manière la plus sûre de progresser est de limiter la zone de changement à ce qui est “manifestement incohérent”. Si vous ne trouvez aucune anomalie sur des répertoires qui doivent être modifiables, inutile de les attaquer. En revanche, si vous observez une différence brutale de propriétaire ou des droits d’écriture étendus sur un fichier PHP inattendu, c’est exactement le genre de cible qu’il faut corriger.
Une mini grille de décision basée sur les symptômes (et ce que ça implique)
J’utilise souvent une correspondance “symptôme probable” pour orienter la vérification des permissions, surtout quand il n’y a pas le temps pour une analyse exhaustive.
Voici comment je raisonne typiquement:
- si les fichiers malveillants “reviennent” après suppression, la première hypothèse est une persistance via droits d’écriture, ou un mécanisme côté WordPress (identifiants, tâche planifiée, plugin malveillant actif) qui recopie le code, si le site est propre mais des uploads échouent après un nettoyage, alors la correction de droits a peut-être touché uploads ou un dossier requis, il faut vérifier l’utilisateur web et les droits de ces emplacements, si le back-office est accessible mais les pages publiques redirigent, on suspecte souvent un fichier PHP ou un comportement injecté, et là la cohérence des droits dans wp-content et les thèmes enfants devient un axe prioritaire, si la totalité du site devient instable, on suspecte parfois une incohérence de lecture sur les fichiers, un dossier qui ne peut plus être parcouru, ou un changement trop agressif qui a cassé le chemin d’exécution.
Ce raisonnement ne remplace pas le diagnostic, mais il permet d’éviter de “forcer” des corrections sans comprendre ce qui casse.
Ce que j’ai appris en pratique sur les comptes de fichiers
Les chantiers qui se passent bien ont presque toujours un point commun: on respecte le modèle d’accès prévu par l’hébergement.
Sur certains serveurs, le propriétaire attendu des fichiers et le groupe attendu sont documentés, ou au minimum visibles via un site témoin sain. Sur d’autres, tout dépend de la façon dont l’hébergeur gère le mutualisé, ce qui rend la notion de “valeur universelle” moins pertinente.
J’ai aussi appris à ne pas confondre “le bon droit” et “la bonne logique”. Par exemple, un fichier PHP avec des permissions strictes peut être parfaitement sain s’il est bien propriétaire du compte web, mais un même fichier “strict” peut être suspect si son propriétaire est différent de celui des autres fichiers similaires, ou s’il a été modifié récemment sans explication.
Autre leçon utile: si vous avez accès à un environnement de récupération ou à une sauvegarde connue, comparez les métadonnées (propriétaire, droits) autant que le contenu. Il arrive que la compromission ne change que quelques octets, mais modifie les droits comme un effet secondaire. L’écart vous guide.
Concrètement, quoi faire après avoir corrigé permissions et propriétaires
La correction ne doit pas finir au moment où l’on tape une commande ou qu’on modifie quelques valeurs dans un gestionnaire de fichiers.
Après correction, je recommande de valider la cohérence sur trois axes:
1) fonctionnement: le front et le back-office doivent répondre sans erreurs, 2) persistance: pendant une fenêtre de surveillance courte, les symptômes ne doivent pas revenir, 3) traçabilité: si vous avez des logs, surveillez les erreurs et les accès inhabituels.
Si vous voyez que quelque chose réécrit des fichiers après correction, ne partez pas du principe que “c’est WordPress”. WordPress a des comportements prévisibles, surtout sur uploads et certaines zones temporaires. Si la réécriture concerne des fichiers PHP dans des endroits sensibles, c’est souvent un programme qui tourne encore, ou un processus de persistance qui a besoin d’être coupé.
Ajuster les droits, puis verrouiller l’accès côté WordPress
Les permissions système sont une barrière. La barrière la plus efficace reste celle qui ferme l’accès côté application.
Même si vous corrigez tout, je vous conseille de garder en tête le duo “système et application”:
- suppression et remplacement du code suspect, mots de passe forts et rotation ciblée des comptes, vérification des utilisateurs, des rôles, et des mécanismes de planification, mise à jour de ce qui était obsolète, en tenant compte des versions réellement installées.
L’objectif est d’empêcher la rechute sous deux angles, celui des fichiers sur disque et celui des actions via l’application.
Un dernier point souvent oublié: la cohérence du dossier uploads et des caches
Le dossier wp-content/uploads a une vie particulière. Il doit pouvoir recevoir des médias. Mais dans une compromission, on voit aussi des usages détournés, par exemple des fichiers déposés dans uploads qui ne devraient pas être exécutables.
Votre stratégie doit donc faire preuve de nuance: autoriser l’écriture là où elle est nécessaire, mais éviter d’ouvrir l’exécution ou des droits trop généreux.
Pour les caches et dossiers temporaires, le principe est le même. Certains dossiers sont régénérés, donc leurs droits et propriétaires doivent rester alignés avec l’exécution normale. Si vous corrigez un dossier cache et que WordPress ne peut plus le régénérer, vous allez corriger un problème et en introduire un autre, parfois sous forme d’erreurs “500” ou de comportement étrange.
Souvent, la meilleure démarche consiste à corriger les incohérences extrêmes en priorité, puis à stabiliser le fonctionnement avant de durcir progressivement.
Check final: ce que vous devriez avoir après une vraie désinfection
Si la désinfection “tient”, les permissions et propriétaires doivent refléter la logique de votre site:
- les zones de code ne sont modifiables que par les bons acteurs, les zones d’upload sont modifiables par WordPress, les droits ne sont pas plus ouverts que nécessaire, et la configuration ne réautorise pas la persistance dès que vous supprimez un fichier.
C’est aussi pour cette raison que, dans les interventions que je préfère, on finit rarement par “une commande magique”. On termine par une cohérence: propriétaire, groupe et droits restaurés selon un modèle raisonnable, validés par le fonctionnement et par une courte surveillance.
Si vous voulez, dites-moi votre contexte (hébergement mutualisé ou serveur dédié, accès via shell ou gestionnaire de fichiers, et si vous avez détecté des fichiers suspects dans wp-content). Je pourrai vous proposer une grille de vérification plus ciblée sur les zones à contrôler en priorité et sur le niveau de durcissement réaliste, sans casser l’upload ni les mises à jour.