WordPress est devenu un standard, et justement pour cette raison, il attire autant l’attention des attaquants que des équipes sécurité. Quand un site commence à se comporter “bizarrement”, la tentation est de tout mettre à jour, puis d’attendre que ça se passe. Sur le terrain, ça marche parfois. Souvent, ça ne fait que déplacer le problème, ou masquer la cause derrière des mises à jour successives.
L’approche qui tient le mieux consiste à auditer ce qui touche le navigateur et le moteur du site, autrement dit les thèmes et les plugins. Dans cette démarche, le scanner malware WordPress peut être un bon point de départ, mais il ne remplace pas un audit “manuel” des éléments exposés et des signaux faibles. L’objectif n’est pas d’accuser à tort un développeur, c’est de réduire la surface d’attaque, de comprendre la logique du compromis, puis d’agir avec une méthode reproductible.
Les signes qui orientent l’audit vers thèmes et plugins
Avant même d’ouvrir l’espace d’administration ou de lancer un scan, j’aime fixer des hypothèses à partir des symptômes observés. Ça évite de partir dans tous les sens.
Un malware sur WordPress ne se limite pas à “un fichier binaire dans /wp-content”. Il peut aussi prendre la forme d’une porte dérobée via un plugin, d’un script inséré dans le thème, ou d’un chargeur qui modifie des pages ciblées. Des indices concrets reviennent régulièrement :
- redirections inattendues, surtout depuis certaines pages ou catégories apparition de liens sponsorisés dans le contenu, parfois masqués au lecteur mais visibles dans le code comportements différents selon l’agent utilisateur, ou selon le pays, ou même selon le navigateur augmentation du trafic sortant, des requêtes à des domaines inconnus, ou des appels à des endpoints étranges dans les fichiers JavaScript échecs de mises à jour, avertissements d’intégrité, ou déploiement “fantôme” de fichiers après un update modification du thème actif sans intervention humaine, ou surcouche CSS/JS qui n’était pas là avant
Sur un site client, j’ai déjà vu le cas où la page d’accueil semblait normale, puis une minorité d’utilisateurs tombait sur une redirection dès qu’ils accédaient à une URL de type /?p=123. Le scanner a signalé “quelque chose dans /wp-content/plugins”, mais ce qui a vraiment orienté vers le coupable, c’est l’analyse du code source rendu, et la comparaison des timestamps de modification entre dossiers.
Pourquoi le thème et les plugins sont un levier privilégié
Un thème et un plugin sont des “extensions” de WordPress. Ils reçoivent l’exécution côté serveur (PHP), ils influencent le rendu (HTML, CSS, JS), et ils peuvent aussi déclencher des actions planifiées (cron), des hooks, des appels distants.
En pratique, un attaquant préfère rarement attaquer le noyau WordPress lui-même, car il est plus surveillé et plus facile à remplacer. Il s’en sort mieux en :
- ajoutant du code à un plugin rarement mis à jour modifiant le thème actif via des fichiers inclus ou des templates spécifiques exploitant une fonction d’upload ou une fonctionnalité “éditeur de fichier” mal contrôlée abuse d’un plugin de formulaires, d’un plugin SEO, ou d’un outil de newsletter, parce qu’ils importent et traitent des données
L’audit consiste donc à mesurer la confiance que vous accordez à chaque composant, puis à vérifier ce que le site exécute réellement, pas seulement ce qui est affiché dans l’interface.
Première étape pragmatique : cartographier ce qui tourne
L’interface WordPress donne une vue d’ensemble, mais elle est parfois trompeuse si l’attaquant a modifié des fichiers de configuration ou utilisé un chargement conditionnel.
Commencez par une cartographie simple et cohérente :
- listez les plugins installés, leur version, et la date approximative d’installation si vous l’avez dans vos logs notez le thème actif et tous les thèmes présents, même ceux qui ne sont pas actifs vérifiez les utilisateurs disposant de droits élevés (administrateurs, éditeurs), et repérez les comptes créés récemment inspectez les fichiers générés ou modifiés récemment dans /wp-content, notamment plugins, themes et uploads
Ce travail peut sembler fastidieux, mais il devient une référence pour ensuite juger “quoi vérifier” et “quoi ne plus toucher”. Sur un site où plusieurs plugins avaient été bricolés par le passé, cette cartographie m’a évité de refaire l’enquête à chaque redirection.
Utiliser un scanner malware WordPress sans se laisser hypnotiser
Un scanner malware WordPress est utile pour gagner du temps, surtout quand vous partez d’un doute. Il peut repérer des signatures, des schémas typiques, ou des anomalies de structure dans les fichiers.
Mais il y a trois pièges fréquents.
D’abord, les faux positifs. Un plugin légitime peut contenir des fragments ressemblant à des patterns malveillants, parce qu’il génère du code, charge des bibliothèques, ou utilise des obfuscations.
Ensuite, l’angle mort. Certains malwares ne se déclenchent qu’après une condition (requête avec un paramètre, heure précise, présence d’un cookie), ou s’appuient sur des fonctions exécutées dynamiquement. Un scan “à l’aveugle” peut manquer le déclencheur.
Enfin, la paresse. Si vous remplacez des fichiers “sans comprendre”, vous risquez de casser le site, ou pire, de laisser persister un autre composant contaminé.
Mon conseil est simple : traitez le scanner comme un radar. Il vous indique des zones à inspecter. L’enquête continue ensuite par lecture du code, vérification de l’intégrité, et comparaison avec une version attendue.
Audit ciblé des plugins : où regarder en premier
Quand je teste l’hypothèse “plugin à risque”, je ne commence pas par lire tout le code. Je commence par chercher des signaux qui, en général, ne mentent pas.
Dans les plugins, les zones que j’examine en priorité sont :
- le fichier principal du plugin, et tous les fichiers inclus depuis celui-ci toute trace de chargement dynamique de fichiers, d’exécution de chaînes, ou d’appel réseau depuis PHP l’existence de fichiers supplémentaires “inattendus” dans le dossier du plugin, comme des .php ajoutés, des .txt contenant du code, ou des fichiers avec des noms qui ressemblent à des outils (cache, logs, class, include) les modifications de fonctions WordPress classiques via hooks, surtout si le hook vise wp head, wpfooter, ou le rendu de contenu la présence de fichiers obfusqués, chaînes base64, gzinflate, str rot13, eval, assert, pregreplace avec /e (quand c’est encore possible), ou appels à des fonctions d’exécution
Ce tri rapide permet de repérer des comportements typiques : injection de scripts en frontal, collecte d’informations, ou chargement de chargeurs distants.
Sur plusieurs cas récents, ce qui a tranché n’était pas “un fichier corrompu” évident, mais un plugin qui semblait normal à l’œil nu, puis dont une branche de code n’était active que sur une condition de type “si l’URL contient telle chaîne” ou “si l’utilisateur n’a pas tel rôle”. Sans lecture ciblée, impossible de le voir.
Vérifier les chargements côté navigateur
Un malware orienté SEO spam ou redirection affiche souvent le payload en JavaScript. Pour repérer ça sans tout casser, vous pouvez :
- inspecter le code HTML rendu pour voir quels scripts sont ajoutés comparer le code rendu “avant et après” sur une machine de test vérifier les requêtes réseau déclenchées au chargement de pages suspectes
Le point important : ne vous contentez pas de regarder la page affichée. Regardez la page source, puis les scripts réellement chargés. Un plugin peut inclure un fichier JS qui ressemble à un simple utilitaire, mais qui appelle un endpoint de commande distant.
Audit ciblé des thèmes : ce qui trahit une compromission
Le thème est souvent un terrain de compromis parce qu’il contrôle les hooks de rendu. Les attaquants peuvent injecter un code dans header, footer, ou via des fonctions comme wp enqueuescripts, get header, getfooter.
Dans les thèmes, je regarde surtout :
- les fichiers situés à la racine du thème (par exemple functions.php) et les fichiers inclus automatiquement la présence de scripts PHP “bizarres” qui ne correspondent pas au thème (obfuscation, longues chaînes, fonctions d’exécution) les hooks liés à wp head et wpfooter, surtout s’ils contiennent des envois de contenu à l’écran ou des inclusions conditionnelles l’ajout de fichiers dans des dossiers non habituels du thème, comme des sous-dossiers non standards, ou des templates inconnus
Un exemple concret : un thème premium “normal” a fini par injecter un fragment de code après une mise à jour partielle faite par quelqu’un de l’agence. Le thème ne prenait pas la main systématiquement, seulement sur certaines pages. Le scanner a signalé un plugin, mais la véritable injection se faisait via le thème. Le plugin était “juste” utilisé pour créer un cron et pousser une version modifiée du thème, ce qui rendait l’enquête trompeuse.
Leçon : ne vous focalisez pas sur le premier signal. Cherchez la chaîne logique.
Comparer les versions : l’approche la plus fiable quand vous avez une référence
Si vous avez un historique fiable du site (backup propre, copie de la version connue, export de plugin depuis un environnement contrôlé), la comparaison devient très puissante.
L’idée est de comparer :
- le contenu d’un dossier de plugin ou de thème suspect avec une version attendue les timestamps de modification des fichiers du composant la présence de nouvelles inclusions (include, require) pointant vers des fichiers qui n’étaient pas là
Dans un contexte d’entreprise, on peut aussi récupérer les artefacts exacts depuis un registre interne ou depuis une copie git si vous versionnez vos déploiements.
Si vous n’avez pas de référence, vous pouvez quand même comparer avec une source officielle (site du développeur, dépôt du plugin, zip publié) mais il faut rester prudent, car une version légitime peut différer légèrement selon la configuration ou l’architecture de packaging.
Détection des comptes et droits, même si la question porte sur thèmes et plugins
Même si votre sujet est “auditer thèmes et plugins à risque”, je ne recommande pas d’ignorer l’administration.
Pourquoi ? Parce qu’un malware s’installe souvent grâce à un accès initial. Si un attaquant a un compte admin, il peut modifier le thème, installer un plugin, ou injecter du code depuis l’éditeur de fichiers ou d’autres fonctionnalités.
Avant de conclure, vérifiez :
- la création récente d’utilisateurs l’existence de rôles inhabituels des actions planifiées (cron) dont vous ne connaissez pas la provenance des modifications de paramètres, notamment ceux liés aux autorisations
C’est aussi une façon de valider vos hypothèses. Un plugin peut sembler suspect, mais si un utilisateur a modifié le thème “juste après” que son compte a été créé, la chronologie devient un indice solide.
Méthode d’audit en pratique, sans casser le site
Je vous propose une démarche raisonnable, orientée “investigation” plutôt que “réparation aveugle”. L’objectif est de limiter le temps d’arrêt tout en gagnant en certitude.
Checklist d’investigation (avant toute suppression)
- Faire une sauvegarde complète, base de données comprise, et conserver une copie des dossiers wp-content concernés Activer un environnement de test, ou au minimum bloquer l’accès public pendant l’analyse si le risque d’affichage est élevé Lancer un scanner malware WordPress pour repérer les fichiers et comportements probables, puis noter les chemins signalés Comparer les fichiers modifiés récemment dans wp-content avec une version attendue ou un backup propre Répertorier les hooks et inclusions dans le thème actif et les plugins suspects (wp head, wpfooter, enqueue, includes PHP)
Cette séquence évite de supprimer un fichier trop tôt, ce qui rend ensuite impossible de comprendre la logique du compromis.
Isoler le coupable : désactiver sans aveuglement
Une fois les composants suspectés, l’isolation est souvent la méthode la plus rentable. Mais l’important est de désactiver dans un ordre qui vous informe, pas seulement dans un ordre qui “arrête le symptôme”.
Si vous désactivez tout, vous perdez la possibilité d’apprendre. Si vous désactivez un seul plugin, vous risquez de ne voir aucune amélioration si le thème reste la source d’injection.
L’approche que j’utilise le plus :
- désactiver d’abord les plugins qui ont été le plus fortement signalés par le scan et qui ont un accès large au rendu tester sur les pages qui montraient le problème si ça persiste, investiguer le thème actif, puis le chaînage (inclusions du thème vers d’autres fichiers)
Quand un site a beaucoup de dépendances, il est parfois nécessaire de couper un plugin “moteur” pour retrouver la stabilité, puis de revenir étape par étape.
Petit repère de priorité
Je classe souvent les composants à risque selon trois axes, pas seulement la notoriété du plugin :
- capacité à injecter du code dans le rendu (front-end) capacité à exécuter du PHP dynamique, à importer des contenus, ou à déclencher des tâches planifiées historique de maintenance et réputation technique (mais sans conclure uniquement sur “c’est populaire donc sûr”)
Quand le malware n’est pas dans le code “principal”
Parfois, le malware n’est pas dans le fichier principal qui attire l’œil. Il se cache dans :
- des fichiers inclus indirectement des assets dans le dossier uploads (même si ce n’est pas “thème/plugin” au sens strict, ils peuvent porter un payload) des dossiers créés après coup dans wp-content des références à des scripts hébergés ailleurs
C’est pour ça qu’un audit “juste sur le plugin principal” peut échouer. Vous devez suivre les inclusions. Si un fichier appelle require_once sur un chemin étrange, ouvrez ce chemin. Si un fichier JS injecté fait un appel réseau vers un domaine non familier, remontez la chaîne côté serveur pour savoir comment ce script a été introduit.
Scénarios fréquents, et comment ne pas se tromper
Il y a plusieurs scénarios qu’on rencontre souvent, et chacun impose un raisonnement.
Le plugin semble coupable, mais le thème injecte réellement
Le cas le plus piégeux : un plugin sert de déclencheur, puis le thème ajoute le code en frontal via un hook. Un scanner signale le plugin car il contient le “mécanisme”, mais le symptôme visuel vient du thème.
Dans ce scénario, ce n’est pas “qui a mis le code”, c’est “qui a déclenché l’injection du rendu”.
Le plugin a été “installé” sans installation classique
Parfois, on voit un plugin qui apparaît installé, mais le processus d’installation ne correspond pas à ce qui a été fait. Ça peut venir d’un script de persistance.
Je fais alors deux vérifications : la présence de fichiers nouveaux et les modifications du dossier sur une période cohérente avec l’apparition du problème. Si tout s’est produit en une seule fenêtre, vous avez un indice fort.
Le code est propre, mais les comportements restent
Dans ce cas, le malware peut être ailleurs : cache, CDN, un script modifié dans un niveau supérieur, un proxy injecteur, ou une configuration serveur altérée.
Cela arrive quand le scanner signale quelque chose de plausible, mais qu’une fois le fichier supprimé et remplacé, le comportement persiste.
Ici, il faut accepter le fait que “le symptôme” n’est pas forcément “à l’endroit signalé”.
Réparer sans créer une nouvelle faille
Quand vous trouvez un composant compromis, la réparation n’est pas toujours “supprimer puis finir”. Souvent, il faut éviter de réinfecter le site en remettant un fichier contaminé depuis un ancien backup, ou en réinstallant un plugin modifié.
Le bon enchaînement est généralement :
- remplacer le composant par une version réputée et vérifiée (zip officiel, copie de référence) purger caches et objets persistants si vous en utilisez vérifier les fichiers de configuration qui pourraient recharger le malware contrôler l’intégrité de la base de données sur les champs suspects (si vous avez injecté des données, elles peuvent être encore présentes)
Il y a un équilibre à trouver entre vitesse et rigueur. Sur un site vitrine, on peut parfois restaurer rapidement, surveiller, puis affiner. Sur un site e-commerce, je préfère une approche plus lente, avec analyse des logs et vérification plus structurée.
Sécurité autour de l’éditeur et des droits, pour empêcher la persistance
Les thèmes et plugins ne sont pas seulement des victimes, ils sont aussi des voies d’attaque persistante si vos protections sont faibles. Deux exemples concrets que j’ai vus :
- des droits trop larges pour des comptes qui n’en avaient pas besoin l’accès à des fonctionnalités permettant l’édition de fichiers ou l’exécution de code sans contrôle
Vous n’avez pas besoin de “verrouiller tout” de manière brutale, mais vous devez réduire les chemins qui permettent à un attaquant de revenir.
Mes garde-fous à ce stade
- limiter les rôles éditeurs et administrateurs aux personnes qui en ont besoin vérifier que l’éditeur de fichiers et les fonctionnalités à risque sont correctement encadrés surveiller les comptes créés récemment et les connexions anormales mettre en place une rotation de mots de passe si un accès a été compromis contrôler les jobs planifiés et les plugins de type “automatisation” ou “import”
C’est moins spectaculaire qu’un script malveillant découvert, mais c’est souvent ce qui fait la différence entre un incident ponctuel et une récidive.
Par où commencer si vous devez prioriser rapidement
Si vous êtes dans une situation d’urgence, la question devient : “qu’est-ce que je fais en premier pour stopper le risque de façon raisonnable”.
Voici une logique de triage, que j’ai vue fonctionner sur des sites de taille variée :
- Si les symptômes sont visibles (redirections, injection de scripts), ciblez d’abord le thème actif, puis les plugins qui touchent le rendu (SEO, optimisation, page builder, formulaires, caches). Si les symptômes sont intermittents ou liés à des URLs spécifiques, suivez les inclusions conditionnelles et inspectez la logique de chargement dans les plugins signalés. Si vous avez un historique de versions ou un backup propre, comparez en priorité les dossiers modifiés récemment plutôt que ceux listés “à risque” sur le papier.
Ce triage vous évite la chasse aux sorcières. Vous ne cherchez pas “le plugin le plus suspect”, vous cherchez “le mécanisme qui produit le comportement observé”.
Contrôles complémentaires : logs et analyse de domaines
Même sans avoir accès à des outils lourds, des vérifications simples peuvent donner des réponses très rapides.
Regardez les logs applicatifs et web serveur si vous y avez accès. Cherchez :
- des erreurs PHP répétées liées à des fichiers de plugins ou thèmes des requêtes sortantes inattendues, ou des appels à des endpoints non familiers des pics de requêtes sur des URLs qui ne correspondent pas à vos usages des traces d’accès à des pages d’administration par des IP inhabituelles
Pour les domaines, je privilégie une approche prudente. Un domaine peut être légitime si un plugin de newsletter ou d’analytics l’utilise. Le point n’est pas “nouveau domaine = malware”. Le point est “nouveau domaine + contexte anormal + mécanisme d’injection”.
Edge cases qui compliquent l’audit
Quelques cas atypiques méritent une attention particulière.
- Plugins qui générent du code de façon légitime mais qui ressemble à de l’obfuscation. Un audit doit distinguer génération de métadonnées, minification et exécution dynamique dangereuse. Thèmes enfants (child theme) dont la configuration est saine, mais dont le fichier de thème parent a été modifié. Vous devez vérifier la chaîne complète, pas seulement le fichier que vous éditez. Environnements où une couche supplémentaire intervient, par exemple un cache serveur, un WAF, ou une intégration CDN qui peut injecter ou modifier du contenu. Le malware peut être côté distribution, pas uniquement côté application. Plugins “proches de l’écosystème” qui importent des contenus distants. Si le plugin charge des scripts depuis l’extérieur, il faut vérifier la provenance et la logique, parce que c’est une porte potentielle.
Ces cas ne se résolvent pas avec un scan. Ils se résolvent avec la lecture du flux, la chronologie, et la comparaison.
Deux décisions difficiles : restaurer un backup ou corriger à la main
La réparation choisie dépend de votre tolérance au risque et de la capacité d’analyse.
Restaurer un backup propre, c’est parfois le chemin le plus sûr, surtout si vous avez un point de restauration proche du moment où tout allait bien. La contrepartie, c’est que vous perdez des changements légitimes récents, et vous devez vérifier qu’aucun élément persistant ne revient après restauration.
Corriger à la main, ça marche quand vous avez identifié précisément les fichiers et la logique du compromis. La contrepartie, c’est que sans une analyse rigoureuse, vous pouvez laisser une pièce maîtresse active ailleurs.
Dans un environnement où le site a été “touché”, mais que vous ne savez pas exactement quand, je préfère souvent une stratégie hybride : restaurer pour stopper l’exposition, puis investiguer sur la copie pour comprendre ce qui revient. Ça vous donne à la fois sécurité immédiate et apprentissage.
Ce que j’attends d’un audit “bon niveau” (et comment le juger)
Un audit utile ne se contente pas de dire “fichier X est dangereux”. Il doit répondre à trois questions :
- Quel composant est à l’origine de l’injection, et à quel moment du cycle WordPress ? Comment le site charge le code malveillant, via quel mécanisme concret ? Comment éviter la persistance, que ce soit via droits, cron, hooks ou configuration ?
Si un diagnostic ne répond qu’aux deux premières sans traiter la persistance, l’incident a de grandes chances de revenir.
Pour juger la qualité du travail, je regarde aussi la cohérence entre la chronologie et les modifications de dossiers. C’est souvent là que les erreurs apparaissent.
Mini check final, avant de remettre en ligne
Une fois les actions faites, ne relancez pas le site https://gardewp.fr/ “juste parce que ça a l’air mieux”. Prenez cinq minutes pour valider.
- tester les pages qui montraient le problème, avec deux navigateurs différents vérifier le code source rendu, notamment scripts en haut et en bas de page contrôler les requêtes réseau déclenchées au chargement vérifier qu’aucun plugin/thème suspect n’a été réinstallé ou recréé surveiller les logs quelques heures, surtout les accès administration et les erreurs PHP
Ce contrôle final évite la situation où le site “semble propre”, mais où un déclencheur conditionnel revient après un certain délai.
Conclusion pratique, sans promesse magique
Scanner malware WordPress est un outil utile, mais il ne remplace pas l’audit des thèmes et des plugins à risque, ni l’analyse de la logique d’injection. L’attaque se joue souvent dans les hooks, les inclusions indirectes, les conditions d’activation et la persistance via des droits ou des tâches planifiées.
Si vous retenez une idée, ce serait celle-ci : l’audit doit être une enquête, pas un tir au hasard. Le bon rythme, c’est celui qui combine scanner pour pointer, lecture pour comprendre, comparaison pour vérifier, puis contrôle pour empêcher le retour.
Si vous voulez, je peux aussi vous proposer une grille d’inspection pour vos thèmes et plugins basée sur vos symptômes (redirection, injection de scripts, spam SEO, pages ciblées). Donnez-moi le type de comportement observé, et si vous avez accès aux logs ou à un backup avant l’incident.