Désinfection WordPress : comment vérifier l’intégrité des fichiers

Quand on parle de désinfection WordPress, on pense vite à “supprimer le malware”. En pratique, c’est souvent la dernière étape. Avant de remplacer des fichiers, de restaurer une sauvegarde, ou de relancer un site censément propre, il faut une idée claire de l’état réel des fichiers WordPress sur le serveur. L’intégrité n’est pas un concept abstrait: c’est la différence entre un site revenu au calme et un site qui “revient à infecter” quelques heures plus tard.

J’ai vu des cas où un nettoyage semblait réussir, puis où des redirections frauduleuses réapparaissaient. La cause n’était pas toujours “un oubli”. Parfois, un fichier-modèle du thème ou un script dans un dossier d’upload était inchangé, parfois c’était une mise à jour incomplète, parfois encore c’était un backdoor dans un fichier qui n’avait rien à faire dans WordPress, mais qui survivait parce qu’on l’avait laissé en place par automatisme.

Vérifier l’intégrité des fichiers, c’est donc se donner une boussole. Pas une certitude absolue, car un attaquant peut aussi modifier des éléments de contrôle. Mais c’est une base solide pour trier ce qui est suspect de ce qui est normal.

Pourquoi l’intégrité est le nerf de la guerre

WordPress repose sur un ensemble de fichiers “attendus”: le core, les thèmes, les plugins, quelques fichiers de configuration, et les contenus (médias et articles). Une compromission vise souvent deux choses:

Ajouter ou modifier du code dans des fichiers qui s’exécutent. Dissimuler la persistance, pour que le nettoyage soit temporaire.

Les symptômes côté site (spam dans les commentaires, redirections, formulaires détournés, pages créées automatiquement) sont importants, mais ils ne disent pas toujours quel fichier a bougé. Les symptômes peuvent aussi venir de fichiers qui ne sont pas modifiés directement, par exemple un cron corrompu, une règle serveur, ou un compte administrateur ajouté.

La vérification d’intégrité apporte une réponse plus mécanique: “est-ce que tel fichier est identique à celui qu’il devrait être”. C’est particulièrement utile pour distinguer:

une infection “simple”, dans un plugin ou un thème une altération du core une modification de fichiers installés différemment par une procédure de déploiement une pollution dans les uploads, donc dans des fichiers qui ne sont pas censés être exécutés comme PHP

Le piège du “tout a l’air bon”

Beaucoup d’interventions commencent par un examen visuel. On ouvre les fichiers modifiés, on cherche une signature, on commente des portions douteuses. C’est utile en incident response, mais ça rate plusieurs scénarios courants.

D’abord, les attaquants savent se faire discrets. Ils peuvent insérer un chargement conditionnel, ne déclencher du code que dans certaines conditions (user agent, plage d’IP, moment), ou stocker un code dans une ressource encodée. Ensuite, les modifications peuvent être minuscules et ciblées, donc invisibles à un coup d’œil.

Enfin, même quand on remplace les fichiers du core, il peut rester une porte d’entrée ailleurs: un plugin oublié, un thème enfant, un fichier dans wp-content/uploads, ou un composant ajouté dans un répertoire “cache” ou “logs” qui finit par être exécuté selon la configuration du serveur.

C’est pour cela que l’intégrité doit être pensée comme une chaîne. On vérifie le core, puis on vérifie les thèmes et plugins, puis on inspecte les répertoires à risque, et seulement après on valide le site de manière fonctionnelle.

Ce qu’on entend par intégrité, et ce qu’on ne peut pas garantir

Vérifier l’intégrité https://gardewp.fr/nettoyage-malware-wordpress/ ne veut pas dire “l’attaque est impossible”. Ça veut dire “les fichiers correspondent à une référence fiable”.

La difficulté, c’est que la “référence” peut varier. Un site peut avoir:

des modifications légitimes (ajout de snippets de sécurité, custom templates, mu-plugins maison) un déploiement qui applique des patchs des versions non standard (plugins branchés sur un fork) des mises à jour partielles

Quand on compare à une version “officielle” du core, on peut déclencher de faux positifs, ou au contraire ne rien voir si l’attaque ne touche pas le core. Quand on compare uniquement les hash, on peut aussi manquer un fichier ajouté au bon endroit mais chiffré ou déguisé.

En clair, l’intégrité donne une base, pas une vérité globale.

Préparer le contrôle sans casser le site

Avant de lancer des commandes ou de remplacer des fichiers, l’objectif est d’éviter de rendre la suite plus difficile.

La première étape, c’est de travailler depuis une copie, ou au minimum de conserver un état reproductible. Sur un site critique, je conseille généralement de faire au moins un instantané complet et vérifiable. Ensuite, on peut procéder à des contrôles.

