Quand une installation WordPress “fait quelque chose de louche”, on pense d’abord à la porte d’entrée. Le problème, c’est que les symptômes restent souvent flous. On voit un trafic bizarre, des redirections vers des domaines inconnus, des pages qui ne correspondent plus au contenu attendu, ou juste des erreurs qui apparaissent après une mise à jour. Dans ce genre de situation, la désinfection WordPress ne commence pas par “tout supprimer”, elle commence par une vérification méthodique de l’intégrité des composants, surtout les plugins et les thèmes.
Je l’ai vécu sur plusieurs sites, et chaque fois le même piège revient: croire qu’un plugin ou un thème est “innocent” parce qu’il est ancien, ou parce qu’il n’a pas été mis à jour depuis longtemps. Or une infection peut modifier des fichiers, ajouter des scripts discrets, ou casser la logique d’un hook sans déclencher tout de suite un comportement visible. Vérifier l’intégrité, c’est recoller les morceaux, comprendre ce qui a changé, puis nettoyer sans aggraver.
Le vrai rôle des plugins et thèmes pendant une compromission
WordPress charge énormément de code au démarrage. Un plugin malicieux n’a pas besoin d’être spectaculaire: il peut seulement enregistrer une action supplémentaire, écouter un événement précis, ou altérer une fonction interne. Les thèmes aussi peuvent devenir des vecteurs, notamment quand ils contiennent des fichiers PHP exécutés au rendu, ou des appels à des scripts distants.
Deux conséquences pratiques en découlent.
D’abord, l’infection peut être distribuée. Vous pouvez avoir un “petit” plugin qui ne touche à rien d’important au quotidien, mais qui injecte un chargement JavaScript ou une redirection. Ensuite, l’illusion de stabilité. Si le site semblait normal jusqu’à une date, puis a basculé après un changement mineur, il faut traiter ce changement comme suspect, même s’il a l’air banal dans l’interface.
La désinfection devient alors un travail d’audit. On cherche ce qui a été modifié. On vérifie si l’actif est conforme à sa version attendue. Et, si on ne peut pas garantir l’intégrité, on le remplace plutôt que de “réparer au feeling”.
Identifier ce qui a vraiment changé, sans se perdre
Avant de toucher aux fichiers, j’aime bien cadrer la scène. Sur WordPress, une compromission laisse souvent des traces dans plusieurs endroits: fichiers modifiés récemment, comptes administrateurs créés sans raison, options anormales, et parfois des modifications dans le thème ou le dossier racine. Même si votre focus est l’intégrité plugins et thèmes, ces indices aident à ne pas tourner en rond.
Sur l’inventaire des plugins et thèmes, un point utile est la corrélation temporelle. Si vous remarquez une date d’apparition des symptômes, comparez-la à:
- la dernière mise à jour WordPress, plugin ou thème, un changement de DNS ou de configuration serveur, une installation de plugin “au dernier moment” pour une fonctionnalité.
Je ne parle pas seulement de “quand”. Je parle aussi de “comment”. Un plugin installé depuis des mois mais dont des fichiers ont été modifiés récemment est un signal. Un thème peu utilisé mais dont un fichier template a changé récemment est également un signal. À l’inverse, une mise à jour légitime peut modifier des fichiers, donc il faut éviter la confusion.
Quand j’ai un accès SFTP ou via le gestionnaire de fichiers, je commence presque toujours par relever les dates de modification. Ensuite je confronte à la réalité: un plugin mis à jour via l’interface a des fichiers qui changent. Un plugin infecté peut avoir des fichiers modifiés sans correspondre à un événement “propre”.
Vérifier l’intégrité: le principe, pas seulement l’outil
“Vérifier l’intégrité” sonne comme un mot technique, mais l’idée est simple: un plugin ou un thème est censé être identique à une version connue. Si des fichiers diffèrent, il y a eu modification. La difficulté est double.
La première, c’est que certains éléments changent même sans infection. Un thème peut avoir des fichiers de cache, des assets générés, ou des contenus minifiés si vous utilisez un build. Un plugin peut générer des fichiers de log ou des dossiers temporaires. Si vous comparez brut à brut, vous risquez des faux positifs.
La seconde, c’est que l’infection peut modifier seulement un petit fichier, parfois un seul “include” ou un fichier rarement relu. On peut donc avoir un plugin “globalement” identique, mais un détail compromis.
La bonne approche est donc une combinaison de méthodes: comparaison de versions, contrôle ciblé de fichiers suspects, et analyse des écarts significatifs.
Deux méthodes réalistes pour contrôler plugins et thèmes
Selon votre niveau d’accès, vous avez plusieurs options. Certaines équipes utilisent des scanners et bases de signatures. Je n’ai rien contre, mais j’ai constaté qu’ils peuvent rater des modifications “sur mesure” ou signaler trop large si le site a été fortement personnalisé.
Personnellement, quand on vise l’intégrité, j’utilise surtout deux méthodes complémentaires.
Comparaison avec une version attendue
Si le plugin ou le thème vient du répertoire officiel ou d’un fournisseur sérieux, vous pouvez récupérer la version correspondant exactement à celle installée. Ensuite, vous comparez les fichiers.
Sur un site qui n’est pas trop énorme, la comparaison visuelle ou via un outil de diff peut être très parlante. Sur un parc de sites plus large, je passe souvent par une logique “fichiers hashés”: l’idée est de calculer des empreintes sur les fichiers présents, puis de voir lesquels diffèrent par rapport à la copie “saine”.
Le piège ici, c’est l’ajustement de version. Une différence de version légitime produit naturellement des différences. Il faut donc connaître la version exacte installée. Sur l’interface WordPress, la version s’affiche parfois, mais parfois un plugin charge des composants internes avec une logique qui n’est pas parfaitement reflétée. Si vous doutez, regardez le fichier principal du plugin (par exemple le bloc d’en-tête PHP) et comparez.
Analyse ciblée des fichiers exécutés
Même si vous comparez, je recommande une lecture ciblée de certains fichiers, parce que l’infection aime les points d’entrée. Pour un plugin, ce sera souvent le fichier principal chargé au moment où WordPress détecte le plugin. Pour un thème, ce sera un fichier comme functions.php, ou des includes appelés tôt.
Vous cherchez des signes d’obfuscation, par exemple des chaînes codées, des évaluations dynamiques, ou des structures qui semblent “hors sujet” pour le thème. Je ne vous donne pas une liste de signatures universelles, parce qu’elles varient selon les familles d’attaques, et parce que se baser uniquement sur un motif peut conduire à ignorer une variante.
Mais dans la pratique, si vous voyez des fonctions très génériques insérées dans un endroit inattendu, ou des appels vers des domaines externes sans rapport avec votre stack, vous avez un candidat. Et si le plugin ou le thème n’avait pas ce comportement avant votre date de bascule, vous avez une alerte renforcée.
Mettre les hypothèses à l’épreuve: gérer les faux positifs
L’intégrité ne signifie pas “absence totale de différence”. Elle signifie “différence expliquée”. Sur un site réel, surtout avec des outils de performance, les différences peuvent être normales.
Par exemple, un thème peut inclure un dossier d’assets générés, des fichiers CSS minifiés, ou des scripts créés lors d’un build. Certains thèmes proposent aussi des options “compilation” et régénèrent des fichiers. Dans ce cas, comparer avec une version “zip propre” peut rendre la comparaison bruyante.
Pour limiter les faux positifs, je me fixe une règle simple: d’abord vérifier les fichiers PHP qui sont chargés et exécutés. Ensuite seulement, regarder les assets et fichiers statiques si vous avez une raison de croire qu’ils ont été modifiés.
Un autre cas classique: les mises à jour automatiques. Si votre site est en multi-sites ou si l’hébergement force des mises à jour, vous pouvez recevoir des modifications sans avoir “cliqué”. Les dates de modification sont alors votre allié, mais elles ne sont fiables que si votre système de fichiers est cohérent. Sur certains hébergements, la granularité des timestamps peut être “arrondie”. Cela ne rend pas l’analyse impossible, mais vous oblige à raisonner avec des intervalles, pas avec des secondes exactes.
Étapes concrètes pour vérifier l’intégrité (sans casser votre site)
Voici une démarche qui a fonctionné pour moi sur des sites de taille variable. L’idée n’est pas d’être parfait sur chaque bit, mais d’être suffisamment rigoureux pour distinguer “modification normale” et “modification suspecte”.
Cette séquence évite de commencer par supprimer. Supprimer trop tôt peut casser la logique, et surtout, cela peut effacer des traces utiles. Si vous êtes pressé, vous pouvez aussi mettre le site en maintenance avant de poursuivre, mais je préfère d’abord faire l’audit.
Comment interpréter les écarts quand tout n’est pas “identique”
Une comparaison révèle parfois des écarts qui ne sont pas forcément malveillants. D’où l’importance d’interpréter.
Si vous comparez un plugin et trouvez que la structure est identique mais qu’il existe quelques différences de style, commentaires, ou chaînes de traduction, c’est souvent lié à une différence de version, ou à un patch de distribution. En revanche, si vous trouvez un ajout de logique ou de chargement dynamique dans un fichier central, ce n’est plus une simple divergence.
Dans un cas réel, j’ai vu un plugin “standard” qui avait été modifié de façon minimale: un petit bloc inséré dans un fichier qui n’était pas celui prévu pour gérer la fonctionnalité activée. L’équipe a d’abord utilisé un scanner qui n’a rien confirmé. Pourtant, lors de la comparaison, l’écart était évident: une fonction ajoutée, utilisée ensuite pour injecter une requête externe. C’était un petit code, donc facile à rater, mais l’intégrité avait parlé.
L’autre point à considérer est la cohérence avec les hooks. WordPress fonctionne par actions et filtres. Si un plugin ne devrait pas toucher à certains événements (comme le rendu des pages, la sortie du contenu, ou l’URL), et qu’il le fait soudainement, c’est un drapeau rouge. Inversement, un plugin qui fait exactement ce qu’il annonce et qui ne détourne pas des hooks inattendus peut être légitime, même si quelques lignes changent.
Vérifier spécifiquement les thèmes: le moment où tout se joue
Les thèmes ont un avantage pour l’attaquant: ils sont chargés, ils touchent au rendu, et ils ont accès à l’environnement WordPress. Un thème compromis peut modifier l’affichage sans toucher aux plugins, ou au contraire servir de vecteur à des appels distants.
Quand je vérifie l’intégrité d’un thème, je regarde généralement:
- functions.php, et tout fichier appelé au chargement, les templates principaux, surtout ceux liés à la sortie du contenu, tout fichier inclus via require/include depuis des endroits “tôt” dans l’exécution.
Un détail m’a souvent mis sur la voie: l’ajout de “code de liaison” à un endroit inattendu. Par exemple un bloc dans un fichier template qui devrait uniquement contenir de la logique d’affichage. Le code peut charger un autre fichier, ou déclencher une action discrète. Ce type de modification apparaît souvent dans les diffs, mais il faut savoir où chercher.
Si vous avez un thème enfant, la question devient plus délicate. Un thème enfant est normal qu’il modifie functions.php et des templates. Mais l’infection peut être dans le thème parent, dans le thème enfant, ou dans les deux. Vérifier l’intégrité sur les deux niveaux évite de tomber dans le piège “tout vient du thème enfant”.
Quand l’intégrité est incertaine: choisir entre “réparer” et “remplacer”
Il existe une tentation: corriger le fichier modifié à la main. Je comprends l’envie, mais sur des infections, c’est risqué. Un plugin peut contenir un “graal” caché dans un fichier secondaire, ou appeler du code depuis un chemin inattendu. Si vous réparez partiellement, vous pouvez laisser une porte ouverte.
Si l’intégrité ne peut pas être confirmée, le remplacement https://gardewp.fr/nettoyage-malware-wordpress/ est souvent le choix rationnel. Cela vaut surtout pour les plugins qui s’exécutent tôt dans la chaîne. Pour un thème, vous pouvez aussi le remplacer, mais il faut gérer la persistance des personnalisations. C’est là que l’existence d’un thème enfant devient un avantage.
Voici une façon de trancher quand vous hésitez:
- si le fournisseur fournit un package propre et reproductible, remplacez le plugin ou le thème par ce package, si vous n’êtes pas sûr de la version exacte, comparez d’abord, puis ne faites pas “au hasard”, si vous avez des modifications fonctionnelles légitimes, isolez-les dans un thème enfant ou dans une extension dédiée, puis revenez à un socle propre.
Je préfère documenter ces choix, même simplement, car lors d’une désinfection WordPress, l’historique compte. Si quelque chose se reproduit, vous devez savoir ce qui a été décidé, quand, et sur quelle base.
Contrôle additionnel: vérifier les dépendances et l’environnement
L’intégrité des plugins et thèmes n’existe pas en vase clos. Les attaques exploitent aussi:
- les fichiers uploadés via des formulaires, les modifications dans le dossier racine, la présence de scripts qui ne sont pas des fichiers de plugin ou de thème “classiques”.
Même si votre consigne est “vérifier l’intégrité des plugins et thèmes”, je conseille au moins un regard sur l’extérieur immédiat. Par exemple, s’il y a un comportement d’injection, un fichier suspect peut être placé ailleurs, puis être appelé par un plugin ou un thème modifié. Dans ce cas, réparer l’intégrité sans chasser le point d’appel peut donner l’impression que vous avez nettoyé, puis le problème revient.
Protéger le site après la vérification
Nettoyer n’est utile que si vous empêchez la récidive. Une désinfection réussie se joue autant dans l’après que dans le nettoyage.
Après remplacement et vérification, je reviens systématiquement sur trois axes. D’abord, les accès. Les comptes admin doivent être cohérents. Ensuite, les mises à jour. Mais je nuance: mettre à jour tous les plugins en même temps peut compliquer le diagnostic si quelque chose se passe mal. Je préfère souvent un ordre contrôlé. Enfin, l’hygiène technique. Des limites de permissions, une gestion des fichiers cohérente, et une surveillance des changements réduisent les chances que l’infection revienne sans être détectée.
Si vous gérez plusieurs sites, je m’appuie sur une logique d’images de référence: conserver une copie propre de plugins et thèmes régulièrement, ou au moins des archives de versions. Cela rend la prochaine vérification beaucoup plus rapide.
Les compromis les plus fréquents (et comment je les traite)
Il y a toujours des contraintes, et elles finissent par orienter la décision.
Quand un site a été fortement customisé, remplacer un thème peut casser le rendu. Dans ce cas, je vérifie d’abord l’infection potentielle dans la partie exécutée, et je privilégie le remplacement du socle en conservant le thème enfant. Ce n’est pas “tout ou rien”.
Quand un plugin est “clef en main” mais obsolète, comparer avec une version attendue peut être impossible. Certains fournisseurs n’archivent pas correctement les anciennes versions, ou le site n’en garde pas la trace. Dans ce cas, l’évaluation devient plus subtile: je cherche des modifications incriminantes plutôt que de forcer une comparaison stricte à l’aveugle.
Enfin, quand l’hébergement est instable ou que l’accès fichier est limité, les dates et la comparaison peuvent être moins fiables. Là, la priorité passe au diagnostic via les comportements et aux points d’entrée, et le remplacement devient le plan principal, avec un contrôle sur les effets.
Mini-guide de décision quand vous ne savez pas quoi supprimer
Je vous propose une règle pratique, simple, pour éviter les suppressions aveugles.
| Situation observée lors de la vérification | Action la plus sûre | |---|---| | Des fichiers PHP du plugin ou du thème diffèrent clairement et modifient des points d’entrée | Remplacer par une version propre et vérifier le comportement après redéploiement | | Les différences sont limitées à des assets (CSS/JS/images) ou à des traductions | Recontrôler la date et la version, puis traiter uniquement si un comportement anormal est lié | | Impossible de garantir la version exacte ou la copie “saine” | Inspection ciblée des hooks et des includes, puis remplacement si un doute sérieux persiste |
Ce tableau ne remplace pas un audit complet, mais il donne une structure mentale quand on est sous pression, avec un site potentiellement instable.
Garder une trace, même légère, pour la suite
Pendant une désinfection, on se concentre sur l’immédiat: stopper le comportement, restaurer la confiance. Pourtant, la meilleure prévention d’une récidive, c’est la mémoire. Noter ce que vous avez comparé, quelles versions étaient installées, et quels écarts vous avez observés, même en notes courtes, change la vitesse de réaction lors du prochain incident.
Sur un de mes chantiers, c’est cette trace qui a permis de conclure que la cause n’était pas un plugin “globalement connu”, mais un changement discret fait à une date précise via un accès oublié. Sans l’historique des vérifications, l’équipe aurait probablement recommencé un cycle de suppression et réinstallation sans comprendre la source.
Dernier point: la vérification d’intégrité n’est pas un quiz, c’est un jugement
Au fond, vérifier l’intégrité des plugins et thèmes, c’est exercer un jugement informé. La comparaison de version et la lecture ciblée donnent des preuves. Les dates et le contexte donnent le sens. Et votre expérience vous aide à éviter deux erreurs classiques: considérer “différent” comme forcément “infecté”, ou considérer “ça marche” comme forcément “sain”.
Si vous construisez une méthode simple, reproductible, vous gagnez du temps. Et surtout, vous rendez la désinfection plus propre, moins destructrice, et plus sûre pour le site et pour les utilisateurs qui y reviennent.