Quand un WordPress se fait compromettre, la première question n’est pas “comment réparer”, c’est “qu’est-ce qui a été modifié, et jusqu’où”. On peut tout passer à la moulinette de sécurité, vider le cache, changer les mots de passe, supprimer des plugins. Mais si le cœur de WordPress a été altéré, même légèrement, tu repars sur une base qui peut continuer à servir l’attaque.
Dans la pratique, j’ai vu deux scénarios très différents. Le premier, c’est une infection “bruyante”, avec des redirections visibles, du spam relayé ou des fichiers PHP inconnus dans les répertoires légitimes. Le second, plus insidieux, ressemble à un site normal, mais des requêtes sortent ailleurs, des scripts s’ajoutent dans le footer, et certains formulaires déclenchent des actions à distance. Dans les deux cas, restaurer les fichiers core et comparer les différences permet de retrouver un repère solide.
Ce texte détaille une méthode de terrain pour nettoyer un site WordPress infecté en restaurant les fichiers core et en analysant les écarts, avec les compromis et les pièges à éviter.
Distinguer “infecté” et “modifié”
Avant de remplacer quoi que ce soit, je pars toujours d’une observation simple: une infection WordPress n’est pas forcément une “corruption massive” de WordPress. Souvent, l’attaque vise un point précis, par exemple un fichier PHP exécuté sur une requête (un index, un loader, un plugin), ou une zone où les fichiers changent sans alerte (uploads, cache, thèmes).
Restaurer le core n’a de sens que si tu acceptes une réalité technique: tu ne peux pas garantir que tout est propre juste parce que WordPress est “à jour”. En revanche, tu peux réduire une incertitude majeure. Si le core a été modifié, tu le neutralises. Si le core n’a pas été modifié, tu sais que la piste la plus probable se trouve ailleurs (thème, plugin, uploads, base de données).
J’en fais un règle maison: le core est un terrain https://gardewp.fr/nettoyage-malware-wordpress/ neutre. Le reste, c’est le champ de bataille.
Préparer une intervention qui ne fabrique pas d’autres problèmes
Le nettoyage “propre” commence rarement par une action. Il commence par une discipline.
Première étape: prendre des sauvegardes cohérentes, pas seulement un export de base de données. Il faut aussi une capture des fichiers, et si possible une copie synchronisée du document root. Selon l’hébergement, ça peut être rapide ou laborieux, mais le risque de tout casser diminue énormément quand tu as au moins un état complet “avant”.
Deuxième étape: documenter la version exacte de WordPress, les répertoires, et ce que tu observes côté navigateur et côté serveur. Par exemple, si tu vois des redirections incohérentes, note les URL de départ et d’arrivée, les horaires approximatifs, et si ça se produit uniquement pour certains user-agents ou certaines pages.
Troisième étape: choisir une approche de comparaison. Le but n’est pas seulement de remplacer, c’est de prouver ce qui a changé.
Petit détail qui évite des heures perdues
Avant de restaurer, vérifie aussi les paramètres d’environnement: PHP handler (mod_php, PHP-FPM), cache serveur (Varnish ou autre), et outils de déploiement. J’ai déjà vu une restauration “core” réussie sur un environnement, puis un retour de l’infection après redéploiement à cause d’un processus d’automatisation qui re-dépose des fichiers modifiés. Si tu as un pipeline (même simple), il faut l’aligner sur ton état sain.
Restauration des fichiers core, la méthode la plus sûre
L’idée est de réinstaller les fichiers “officiels” correspondant exactement à la version de WordPress installée, puis de vérifier ce qui a été remplacé.
Il y a une différence importante entre “télécharger WordPress propre” et “remplacer les bons morceaux sans toucher au reste”. Sur WordPress, les fichiers core sont relativement identifiables: scripts principaux, bibliothèques, fichiers racine, etc. Mais certains dossiers contiennent aussi des éléments non-core (uploads, éventuellement des mu-plugins, ou des caches). Donc, tu dois restaurer ce qui appartient au core, pas tout mélanger au hasard.
Vérifier la version et les contrôles possibles
Si tu peux utiliser WP-CLI, c’est souvent le moyen le plus direct pour détecter des écarts. La commande de vérification des sommes de contrôle (“verify-checksums”) permet de repérer des fichiers core modifiés. Selon la configuration, elle peut échouer si les données ne sont pas disponibles ou si WordPress n’a pas le contexte attendu, mais quand elle fonctionne, elle donne une liste claire.
Si tu ne peux pas utiliser WP-CLI, tu fais “à la main”, en téléchargeant la version correspondante et en comparant les arborescences.
Dans les deux cas, l’objectif final reste identique: restaurer le core à un état connu propre, puis analyser les différences pour comprendre l’origine.
Restaurer avec un téléchargement contrôlé
La méthode que j’utilise le plus souvent ressemble à ceci:
- Tu télécharges la distribution WordPress correspondant à la version exacte. Tu compares l’arborescence locale propre à l’arborescence du site. Tu remplaces uniquement les fichiers du core qui ont été modifiés ou qui diffèrent. Tu laisses les répertoires de contenus non-core tels quels (uploads, thèmes custom, plugins, etc.), sauf si ton audit montre qu’ils ont été touchés.
L’avantage de cette approche, c’est qu’elle te force à regarder. Remplacer “au hasard” marche parfois, mais tu perds l’occasion de comprendre la chaîne d’infection. Et dans un incident récurrent, comprendre est capital.
Comparer les différences: de la vision “humaine” à la preuve technique
Restaurer sans comparer, c’est comme désinfecter une pièce sans regarder quelles traces tu as enlevées. Le site peut sembler guéri, mais la cause revient si tu n’as pas neutralisé ce qui a déclenché l’altération.
Comparaison contrôlée côté fichiers
Il y a plusieurs niveaux possibles:
Comparaison “structure” (présence/absence) Comparaison “contenu” (diff) Comparaison “empreintes” (hashes)La combinaison la plus pratique en incident, c’est de commencer par la structure, puis de plonger sur les fichiers suspects.
Un exemple concret. Sur un site que j’ai déjà accompagné, le core semblait “fonctionner”, mais la page d’accueil ajoutait un fragment de script dans le HTML final. La restauration core seule n’avait rien changé. La comparaison a montré que le fichier responsable n’était pas le core, mais un plugin, et que le code malveillant était “injecté” via un hook. Tant que je n’avais pas comparé les fichiers modifiés, je cherchais du côté des redirections racine.
Comparer les hashes pour trier vite
Si tu peux calculer des empreintes (SHA-256 ou autre) pour les fichiers core, tu gagnes du temps. Les fichiers core modifiés se détachent immédiatement par des différences d’empreinte. Ensuite, tu ouvres uniquement les fichiers concernés et tu lis les changements.
C’est aussi une bonne méthode pour éviter le piège suivant: un fichier peut avoir été “touché” (timestamp modifié) sans être malveillant. Les timestamps varient avec des déploiements, des copies, des corrections manuelles. Les hashes, eux, correspondent au contenu réel.
Lire les différences, ce que je regarde en premier
Quand tu as la différence, tu veux répondre à trois questions:
- Est-ce que l’attaque est un simple ajout (exécution d’un code de manière conditionnelle), ou un remplacement plus profond de logique ? Le code s’exécute-t-il au chargement (autoload), dans un hook, ou au moment d’une requête particulière ? Les modifications concernent-elles la conformité (par exemple, une inclusion d’un fichier distant, une obfuscation, un base64 decode au runtime) ?
Dans beaucoup d’infections, le core modifié contient un code minuscule, parfois quelques dizaines de lignes, voire un seul bloc. Le reste du fichier ressemble au fichier officiel. C’est justement pour ça que la comparaison est indispensable, car à l’œil nu, tu peux passer à côté.
Cas réels fréquents: que se passe-t-il quand le core a été altéré ?
Beaucoup de propriétaires pensent que l’attaque touche forcément des plugins. Pourtant, j’ai vu des modifications du core dans des cas où l’attaquant avait:
- obtenu des droits suffisants pour écrire dans le document root, exploité une vulnérabilité ou un outil de déploiement, ou abusé d’un script de mise à jour compromis.
Quand le core est modifié, les symptômes varient. Parfois c’est un backdoor globale, parfois une altération d’un point d’exécution, parfois une fonction remplacée avec une version “étendue”.
Il faut aussi considérer l’autre sens: parfois tu as l’impression d’une infection core, mais ce sont des différences légitimes liées au serveur. Par exemple, certains fichiers peuvent avoir des différences de paramètres, de lignes ajoutées par un processus de build interne (rare sur WordPress “standard”), ou des corrections déjà appliquées. D’où l’intérêt de comparer au bon “référentiel” correspondant exactement à la version installée.
Restaurer le core ne suffit pas si la base et les hooks sont déjà contaminés
Même si tu neutralises le core, il reste un risque majeur: la base de données et les mécanismes d’exécution.
Un site infecté peut contenir dans la base des entrées modifiées, options changées, utilisateurs ajoutés, ou des données qui injectent du JavaScript au rendu. Si tu ne nettoies pas ces éléments, tu peux retrouver le problème dès que WordPress reconstruit la page.
Autre point, souvent oublié: les fichiers non-core. Un plugin infecté peut se reposer sur le core “normal” et ne dépend pas de son altération. Restaurer le core peut donner l’impression que tout est revenu à la normale, alors que l’injection vient toujours d’un fichier de thème ou de plugin.
En incident, la logique que je suis est simple: core d’abord (pour neutraliser un vecteur possible), ensuite plugins et thèmes, puis uploads et enfin base de données, dans cet ordre là quand c’est faisable. Le tri réduit la charge mentale.
Où chercher l’infection après la restauration core
La restauration core a un effet psychologique, mais techniquement elle sert surtout à éliminer. Une fois le core remis propre, tu observes à nouveau.
Si l’infection persiste, je regarde en priorité les endroits où un attaquant peut agir sans toucher au cœur:
- fichiers PHP exécutables dans les zones de thèmes et plugins fichiers ajoutés dans uploads (ou dans des sous-dossiers inattendus) pages, widgets ou scripts enregistrés dans la base comptes utilisateurs créés ou modifiés
Il y a aussi un comportement typique: l’attaquant déploie une webshell ou un “dropper” puis efface ses traces sur certains chemins. Dans ce cas, la comparaison des fichiers, combinée à des logs (si tu en as), t’aide à comprendre l’évolution.
Une approche pratique, étape par étape (avec jugement)
Je te propose une séquence qui fonctionne bien quand tu dois agir sans perdre de temps. Elle n’est pas “unique”, mais elle est robuste.
Étape 1: créer un “référentiel propre” pour la comparaison
Télécharge WordPress pour la version exacte. Ensuite, prépare une comparaison locale entre:
- les fichiers core du site (depuis ton document root) les fichiers core de la distribution propre
Tu peux faire une comparaison diff sur les dossiers du core. Si tu as peu de confort avec les outils en ligne de commande, tu peux au moins faire un inventaire des fichiers présents et vérifier les tailles et dates de modification. Mais en incident, je préfère la comparaison contenu, même basique, parce que la taille et la date peuvent mentir.
Étape 2: restaurer uniquement le core modifié
Sur la base de tes différences, tu remplaces les fichiers core qui diffèrent. Le principe: tu n’écrases pas ce que tu n’as pas identifié comme suspect, sauf si ton diagnostic l’impose.
Cette retenue évite un problème classique: tu remplaces un fichier non-core par un fichier core parce que tu as copié un dossier entier trop large. C’est rare, mais assez coûteux pour qu’on s’en méfie.
Étape 3: recontrôler après restauration
Tu testes le front et les pages connues, tu vérifies les comportements sur plusieurs navigateurs, et tu surveilles le serveur si possible (par exemple, augmentation des requêtes vers certains endpoints, sorties réseau, ou erreurs PHP).
Si le site redevient normal, tu n’arrêtes pas là. Tu compares encore, mais cette fois sur les zones non-core, parce que le core n’était peut-être qu’un premier vecteur.
Étape 4: si l’infection persiste, passer au reste
Là, tu entres dans un mode plus “enquête”. Tu regardes les modifications sur les plugins et thèmes, puis tu passes en revue la base. Et tu vérifies aussi que tu n’as pas une persistance via un fichier dans uploads.
Je préfère l’ordre suivant: plugin, thème, uploads, puis base. Pourquoi? Parce que les plugins et thèmes donnent souvent des indices dans leurs fichiers, et parce que tu peux parfois éliminer rapidement en désactivant des composants. La base peut rester dans un état dangereux même si tu corriges les fichiers.
Une mini check-list utile avant de redonner accès
- Faire une sauvegarde complète avant toute suppression Identifier la version exacte de WordPress et restaurer le core à l’identique Comparer core avant et après restauration, noter les fichiers remplacés Tester le site sur plusieurs routes, pas seulement la page d’accueil Prévoir une phase de revue des plugins, thèmes et uploads si l’attaque persiste
Comparer “avant après” sur le core: comment interpréter
Quand tu as remplacé les fichiers core, tu dois t’assurer que ce que tu as fait n’a pas créé d’écart ailleurs.
Il y a deux niveaux d’analyse:
- vérifier que les fichiers core sont conformes à la distribution propre vérifier que le comportement du site est cohérent
Sur le premier point, tu peux refaire une comparaison et voir que tous les fichiers core sont identiques. Sur le second point, tu surveilles le site.
Un piège courant: tu compares les fichiers core, ils sont propres, mais tu as un problème intermittent. Cela peut venir d’un cache, d’une régénération, ou d’un contenu dans la base. L’attaque peut être “triggerée” seulement sur certaines requêtes ou périodes.
Dans un incident réel, j’ai vu une infection qui ne se déclenchait que sur des pages spécifiques et seulement lorsqu’un paramètre d’URL était présent. Si tu ne testes pas ces pages-là pendant ta phase de vérification, tu crois à tort que la restauration core a tout réglé.
Les compromis: tout effacer ou restaurer précisément ?
La tentation en incident, c’est de tout supprimer et réinstaller. Ça marche parfois, surtout sur des sites simples. Mais sur des WordPress qui ont des personnalisations importantes, tu peux perdre du temps et introduire des régressions.
Pour décider, il faut poser une question: le site est-il “réparable” sans trop de coût, ou le risque résiduel est-il trop élevé ?
Voici comment j’arbitre quand je dois choisir entre restauration fine et réinstallation plus radicale.
| Situation observée | Restauration du core fine | Réinstallation plus radicale | |---|---|---| | core modifié mais plugins et thème encore stables | très adaptée, car tu neutralises vite le vecteur | possible mais plus de travail et de risque | | infection persistante, beaucoup de fichiers différents et timestamps suspects | utile en premier, puis tu bascules vers investigation étendue | peut être plus rapide si tu peux re-déployer proprement | | site complexe avec custom mu-plugins, déploiements spécifiques | préférable, pour éviter de casser le contexte | risqué, car tu dois reconstituer exactement l’environnement | | manque de sauvegardes ou historique flou | tu fais des comparaisons avec prudence | parfois la seule option réaliste |
Le vrai critère que je regarde, c’est la capacité à revenir en arrière et à reconstruire proprement. Si tu peux restaurer une base saine et des fichiers propres, tu peux être précis. Si tu n’as pas cette maîtrise, la stratégie “repartir d’un état standard” peut être plus sûre, à condition de traiter aussi la base et les composants infectés.
Après la neutralisation: sécuriser pour ne pas recommencer
Nettoyer un site WordPress infecté ne se résume pas à enlever un fichier malveillant. Le point de rupture, c’est souvent la même faille d’origine: identifiants faibles, plugin vulnérable, permissions trop ouvertes, ou mécanismes d’upload insuffisamment contrôlés.
Sans tomber dans des recettes universelles, voici ce que je vérifie systématiquement après restauration core et nettoyage:
- comptes utilisateurs et rôles: utilisateurs inattendus, changements de rôle, mots de passe non rotés plugins et thèmes: suppression de ceux qui ne servent pas, mise à jour de ceux qui restent permissions: dossiers inscriptibles trop largement, surtout dans les zones non nécessaires rotation des clés et des sessions si applicable surveillance après incident: logs, alertes, comportement anormal
Le but est de réduire la surface d’attaque et d’éviter qu’un même vecteur se reproduise. Sinon, tu peux “nettoyer” trois fois, sans comprendre pourquoi.
Ce que “comparer les différences” t’apporte vraiment
On pourrait réduire toute la démarche à “remplacer les fichiers core par ceux d’origine”. C’est nécessaire, mais ce n’est pas suffisant sur le long terme.
La comparaison des différences te donne:
- une liste exploitable des fichiers core modifiés (preuve concrète) un point de départ pour l’analyse des autres zones (si core est touché, qui a pu y accéder ?) une manière de distinguer un incident ponctuel d’une compromission plus profonde un repère pour savoir si tu repars sur quelque chose de sain
Sur un plan plus humain, elle calme aussi le stress. Quand tu as un rapport de différences, tu ne te contentes pas de “sentir” que ça va mieux. Tu sais ce qui a été changé, et tu peux expliquer à ton client ou à ton équipe pourquoi la décision a été prise.
Pièges fréquents à éviter quand tu restaurer le core
Il y a quelques erreurs qui reviennent souvent, même chez des personnes compétentes.
- Remplacer des fichiers core sans s’assurer de la version exacte, ce qui crée des écarts difficiles à diagnostiquer. Remplacer trop large, par exemple en écrasant des fichiers de thème ou de plugin par erreur. Réinstaller le core, puis laisser des plugins ou thèmes infectés actifs. Le site peut redevenir “sale” rapidement. Tester uniquement la page d’accueil, alors que l’injection ne se produit que sur une page ou un type de requête. Négliger la base de données: même avec un core propre, des options injectent du contenu.
Le nettoyage consiste à réduire ces angles morts. La comparaison est justement le moyen de les repérer avant qu’ils ne te fassent perdre une journée entière.
Quand faire appel à une démarche plus profonde
Si tu as des indices sérieux de compromission (exécution persistante, modifications nombreuses, activité réseau suspecte, comptes multiples, ou absence de sauvegardes fiables), tu passes à un mode plus complet. Dans ce cas, restaurer le core reste une pièce du puzzle, mais tu dois aussi traiter:
- l’origine de l’accès l’état complet de la base la persistance via des fichiers ou des tâches programmées la cohérence entre les déploiements et les fichiers présents
Je n’aime pas “couvrir” une compromission en espérant que ça disparaît. Je préfère traiter la chaîne, sinon tu ne sais jamais ce que tu protèges.
Conclusion technique sans slogan: un core propre, mais un diagnostic complet
Restaurer les fichiers core et comparer les différences, c’est une démarche de rigueur. Elle sert à remettre un repère fiable au milieu du chaos: tu élimines un vecteur potentiel et tu produis des éléments concrets pour la suite. Ensuite, tu peux poursuivre l’enquête sur les plugins, thèmes, uploads et la base de données, sans travailler à l’aveugle.
Si tu fais les choses bien, tu ne te contentes pas de “nettoyer site WordPress infecté”, tu réduis aussi le risque de récidive, et tu transformes l’incident en diagnostic réutilisable pour les prochaines opérations de maintenance.