Voici une petite liste utile avant toute vérification à grande échelle:

activer une maintenance le temps de la phase de contrôle, ou limiter l’accès admin si le site doit rester public sauvegarder les fichiers WordPress et, si possible, consigner la version exacte (core, thèmes, plugins) noter les points de persistance connus (tâches cron, utilisateurs admin, mu-plugins, config serveur) vérifier que vous avez accès à une méthode de comparaison fiable (outils de checksums, WP-CLI si disponible) planifier une fenêtre de rollback, pour revenir à un état cohérent si un remplacement casse le site

Vérifier l’intégrité du core: l’approche la plus robuste

Le core WordPress est le meilleur candidat pour l’intégrité, parce que la référence est standard: les fichiers du core publiés par WordPress. L’idée est simple: calculer des empreintes (hash) et comparer à celles attendues pour votre version.

Si WP-CLI est disponible sur votre serveur, la commande wp core verify-checksums est souvent le moyen le plus direct. Elle s’appuie sur les checksums attendus pour la version installée et signale les fichiers qui diffèrent.

Exemple de logique de contrôle, selon votre environnement:

Wp core verify-checksums

Si la commande signale des divergences, la question devient immédiate: est-ce une modification légitime, ou un signe d’infection? Sur un incident, la plupart du temps, des différences sur le core sont un signal fort. Mais il y a des cas particuliers: patchs “maison”, installation avec fichiers custom, ou mises à jour incomplètes.

Dans un contexte de désinfection WordPress, j’ai tendance à traiter ces divergences comme suspectes tant qu’on n’a pas une justification claire. La réparation consiste alors à réinstaller proprement le core à partir des fichiers officiels correspondant à la version.

Attention, un point pratique: si vous avez un système de cache agressif ou un mécanisme de déploiement qui remplace les fichiers, assurez-vous que la phase de vérification est alignée avec ce qui se passe réellement sur le serveur. J’ai déjà vu une vérification “réussir” sur un environnement stagiaire, puis échouer en production car les fichiers ne correspondaient pas au même build.

Comparer les thèmes et plugins: là où les résultats deviennent moins simples

Les thèmes et plugins ne sont pas aussi standardisés que le core. Un plugin peut être une version personnalisée, un thème enfant peut avoir des fichiers additionnels, et des modifications peuvent être légitimes (ajouts de templates, override de hooks).

Pour autant, les hash restent utiles, à condition d’avoir une référence. Les options concrètes dépendent de votre contexte:

si vous installez uniquement des plugins depuis le répertoire officiel, vous pouvez comparer à la version attendue si vous avez des plugins “premium” téléchargés via une licence, gardez les archives correspondantes si vous avez des thèmes custom, la référence doit venir de votre source de déploiement ou de votre dépôt

Dans une enquête, je procède souvent par étapes: d’abord, identifier ce qui a été modifié “récemment” et ce qui correspond à un comportement suspect. Ensuite, je vérifie l’intégrité seulement sur les composants qui semblent impliqués.

Un raccourci fréquent: regarder les temps de modification

Une approche très pragmatique consiste à relever les fichiers modifiés récemment dans wp-content et les sous-dossiers. Les temps de modification ne prouvent pas une infection, mais ils servent de tri.

Si vous voyez un plugin “tout récent” installé sans ticket interne, ou un thème enfant dont les timestamps sautent juste avant l’apparition des symptômes, c’est un bon point de départ.

Cela dit, même un fichier modifié récemment peut être le résultat d’une mise à jour légitime ou d’un déploiement. Le lien doit être établi par la comparaison d’intégrité ou par une analyse de contenu (fonctionnalité, hooks, présence de code exécutable anormal, chargements de fichiers externes, requêtes inattendues).

Vérifier les uploads et autres zones à risque

Beaucoup d’incidents WordPress utilisent wp-content/uploads comme terrain. Le but est souvent de déposer un fichier, puis de le charger indirectement ou de l’exécuter via une configuration serveur mal protégée. Même quand l’upload “devrait” être non exécutable, une configuration Apache ou Nginx peut parfois rendre des fichiers PHP exécutables, ou permettre un comportement étrange via des interprétations de types.

Ici, l’intégrité n’est pas “comparer à une version officielle”, puisque les uploads sont intrinsèquement variables. Le contrôle consiste plutôt à détecter:

des fichiers PHP, PHAR, ou scripts dans des répertoires où ils ne devraient pas être des fichiers dont le nom, la taille et le contenu ne ressemblent pas à des médias standards des fichiers récemment créés sans justification (campagne, import, upload manuel) des fichiers qui déclenchent des inclusions depuis des hooks du site

