Quand on parle de “malware WordPress”, on pense souvent au fichier d’un plugin “suspect” ou à un thème modifié. C’est logique, parce que l’attaque la plus visible passe par là. Mais il existe une autre famille de compromissions, plus insidieuse, où le problème vient de ce que WordPress embarque ou installe avec le site: des bibliothèques incluses, des packages vendés, parfois des dépendances réutilisées par plusieurs plugins. Dans ces cas, nettoyer “le plugin” ne suffit pas. Il faut remonter à la chaîne, vérifier les bibliothèques compromises, puis reconstituer des dossiers fiables.
Je l’ai vu sur des sites où les extensions “actives” paraissaient propres, où l’administration affichait un comportement normal, mais où des requêtes étranges partaient la nuit, ou où des scripts injectés apparaissaient seulement sur certaines pages, souvent via une dépendance chargée au runtime. Le nettoyage demande une méthode, du discernement, et surtout un plan pour ne pas “réinfecter” le site pendant la réparation.
Le piège des bibliothèques incluses compromises
WordPress est un écosystème. Un plugin A peut embarquer une librairie tierce, un plugin B peut la réutiliser, et parfois des bibliothèques sont chargées automatiquement via des chemins internes, des chargements conditionnels, ou des systèmes de détection. Résultat: le code malveillant peut se cacher dans un composant qui n’a l’air de rien.
Typiquement, une bibliothèques “incluse” peut être compromise de plusieurs façons:
- modification directe de fichiers dans le dossier concerné (par exemple un dossier de dépendance dans wp-content, ou un dossier “vendor” dans un plugin) installation d’un package malveillant par un script de dépendance ajout d’un chargeur, un “runner” minimal, capable de récupérer du contenu ailleurs, puis de l’exécuter
Ce qui rend le diagnostic difficile, c’est que l’attaque peut ne pas toucher les fichiers les plus connus. La base de données peut contenir des entrées modifiées, mais le comportement se déclenche via un chargement spécifique. Ou bien la compromission est “dormante” et s’active à une heure précise, ou seulement pour certains navigateurs.
Sur le plan pratique, l’erreur classique consiste à remplacer uniquement ce qui semble compromis: on supprime le plugin visible, on réinstalle WordPress, et on redémarre. Si la dépendance compromise reste quelque part, on se retrouve avec le même scénario, parfois moins visible, parfois pire.
Distinguer propagation, persistance, et déclenchement
Avant de toucher aux fichiers, j’ai pris l’habitude de classer le problème. Pas au sens “théorique”, mais au sens opérationnel: qu’est-ce qui prouve que le site a été re-compromis, et à quel moment?
Trois questions guident cette lecture:
La compromission persiste-t-elle après un nettoyage partiel, ou revient-elle au prochain déploiement? Le déclenchement dépend-il d’un événement (visite d’une page, soumission de formulaire, mise en cache, tâche planifiée)? Les logs et traces web révèlent-ils des appels vers des domaines externes, des requêtes internes anormales, ou une suite d’actions répétitive?Quand c’est une bibliothèque incluse compromise, on observe souvent un déclenchement “différé”. Par exemple, le code malveillant est présent, mais il ne fait rien tant que WordPress n’a pas chargé la dépendance. Donc même si un fichier d’apparence “banale” a été modifié, vous ne verrez pas forcément de symptômes immédiats.
En face, la persistance peut être multiple. Elle peut être dans un fichier, mais elle peut aussi être dans la base, via des champs qui alimentent un flux, ou via un réglage lié à un plugin. Dans ces cas, nettoyer les fichiers sans traiter la base peut laisser derrière soi des “reconfigurations” qui réécrivent les fichiers au fil du temps.
Préparer un terrain propre: sauvegardes, isolement, et fenêtres d’observation
Un nettoyage sérieux ne démarre pas par l’effacement. Il démarre par la réduction du risque.
Si le site est en production, l’option https://gardewp.fr/ la plus sûre est de le placer en lecture limitée ou en maintenance, selon votre capacité. L’objectif est simple: empêcher l’attaquant de continuer à injecter du contenu et d’installer d’autres artefacts pendant que vous travaillez.
Ensuite, sauvegardez avec une stratégie cohérente:
- une sauvegarde complète des fichiers actuels (y compris les dossiers dans wp-content et toute bibliothèque incluse) une sauvegarde de la base de données une exportation des paramètres de l’environnement, au minimum version PHP, configuration serveur, et liste des plugins et thèmes installés
Le point important ici est de conserver l’état “avant” pour pouvoir comparer et justifier les décisions. Si vous supprimez trop vite, vous perdez l’empreinte utile: l’attaquant laisse parfois des signatures dans le code, ou des indices dans des chemins de chargement.
Enfin, isolez le diagnostic. Je recommande de travailler sur une copie de l’environnement, idéalement hors production. Cela évite aussi une autre erreur courante: déclencher le code malveillant en visitant le site depuis votre propre navigation, puis croire que “ça a disparu”, alors que le déclenchement n’arrive pas dans ce cas d’usage.
Repérer le code suspect dans les bibliothèques
Le repérage n’est pas uniquement visuel. Une bibliothèque compromise peut être presque identique à l’originale, sauf quelques lignes. Et souvent, ce sont ces quelques lignes qui comptent.
Voici ce que je cherche en premier, dans une approche raisonnable et défendable, sans “paranoïa”.
1) Les patterns de chargement et d’exécution
Dans les bibliothèques, le malware vise rarement à “se montrer”. Il préfère agir comme un chargeur discret, puis déclencher une logique. Concrètement, je vérifie des éléments comme:
- présence de fonctions de décodage, de déchiffrement ou de décompression intégrées de manière atypique usage de fonctions d’exécution dynamique, en particulier quand elles apparaissent dans des fichiers qui ne devraient pas en contenir scripts qui construisent des chemins ou des URLs à partir de fragments, puis qui incluent du contenu
Vous n’avez pas besoin de “comprendre tout le code” pour l’identifier. Si une bibliothèque censée être un utilitaire de base contient un chargeur d’exécution, c’est un signal fort.
2) Les incohérences d’emplacement et de rôle
Une dépendance vendue ou incluse a généralement une structure cohérente. Quand vous voyez un fichier inattendu dans un dossier de bibliothèque, ou une modification dans un chemin qui n’est pas lié au fonctionnement normal du plugin, il faut creuser.
Un exemple fréquent: un code malveillant apparaît dans un dossier “vendor” ou dans un répertoire qui devrait contenir uniquement des fichiers “compatibles” (classes, utilitaires). Si un fichier a la même extension, la même taille proche, mais un contenu inhabituel, comparez avec la version attendue du package.
3) Des traces de modification récente
Les dates de modification aident, mais elles sont imparfaites. Sur certains hébergements, les timestamps peuvent être modifiés par des déploiements ou des migrations. Malgré ça, si une bibliothèque a été modifiée le même jour que l’apparition d’erreurs dans les logs, c’est une corrélation utile.
Je fais aussi attention aux fichiers “touchés” sans raison. Par exemple, un fichier de dépendance ne devrait pas changer au hasard si aucune mise à jour n’a été faite.
Stratégie de nettoyage: reconstruire plutôt que “patcher”
Sur une compromission via bibliothèques incluses, j’ai constaté que la réparation à la main donne rarement un résultat fiable. Le malware est parfois fragmenté, et un “petit correctif” peut casser la logique, tout en laissant une partie du chargeur intacte.
La meilleure approche consiste souvent à reconstruire des morceaux entiers à partir de sources propres et vérifiables:
- réinstaller la partie concernée (plugin, thème, ou bibliothèque) depuis une source officielle ou une archive contrôlée recalculer l’état des fichiers comparer avec une copie saine, si vous en avez une supprimer tout artefact qui n’appartient pas au package d’origine
La question qui revient toujours est la suivante: “comment être sûr que la source est propre?”
Quand vous travaillez à partir d’une archive téléchargée, vous devez vous assurer que cette archive n’a pas été altérée. En pratique, je m’appuie sur des sources officielles (catalogues de plugins, dépôts, pages de projet) et je conserve l’archive utilisée. Si votre seul accès passe par un site déjà compromis, vous risquez de télécharger le malware “avec”.
Vérifier l’intégrité: hashes et comparaisons de dossiers
WordPress et ses extensions laissent une surface de comparaison, surtout si vous avez une copie connue saine, ou si vous avez conservé les versions avant l’incident.
Deux méthodes sont particulièrement utiles:
- comparaison avec la version d’origine du plugin ou du thème (taille, contenu, structure) vérification par empreintes de fichiers (hash) quand vous disposez d’une base de référence fiable
Sans chercher à créer un laboratoire complet, l’idée est de faire du “diff” ciblé. Si vous détectez un fichier modifié, vous comparez son contenu et vous vérifiez si les modifications correspondent à une logique légitime, ou à un comportement de chargeur.
Si vous n’avez pas de base de référence, vous pouvez quand même détecter des anomalies: fichiers inconnus, chemins incohérents, signatures de code suspects.
Attention aux cas limites: certaines bibliothèques ont des versions multiples qui varient selon la configuration. Le but n’est pas d’exiger un contenu identique à la perfection, mais de repérer ce qui ne devrait pas être là.
Traitement des plugins, des thèmes, et des bibliothèques incluses
À ce stade, vous avez probablement identifié un ou plusieurs composants qui hébergent la compromission. Le piège est de s’arrêter au niveau “visible”.
Si la bibliothèque incluse est compromise, l’étape suivante consiste à déterminer qui est responsable de l’inclusion. Parfois, c’est un plugin. Parfois, c’est un thème qui charge une dépendance. Plus rarement, c’est un composant plus global.
Dans la pratique, je procède comme suit, en gardant les décisions traçables.
Étape 1: retirer tout ce qui peut contenir la charge
Vous pouvez commencer par désactiver ce qui est suspect, et même supprimer temporairement certains répertoires, tout en gardant vos sauvegardes. Il arrive que la désactivation ne suffise pas si le code est chargé à un autre niveau, ou si des tâches planifiées continuent d’exécuter.
Je préfère donc un retrait contrôlé: vous coupez le chemin d’exécution, puis vous observez.
Étape 2: réinstaller depuis une source propre
Pour chaque plugin ou thème concerné, réinstallez en remplaçant le dossier complet, pas seulement les fichiers modifiés. Ensuite, testez.
Si la bibliothèque incluse est un composant dans le plugin, remplacer le plugin entier est souvent plus robuste que “nettoyer” dans le dossier de dépendance.
Étape 3: supprimer les artefacts étrangers
Les compromissions laissent souvent des fichiers additionnels, caches, scripts de chargement, ou configurations modifiées. Même si vous réinstallez un plugin, il peut rester des fichiers ajoutés ailleurs.
C’est là que le travail “fouille et supprime” prend tout son sens. Vous supprimez ce qui ne correspond pas aux fichiers attendus du package.
Étape 4: traiter la base de données si nécessaire
Si vous avez des indices sur une persistance via la base, par exemple des champs de configuration injectant du code, vous devez traiter aussi ce volet. Sinon, la réparation des fichiers peut être annulée par un paramétrage qui recharge l’injection.
La difficulté ici est de distinguer une donnée “modifiée” d’une donnée “référente” qui pointe vers un fichier. Quand vous voyez des contenus injectés dans des pages, ou des options inhabituelles, c’est un signe.
Une check rapide avant de passer en mode “suppression définitive”
Je garde ce mini cadre pour éviter les erreurs de jugement quand je dois intervenir sur plusieurs sites.
- Couper l’exécution pendant le diagnostic (maintenance ou isolement), sans perdre les logs. Sauvegarder fichiers et base, puis travailler sur copie hors production. Identifier précisément les composants où la bibliothèques est incluse et potentiellement modifiée. Remplacer intégralement les plugins ou thèmes concernés depuis une source contrôlée, pas via le site compromis.
Cette approche évite de “bricoler” et de relancer une réinfection pendant que vous réinstallez.
Cas typiques de “bibliothèque incluse compromise” et comment les résoudre
Chaque incident a ses détails, mais on retrouve souvent des schémas.
Scénario A: la dépendance est dans le dossier d’un plugin
Vous voyez des pages injectées, et pourtant le plugin actif semble “propre” à l’inspection superficielle. En creusant, vous trouvez un chargeur minimal dans une sous-dépendance, dans un dossier de vendor.
Résolution: réinstaller le plugin entier depuis une archive propre, puis vérifier qu’aucun fichier additionnel n’est resté. Ensuite, lancer un test de navigation sur des chemins qui déclenchent l’injection. Si les injections ne reviennent pas, le nettoyage est probablement complet.
Scénario B: la dépendance est partagée par plusieurs plugins
Un même utilitaire est présent dans deux extensions différentes, et il a été altéré. Dans ce cas, si vous ne réinstallez qu’un seul plugin, l’autre peut recharger le code compromis.
Résolution: vous identifiez les dossiers où la bibliothèque est présente, vous réinstallez tous les composants qui la transportent, puis vous comparez l’état final.
Scénario C: la bibliothèque est compromise indirectement via un mécanisme de mise à jour
Parfois, un site a été compromis pendant une fenêtre de mise à jour. Le plugin a pu être mis à jour, mais l’archive ou l’installation a été altérée.
Résolution: réinstaller tous les éléments mis à jour pendant la période, vérifier l’intégrité des archives utilisées, puis surveiller les prochaines mises à jour en contrôlant ce qui est déployé.
Réinfection: les signaux qui doivent vous alerter
Un nettoyage peut être “réussi” pendant quelques heures, puis échouer. C’est souvent le signe que:
- vous avez retiré le code, mais pas la persistance vous avez remplacé la bibliothèque, mais un autre composant la réintroduit une tâche planifiée ou un cron lance de nouveau le chargement
Je recommande de surveiller après le redémarrage, pendant au moins 24 à 72 heures selon l’intensité du trafic et le calendrier habituel du site. Les sites à faible trafic peuvent masquer des injections qui ne se déclenchent qu’en condition.
Les signaux concrets qui m’ont souvent servi:
- augmentation d’erreurs 404 ou 500 sur des endpoints sans raison trafic sortant anormal vers des domaines inattendus réapparition de fichiers créés récemment dans des dossiers de dépendance nouvelles entrées d’administration, ou modification de rôles
Si vous observez l’un de ces éléments, considérez que le nettoyage n’est pas terminé.
Durcir pour éviter la répétition, sans casser le site
Nettoyer une fois, c’est bien. Empêcher la répétition, c’est mieux. Mais durcir ne veut pas dire verrouiller au hasard.
Je privilégie des mesures qui réduisent l’accès et la surface d’attaque, tout en minimisant les risques de blocage.
Quelques actions, concrètes, qui ont généralement un bon rapport bénéfice et coût:
- mettre à jour WordPress, PHP, thèmes et plugins seulement après validation, et pas en pleine investigation supprimer les plugins inutiles, surtout ceux avec une faible maintenance limiter les permissions d’écriture pour que les mécanismes d’exécution ne puissent pas modifier des dossiers sensibles facilement contrôler l’accès admin, via des règles de filtrage côté serveur et une authentification forte si possible
Si vous modifiez trop de choses d’un coup pendant un incident, vous ne saurez plus ce qui a résolu le problème et ce qui l’a provoqué.
Vérifications finales: ne pas s’arrêter au “plus rien ne bug”
Un site propre ne se limite pas à “ça marche”. Il faut valider que les composants sensibles ont retrouvé un état cohérent.
Je fais une série de vérifications orientées comportement:
- navigation sur les pages qui étaient touchées tests de fonctionnalités déclenchant les scripts et les chargements (formulaires, recherche, chargements front) inspection des fichiers récemment modifiés après quelques cycles revue des tâches planifiées et des utilisateurs
Si tout reste stable, vous pouvez continuer vers une étape de durcissement et de suivi long terme.
Voici une dernière mini grille, utile quand vous devez rendre un verdict après nettoyage:
- Les dossiers de dépendances suspects ont-ils été remplacés intégralement? Avez-vous éliminé les fichiers ajoutés ou les chemins inattendus? Les chargements externes ou scripts d’exécution dynamiques disparaissent-ils? Les comportements déclencheurs ne rejouent-ils pas le même scénario après 1 à 3 jours?
Et si vous n’êtes pas sûr de la bibliothèque à 100 %?
C’est une situation fréquente. Parfois, vous avez des indices solides, mais pas une preuve formelle. Dans ce cas, vous devez arbitrer entre risque et impact.
Mon approche est pragmatique: si une bibliothèque est impliquée dans un chemin d’exécution observé, vous remplacez le package complet concerné, au lieu de tenter un patch minimal. Le patch minimal peut fonctionner aujourd’hui et casser demain, ou laisser un petit bout du chargeur derrière vous.
Si vous hésitez sur le périmètre, testez sur la copie. Vous remplacez, vous observez, vous comparez. La copie vous donne le droit de vous tromper, sans payer ce droit en production.
Quelques repères sur la temporalité d’un incident
Une dernière chose que je veux dire clairement: la chronologie compte. Si votre site a été compromis, la “date d’infection” est souvent floue, parce que l’attaque peut exister avant que vous la découvriez. Cela implique que le nettoyage ne doit pas se baser uniquement sur “depuis combien de temps ça a commencé à bugger”.
Quand la compromission touche des bibliothèques incluses, elle peut avoir été déposée, puis activée seulement plus tard. Donc la période à inspecter est souvent plus longue que la période d’observation.
En pratique, quand vous identifiez une ou plusieurs modifications, je recommande de remonter au moment où vous avez effectué des mises à jour, des changements de configuration, ou des déploiements. C’est dans ces fenêtres que l’injection a souvent été introduite, même si les symptômes arrivent après.
Conclusion opérationnelle, sans formules toutes faites
Supprimer un malware WordPress en nettoyant des bibliothèques incluses compromises, ce n’est pas seulement “effacer un fichier”. C’est reconstruire des composants entiers depuis une base propre, éliminer les artefacts qui restent, et vérifier la persistance via les fichiers et la base. La méthode la plus fiable, dans ce type d’incident, consiste à couper l’exécution pendant l’analyse, travailler sur copie, remplacer les plugins ou dépendances concernés au complet, puis observer la stabilité sur plusieurs jours.
Si vous ne deviez retenir qu’un principe, ce serait celui-ci: quand une dépendance sert de vecteur, le patch partiel laisse trop de place à la réapparition. Remplacer le package impliqué, puis confirmer par comportement et par contrôle des fichiers, vous donne la meilleure chance de repartir avec un WordPress vraiment sain.