Quand on découvre qu’un site WordPress est possiblement infecté, la première réaction est souvent émotionnelle: panique, reproches, besoin de remettre en ligne au plus vite. Sur le terrain, ce réflexe coûte du temps. Une compromission, ce n’est pas seulement “un fichier bizarre”. C’est souvent un mélange de portes dérobées, de fichiers modifiés, de permissions trop larges et de traces qui ne crient pas “malware” en clair. Vérifier l’intégrité des fichiers WordPress, c’est remettre de l’ordre, sans se contenter d’un coup de balai aveugle.
Dans cet article, je vais expliquer comment raisonner, quoi contrôler exactement, et comment décider quoi restaurer quand tout ne colle pas. L’objectif est clair: savoir ce qui a changé, ce qui est encore fiable, et comment limiter les dommages sur un site WordPress infecté.
Comprendre ce que “l’intégrité” veut dire dans WordPress
WordPress est construit autour d’un noyau (wp-core), d’un ensemble de thèmes et de plugins, et de données (base SQL, médias). Quand on parle d’intégrité des fichiers, on vise principalement la partie “navigable” du serveur: le code PHP, les fichiers générés, les scripts cachés, et parfois des binaires ou des archives déposées sur le webroot.
Une vérification d’intégrité efficace repose sur trois questions:
Cette approche évite un piège courant: tout remettre à zéro sans comprendre la cause. Si le site a été infecté via un plugin vulnérable, le même vecteur peut réinfecter immédiatement après restauration. Le contrôle d’intégrité doit donc s’inscrire dans une stratégie plus large, mais il reste une brique centrale.
D’abord: figer la situation avant de “nettoyer”
Si vous pouvez encore accéder à l’admin, commencez par ralentir les actions “destructrices”. Modifier des fichiers et relancer des scans trop tôt peut effacer des indices utiles. Sur un incident réel, j’ai déjà vu des équipes remplacer immédiatement des fichiers suspects, puis perdre la version exacte de ce qui avait été injecté. Résultat, la cause racine restait introuvable.
Concrètement, prenez quelques mesures de bon sens:
- Faites une copie complète du répertoire WordPress sur votre machine (et idéalement un snapshot côté serveur). Relevez la version WordPress en place, ainsi que la liste des plugins et des thèmes chargés. Notez les changements récents: mise à jour, ajout de plugin, changement d’hébergement, modification de droits, mise en place de Cloudflare ou d’un proxy, etc.
Le but n’est pas d’être “parfait”, mais d’avoir un point de comparaison solide. Sans ça, la “vérification d’intégrité” ressemble vite à une chasse aux fantômes.
Repérer les signes faciles, sans confondre avec le normal
Avant même de comparer des hash ou d’inspecter ligne par ligne, il faut observer. Certains signes sont fréquents dans un site WordPress infecté, mais ils ne sont pas exclusifs à la compromission. Par exemple, des fichiers nouveaux dans le répertoire racine peuvent être légitimes, si vous utilisez un outil de déploiement, un framework, ou une fonctionnalité de cache.
Voici des signaux qui méritent d’être examinés de près:
- Erreurs 500 ou comportements incohérents qui apparaissent après une modification invisible. Redirections vers des domaines inconnus, parfois uniquement pour certains navigateurs ou pour des chemins précis. Tentatives d’exécution inattendues via des fichiers PHP dans des emplacements qui ne devraient pas en contenir. Création d’utilisateurs WordPress que vous ne reconnaissez pas, ou comptes avec des rôles élevés. Multiplication de fichiers dans wp-content, surtout s’ils contiennent du PHP, du code obfusqué, ou des noms “tombés du ciel”.
Cette étape sert surtout à prioriser. Si rien ne “semble” anormal, vous ne gagnerez pas de temps à ignorer la vérification d’intégrité. Mais vous pourrez concentrer vos comparaisons là où le risque est le plus probable.
Construire une base de comparaison fiable
Pour vérifier l’intégrité, il faut un référentiel. Or WordPress évolue: une mise à jour mineure change des fichiers du noyau. Donc la comparaison doit être cohérente avec la version exacte.
Le référentiel peut venir de plusieurs sources, selon votre niveau d’exigence:
- Le package officiel correspondant à la version installée. Un déploiement “connu sain” si vous l’avez encore (par exemple un snapshot pris avant incident). Une copie de l’état “avant” sur un environnement de test, si votre CI ou vos procédures de staging conservent des artefacts.
Le point clé: ne comparez pas votre code à une autre version “à peu près”. Les faux positifs sont fréquents, et vous risquez de restaurer des fichiers qui n’étaient pas le problème.
Vérifier les fichiers du noyau WordPress (wp-core)
Les fichiers du noyau sont le meilleur point de départ, parce qu’ils sont relativement stables et qu’ils n’ont aucune raison d’être personnalisés dans un site standard.
L’idée consiste à comparer les fichiers du répertoire WordPress (hors wp-content et hors wp-config.php pour lequel on doit être prudent) avec le package de référence de la version correspondante.
Techniquement, on cherche à répondre à deux choses: “est-ce le bon contenu” et “est-ce le bon ensemble de fichiers”. Sur le terrain, une modification unique dans le noyau ou un fichier supplémentaire placé au mauvais endroit peut suffire à provoquer des effets en chaîne.
Pour cette vérification, vous pouvez procéder de différentes manières, en fonction de ce que vous avez le droit de faire sur le serveur:
- Comparaison par checksum (hash) fichier par fichier, entre votre instance et la version de référence. Comparaison par diff (différence de contenu) pour les fichiers qui ne matchent pas. Contrôle des dates de modification (mtime) et des tailles, comme signal préliminaire.
Le piège ici est la lenteur: comparer tout peut être long sur de gros sites. Mais comme le noyau reste généralement limité, vous pouvez déjà gagner beaucoup de temps en priorisant wp-core.
Inspecter wp-config.php et les chemins d’accès sensibles
Le fichier wp-config.php est un cas particulier. Il contient des identifiants, des constantes, des paramètres de sécurité, et parfois des définitions d’accès. Un malware ne modifie pas forcément ce fichier, mais quand il le fait, c’est souvent en modifiant des constantes ou en ajoutant du code.
Plutôt que de tenter une restauration “aveugle”, traitez wp-config.php comme une pièce maîtresse à analyser attentivement:
- Vérifiez toute logique PHP ajoutée en plus des paramètres attendus. Contrôlez les variables qui n’ont pas de raison d’exister dans votre configuration normale. Inspectez la présence de fonctions, d’instructions conditionnelles ou de code qui lit des fichiers externes.
Un code obfusqué ou une portion de script en bas de fichier est un indice typique. Même si vous n’avez pas le “bon” wp-config.php sous la main, la comparaison au vôtre habituel (si vous avez une version de staging ou un backup) reste la méthode la plus fiable.
wp-content: là où l’infection se cache le plus souvent
Dans WordPress, le noyau bouge peu, mais wp-content vit au quotidien. Les uploads changent, les thèmes et plugins aussi, et de nombreux systèmes ajoutent des fichiers (cache, compilations, optimisations).
Justement, c’est pour cela qu’il faut être méthodique. Une infection dans wp-content peut être un plugin “modifié”, un thème “tordu”, ou un fichier ajouté dans un sous-répertoire inattendu.
Une démarche pragmatique consiste à scinder wp-content en zones:
- plugins: comparer chaque plugin installé contre une version de référence et repérer les fichiers nouveaux ou modifiés. themes: idem, mais avec plus de prudence si vous utilisez un thème enfant, des builders, ou des variantes. uploads: ici, on ne cherche pas le “code du noyau”. On cherche des fichiers PHP exécutables, des scripts, des fichiers texte contenant des charges utiles, et des archives suspectes.
Un point important: beaucoup d’attaques passent par des fichiers qui ne font rien “à l’œil nu” tant qu’une condition n’est pas réunie, par exemple une requête sur une URL spécifique ou l’utilisation d’un paramètre GET.
Contrôler les signatures d’accès et les fichiers récemment changés
Même sans vous lancer dans des hash sur tout le disque, vous pouvez obtenir une première cartographie. Les fichiers récemment modifiés sont souvent liés à l’incident. Sur un serveur chargé, ces dates peuvent être trompeuses (deux fichiers changent tous les jours à cause d’un outil), mais c’est un signal.
L’approche que j’aime bien consiste à:
- repérer les fichiers qui ont changé autour du moment suspect, vérifier si ces changements concernent du code exécutable (PHP) dans des répertoires où vous n’attendez pas ce genre de choses, et croiser avec vos logs, quand ils existent.
Si vous avez accès aux logs web et aux logs PHP-FPM/Apache, vous pouvez chercher des accès à des fichiers rares, des erreurs spécifiques, ou des patterns d’exécution. Ce n’est pas “la preuve”, mais c’est un aiguillage très utile avant d’ouvrir des dizaines de fichiers.
Les indicateurs dans le code: ce que vous cherchez vraiment
Quand vous https://gardewp.fr/nettoyage-malware-wordpress/ ouvrez un fichier suspect, ne vous contentez pas de chercher des mots “malware”. Les attaques modernes savent se déguiser.
Ce qui est souvent révélateur dans le code injecté:
- Des inclusions dynamiques, du type inclure un fichier dont le nom dépend d’un paramètre. Des fonctions de lecture/écriture de fichiers ou d’exécution systèmes, surtout si elles ne sont pas nécessaires à votre plugin. De l’obfuscation, des fragments encodés (base64 par exemple), ou des chaînes longuement concaténées. Des requêtes réseau inattendues, ou des comportements conditionnels basés sur l’agent utilisateur, l’IP, ou la langue. Des zones PHP “qui ne devraient pas exister” dans un plugin ou un thème, par exemple un bloc de code ajouté à la fin pour servir un comportement caché.
Le jugement humain compte ici. Un plugin de cache peut modifier des fichiers, un builder peut générer du code dans un dossier, un thème enfant peut créer de nouveaux fichiers. Tout cela peut être normal. L’intégrité, c’est précisément la limite entre “génération attendue” et “déviation”.
Choisir entre restauration et réparation
Quand vous constatez une divergence (hash différent, fichier nouveau, code suspect), vous avez deux grandes options:
Restaurer le fichier depuis une version connue saine (ou depuis l’artefact de déploiement). Réparer en supprimant le code injecté, en réappliquant la logique attendue, puis en contrôlant que le comportement revient à la normale.Sur un incident, la restauration est souvent plus sûre pour le noyau, et parfois pour un plugin ou un thème que vous pouvez remplacer proprement. Réparer “à la main” peut être tentant si vous avez des modifications légitimes, mais cela demande d’être sûr de ce qui a été ajouté et pourquoi.
Un compromis fréquent consiste à restaurer d’abord ce qui est “standard” (wp-core), puis à auditer les composants personnalisés (plugins maison, thèmes sur mesure). Si un plugin externe est compromis et que vous n’avez pas le contrôle sur votre code, le remplacement par une version propre est généralement la voie la plus simple.
Procédure de vérification: une méthode réaliste (sans se perdre)
Voici une façon de faire qui tient compte du temps, du stress, et des contraintes d’accès.
Étape 1: inventorier l’état actuel
Listez les versions de WordPress, les plugins et thèmes actifs, et vérifiez si vous avez un environnement de staging ou un dernier backup complet. Cette photographie doit être cohérente avec la période suspecte.
Étape 2: vérifier wp-core en priorité
Comparez les fichiers du noyau à une référence correspondant à la version installée. Si des fichiers changent, vérifiez le contenu. Si vous devez restaurer, restaurer wp-core ne devrait pas casser vos contenus, à condition de ne pas toucher à wp-content et à wp-config.php avec désinvolture.
Étape 3: analyser wp-config.php et les chemins de chargement
Ouvrez le fichier, contrôlez le code ajouté, et examinez si des constantes ou des inclusions ont été modifiées. Dans beaucoup de cas, si wp-config.php est clean mais que wp-content ne l’est pas, le malware est ailleurs.
Étape 4: passer à wp-content, plugin par plugin
Là, https://gardewp.fr/ vous avez un choix: soit comparer chaque plugin à sa source propre, soit au minimum analyser ceux modifiés récemment, ceux qui sont sensibles (plugins d’éditeur, de formulaire, de partage, d’optimisation), ou ceux installés juste avant l’incident.
Étape 5: traiter uploads avec méthode
Dans uploads, le risque typique, ce sont des fichiers exécutables ou des scripts déposés. Les médias images ou vidéos sont normaux. Mais si vous voyez un fichier PHP, un script, une archive “bizarre” ou des noms générés au hasard, c’est un signal.
Pour ne pas vous éparpiller, gardez une règle simple: tout fichier nouveau ou modifié que vous ne pouvez pas expliquer doit être soit justifié par un processus, soit supprimé et remplacé par un état sain.
Checklist d’intégrité rapide (utile dès les premières heures)
- Copier le site (au minimum wp-content et les fichiers racine), avant toute modification Vérifier wp-core contre une référence de la version exacte Contrôler wp-config.php: code ajouté, inclusions, constantes suspectes Inspecter plugins et thèmes modifiés récemment ou récemment installés Rechercher des fichiers exécutables dans wp-content/uploads (et les traiter comme prioritaires)
Cette checklist ne remplace pas l’analyse, mais elle évite de partir dans toutes les directions.
Une méthode de comparaison plus “sûre” que la simple observation
L’observation visuelle aide, mais quand vous voulez être rigoureux, les checksums et les diffs sont plus solides. Le principe est simple: pour chaque fichier, vous comparez votre état à une version attendue.
Le choix entre checksum et diff dépend de votre environnement:
- Le checksum est rapide pour repérer “quoi” a changé. Ensuite, vous ouvrez uniquement les fichiers qui diffèrent. Le diff est utile pour comprendre “comment” un fichier a été modifié, surtout si vous devez décider entre réparation et restauration.
Si vous n’avez pas de procédure outillée, faites au moins une comparaison structurée sur wp-core puis sur les plugins actifs. Une comparaison complète de tout le disque peut être longue, mais une comparaison ciblée, bien choisie, donne souvent 80 pour cent du diagnostic.
Cas particuliers qui compliquent l’analyse
Tous les incidents ne se ressemblent pas, et c’est là que la vérification d’intégrité doit rester pragmatique.
Site avec déploiement continu
Si votre organisation a un pipeline qui compile des assets et génère des fichiers, vous verrez des modifications régulières. Dans ce contexte, vous devez comparer avec vos artefacts attendus, sinon vous allez confondre build normal et injection.
Thème enfant et modifications légitimes
Un thème enfant peut ajouter des fonctions PHP, des overrides, ou des fichiers supplémentaires. Vous ne pouvez pas exiger que le thème corresponde à un état “vierge”. Il faut vérifier que ce qui a changé est cohérent avec vos commits ou vos releases.
Plugins qui modifient des fichiers
Certains plugins éditent des fichiers, par exemple pour optimiser, minifier, ou écrire des caches. Si vous supprimez ces fichiers sans comprendre, vous pouvez provoquer des erreurs de fonctionnement. Dans ce cas, l’intégrité doit être interprétée avec le cycle de vie de vos plugins.
Compromission “dans la durée”
Une infection peut aussi être une compromission de compte ou une porte dérobée persistante. Vous restaurerez les fichiers, mais un script déclenche une réinfection. C’est un scénario classique quand un attaquant conserve un mécanisme d’exécution. D’où l’importance de coupler l’intégrité des fichiers avec la vérification des comptes, des tâches planifiées, et des paramètres de sécurité.
Vérifications complémentaires, souvent indispensables
Vérifier l’intégrité des fichiers est central, mais je recommande presque toujours un contrôle additionnel, parce que la cause racine n’est pas forcément un fichier modifié dans le webroot.
Voici les points à garder en tête:
- présence d’utilisateurs WordPress inconnus modifications des rôles ou des comptes ajout de tâches planifiées (selon votre configuration) paramètres de sécurité et réglages qui ont bougé après l’incident
Sur certains serveurs, les injections ne touchent pas beaucoup les fichiers, mais elles altèrent l’accès ou la logique d’exécution via un point d’entrée. Si vous ne contrôlez pas ces zones, vous risquez de restaurer le bon code, puis de laisser l’attaquant “appuyer sur le bouton” dès le prochain cycle.
Checklist de décision: quoi faire quand ça ne colle pas
- Si wp-core est modifié: restaurer et re-scanner immédiatement Si un plugin ou thème est modifié: remplacer par une version propre quand c’est possible Si uploads contient du code exécutable ou des scripts: supprimer et vérifier les chemins d’accès Si wp-config.php est suspect: corriger et vérifier que l’accès aux identifiants n’a pas été compromis Si la réinfection se produit après restauration: cherchez une persistance ailleurs (comptes, tâches, point d’entrée)
Cette grille aide à ne pas tourner en rond quand vous avez plusieurs divergences à la fois.
Après la restauration: tester l’intégrité, mais aussi le comportement
Une fois que vous avez restauré ce qui était incorrect, ne vous arrêtez pas à “les fichiers semblent bons”. Sur un site qui vient d’avoir un problème, le comportement vaut preuve:
- Vérifiez des pages “normales” et des pages sensibles. Testez des formulaires ou des actions d’authentification. Surveillez les logs pendant un intervalle raisonnable, surtout si le site était silencieux avant l’incident.
Si l’injection a été déclenchée par une condition spécifique (certaines URLs, certains paramètres), le comportement anormal peut réapparaître seulement dans des cas particuliers. C’est là que les comparaisons d’intégrité gagnent encore de la valeur, parce qu’elles servent de repère pour re-scanner sans perdre de temps.
Sécuriser le futur pour éviter que la vérification ne soit qu’une routine
Régler l’incident n’est pas suffisant si les mêmes portes restent ouvertes. Les causes fréquentes sont, par exemple, des plugins obsolètes, des thèmes ou plugins non maintenus, des comptes faibles, et des mots de passe réutilisés.
Une fois votre site WordPress infecté assaini, vous pouvez réduire fortement le risque en procédant avec méthode:
- mettez à jour ce qui peut l’être, sans sauter dans le vide limitez les droits et les accès verrouillez les comptes admin et supprimez les comptes non reconnus contrôlez les droits sur les fichiers et répertoires pour réduire la surface d’écriture
Je privilégie toujours les changements qui n’ajoutent pas de complexité inutile. Une sécurité efficace, c’est celle qui résiste aux jours “ordinaires”.
Ce que j’ai appris en traitant ce genre d’incident
Il y a une vérité pratique que j’ai vue se répéter: la vérification d’intégrité n’est pas une fin en soi, c’est une manière de retrouver le contrôle.
Quand on se contente d’installer un “nettoyeur” ou de supprimer au hasard, on peut atténuer les symptômes, mais on laisse souvent une cause persistante. À l’inverse, quand on compare wp-core à une référence, qu’on audite wp-config.php, puis qu’on examine plugins, thèmes et uploads avec logique, on produit des décisions plus propres: restauration, remplacement, suppression ciblée.
Et surtout, on apprend comment l’attaque s’est branchée sur votre site. Cette connaissance vaut plus que la suppression du symptôme.
Un dernier mot sur le rythme et la rigueur
Un audit d’intégrité peut paraître intimidant, surtout sur des sites très personnalisés. Pourtant, il fonctionne mieux quand il est progressif: wp-core d’abord, puis les points de configuration, puis wp-content là où le risque est le plus élevé. Si vous gardez des copies, des comparaisons cohérentes avec la version exacte, et une logique de décision claire, vous évitez le scénario classique de “on a nettoyé, mais on ne sait pas ce qui est revenu”.
Si vous voulez, décrivez votre situation (version de WordPress, accès admin possible ou non, plugins installés, existence de logs, et ce que vous observez), et je vous proposerai une stratégie de vérification plus ciblée, adaptée à votre cas, pour minimiser les faux positifs et accélérer le diagnostic.