Dans ces cas, la “vérification d’intégrité” ressemble moins à une comparaison de hash et plus à une validation de cohérence. Un fichier media typique a une empreinte visuelle, un MIME attendu, et souvent une taille dans des gammes cohérentes. Un fichier de script, même déguisé, a des signatures.

J’ajoute en général une règle mentale simple: si un fichier dans uploads contient du code PHP exécutable (même encodé), il devient candidat à l’élimination, sauf si vous avez un besoin légitime. Dans un site normal, on évite l’exécution PHP dans les uploads.

Vérifier aussi ce qui entoure les fichiers

L’intégrité des fichiers WordPress ne suffit pas toujours. Un attaquant peut modifier autre chose que le code WordPress:

le cron system ou les tâches automatisées des règles serveur via .htaccess, selon la stack (Apache, Nginx) la configuration PHP-FPM ou des paramètres qui rendent un répertoire exécutable des constantes d’environnement ou des fichiers de configuration au niveau serveur des utilisateurs WordPress et la façon dont ils obtiennent des droits

Cela ne veut pas dire qu’il faut arrêter la vérification d’intégrité. Ça veut dire qu’il faut comprendre la portée: “intégrité” pour le core et les plugins, cohérence pour les uploads, et contrôle de configuration pour ce qui influence l’exécution.

Un signe assez parlant: si vous voyez des fichiers WordPress redevenir “modifiés” après nettoyage, c’est souvent un mécanisme externe qui recopie des fichiers. Dans ce cas, la comparaison d’intégrité après chaque étape vous dira très vite si la correction est durable.

Un protocole de validation post-nettoyage, concret et défendable

Après avoir corrigé ce qui était suspect, l’erreur classique est de valider uniquement avec l’interface web. Or l’infection peut rester silencieuse, jusqu’à un contexte précis.

Je préfère une validation en trois axes, avec des contrôles rapides et des vérifications ciblées.

Voici une deuxième liste, courte, pour structurer le “dernier kilomètre”:

relancer la vérification d’intégrité du core et consigner les résultats (qu’est-ce qui a changé, qu’est-ce qui reste différent) parcourir les thèmes et plugins installés, comparer au référentiel connu de vos versions, et repérer les nouveautés vérifier qu’aucun fichier exécutable ne traîne dans les répertoires d’upload (ou d’autres zones censées contenir uniquement des médias) surveiller les logs (erreurs PHP, logs d’accès, événements liés à un fichier ou un endpoint suspect) tester des routes et des formulaires côté front avec un compte non admin, pour repérer redirections et injections

On peut compléter par un test de persistance: pendant quelques heures, surveiller si des fichiers redeviennent suspects. Même une fenêtre courte aide énormément, surtout quand l’attaque est déclenchée par un cron ou un événement périodique.

Quand la vérification échoue: interpréter les divergences

Vous obtiendrez parfois des divergences d’intégrité, même sans infection évidente. C’est là que l’expérience compte.

Cas 1: divergences sur le core

Si wp core verify-checksums signale des fichiers différents, je traite ça comme une alerte prioritaire. Pour trancher, je vérifie la cohérence de la version installée, puis je compare avec les fichiers officiels. Si un composant a été patché légitimement, il faut avoir la trace interne ou le dépôt qui explique la différence. Sans trace, la correction la plus sûre est souvent la réinstallation propre du core.

Cas 2: divergences sur un plugin

Un plugin peut être modifié pour une fonctionnalité custom. Là, il faut distinguer:

une modification qui correspond à votre historique (tickets, repository, déploiement) un ajout de code qui déclenche des actions réseau, une lecture de fichiers, ou une redirection

Sans historique clair, je fais une analyse du flux: quels hooks sont utilisés, quels fichiers sont inclus, quelles conditions déclenchent le code. Une divergence plus une logique douteuse, c’est une décision simple.

Cas 3: pas de divergence sur le core, mais le site est “malade”

C’est fréquent. L’attaque peut être dans un plugin, un thème, un fichier caché dans un répertoire, ou dans une configuration serveur. Vous pouvez aussi avoir un compromis qui ne modifie pas les fichiers WordPress au sens strict, mais qui change la base de données, les utilisateurs, ou des paramètres externes.

Dans ce cas, je reviens aux symptômes et à la “surface” d’exécution: où le site appelle du code, quels fichiers sont chargés à la demande, et quelles pages se comportent différemment.

Les limites à connaître (pour ne pas se faire piéger)

Il y a trois limites que je pose toujours sur la table, parce qu’elles expliquent pourquoi l’intégrité ne suffit pas.

Un attaquant peut aussi modifier la chaîne de vérification. Si les outils de contrôle ou les mécanismes d’intégrité sont compromises, vous pouvez obtenir des résultats “propres” sur un système encore infecté. Un site peut avoir des modifications légitimes, donc des faux positifs. Une équipe qui a l’habitude de patcher ou qui fait des builds personnalisés doit fournir une référence. Un fichier peut être “intègre” selon la comparaison, mais mal configuré via des variables, une configuration serveur, ou une base de données manipulée.

Ces limites ne rendent pas la méthode inutile. Elles obligent juste à garder une logique d’enquête globale et pas un simple bouton “vérifier”.

Relier intégrité et désinfection WordPress: une logique d’enquête

Pour que tout cela serve la désinfection WordPress, il faut connecter chaque résultat à une décision.

Si le core n’est pas intègre, la réinstallation du core devient prioritaire. Si un plugin ou un thème diverge, on regarde le contenu, puis on décide entre remplacement, reconstruction depuis la source, ou correction ciblée. Si des fichiers dans uploads semblent exécutable ou anormaux, on les traite comme des éléments de persistance potentiels. Si rien ne diverge mais que les symptômes persistent, on élargit la recherche, vers la base de données, les utilisateurs, les tâches planifiées, ou la configuration serveur.

En pratique, la “bonne” vérification d’intégrité est celle qui vous permet de dire “nous savons ce qui a été changé, et pourquoi”.

Un exemple vécu, côté terrain

Sur un site e-commerce WordPress, les symptômes étaient une série de redirections vers une page externe, surtout après une action admin. Les fichiers core passaient en apparence, et visuellement, la plupart des plugins étaient “normaux”. Le premier nettoyage a consisté à supprimer un thème enfant suspect et à désactiver deux plugins.

Deux jours plus tard, les redirections ont réapparu. Cette fois, la vérification d’intégrité a montré une divergence sur un fichier du core, pas massive, mais réelle. Ce n’était pas le code injecté, c’était plutôt une petite altération qui servait à charger autre chose. En parallèle, les timestamps sur un fichier de plugin utilitaire dans wp-content/plugins avaient bougé, même si le fichier n’était pas flaggé par l’analyse initiale.

La correction a été plus radicale: remplacement du core depuis les sources officielles, suppression complète du plugin concerné puis réinstallation depuis l’archive connue, et enfin verrouillage de l’exécution PHP sur les uploads. Le point clé, c’est que la vérification d’intégrité a permis d’identifier une persistance qui ne se voyait pas au premier passage.

Ce genre de situation arrive quand on traite les symptômes sans confirmer l’état de base du filesystem.

Méthode de décision: que faire si tout est “intègre” mais que vous doutez

Parfois, vous avez une vérification d’intégrité qui ne remonte pas grand-chose, mais vous gardez un doute. Ce doute est souvent lié à:

des logs qui continuent de montrer des accès anormaux des utilisateurs inconnus une activité anormale de base de données des symptômes qui reviennent après une période

Dans ce cas, l’intégrité des fichiers devient un signal “pas de cible évidente dans le filesystem”. Vous devez alors orienter l’effort sur d’autres pivots: contrôle des comptes, inspection des actions planifiées, analyse des logs, vérification de la configuration serveur, et revue de la base.

L’important est de ne pas forcer une explication “files only”. Un incident WordPress est rarement réduit à une seule catégorie.

Ce que j’enregistre après chaque désinfection

Au-delà du contrôle immédiat, je conseille de documenter les décisions. La désinfection WordPress n’est pas seulement une réparation, c’est aussi une prévention.

Après un incident, je note:

la version exacte du core les plugins et thèmes concernés, et lesquels ont été remplacés les résultats de verify-checksums ou des comparaisons de hash les fichiers suspects supprimés et ceux qui ont été conservés pour analyse les changements de configuration serveur, surtout autour de l’exécution PHP et des accès aux répertoires

Cette documentation rend le prochain incident moins douloureux, et elle facilite les validations internes.

Rester réaliste: intégrité et sécurité, main dans la main

La vérification d’intégrité des fichiers est un outil puissant, mais elle s’inscrit dans une stratégie plus large. La désinfection WordPress devient plus fiable quand elle combine:

contrôles techniques (hash, vérifications core, cohérence des répertoires) analyse de persistance (cron, utilisateurs, configuration serveur) validation fonctionnelle (pages, formulaires, redirections) surveillance post-réparation (heures et journaux)

Si vous devez choisir une priorité au milieu du chaos, gardez une règle simple: commencez par le core, car la référence est la plus nette. Puis élargissez, au lieu de multiplier les réparations “au feeling”. L’intégrité vous donne un fil conducteur, et c’est souvent ce fil qui fait gagner du temps, et éviter les retours à la case départ.