Nettoyage virus WordPress : éradiquer les injections de scripts malveillants

Quand un WordPress se fait “infecter”, ce n’est pas toujours une histoire de gros malware bruyant. Dans beaucoup de cas, il suffit d’une petite injection de script, silencieuse, qui contourne les pages publiques et détourne le navigateur vers une intention douteuse. J’ai déjà vu des sites qui semblaient fonctionnels, sans ralentissements, mais dont la source HTML contenait des bouts de JavaScript impossibles à comprendre, ajoutés au moment du rendu. L’horreur, c’est que la facture arrive plus tard: SEO qui s’effondre, redirections aléatoires, faux formulaires, campagnes de malvertising qui utilisent votre domaine comme caisse de résonance.

Le “nettoyage virus WordPress” dans ces situations, ce n’est pas seulement supprimer un fichier. Il faut analyser comment l’injection est déclenchée, identifier la persistance, puis vérifier que la menace ne revient pas au premier export de thème, à la prochaine mise à jour, ou après une restauration qui ne restaure pas vraiment la bonne chose.

Reconnaître une infection par injection de scripts

Une injection malveillante a souvent un symptôme: le site n’est pas infecté partout, pas de manière uniforme. L’utilisateur peut voir un comportement différent selon la page, l’agent navigateur, l’heure, ou l’origine de la requête. Sur WordPress, cela arrive fréquemment via:

des fichiers modifiés en coulisse (thèmes, plugins, fichiers racine), des champs de base de données qui portent le payload, des fonctions de “hook” (actions ou filtres) ajoutées de façon détournée, des scripts chargés dynamiquement à partir d’un serveur externe.

Un signe concret que j’ai déjà rencontré: l’inspection du code source montrait un bloc de script injecté avant le ou juste avant le rendu du contenu. Parfois, le bloc était obfusqué, compressé, avec des noms de variables sans sens. Le plus révélateur, ce sont les appels réseau déclenchés: une requête vers un domaine inconnu, ou un chargement de fichier JavaScript depuis une URL qui n’a aucun lien avec votre stack.

Il faut aussi distinguer l’infection “côté navigateur” de la compromission “côté serveur”. Les injections peuvent se contenter d’un simple script, mais le vecteur qui a permis d’ajouter ce script vient presque toujours d’une faiblesse plus profonde: identifiants, plugin compromis, thème bricolé, ou un accès à l’hébergement (souvent via une vulnérabilité ou une mauvaise gestion d’autorisations).

Cartographier la trace avant de supprimer

Le piège classique, c’est de remplacer des fichiers sans comprendre ce qui a été changé. Si vous effacez au hasard, vous risquez de:

casser un réglage légitime, masquer l’origine de la compromission, oublier un point de persistance qui réinfectera au prochain accès.

Sur un cas récent (site e-commerce, beaucoup de trafic), j’avais reçu un signal via des messages d’alerte navigateur, puis des plaintes utilisateurs sur des pages produits. La première impulsion a été de “réinstaller WordPress”. Mauvaise idée. La réinstallation a effacé le cœur, mais l’injection venait d’un plugin “custom” modifié. Sans analyse, le site revenait infecté dès que le plugin se chargeait.

Avant d’effacer, prenez le temps de constituer une base de travail:

Listez les fichiers modifiés par rapport à une version de référence. Recherchez les signatures d’obfuscation typiques dans les thèmes et plugins. Vérifiez les comptes utilisateurs, et en particulier les nouveaux rôles administrateur. Constatez les accès récents (logs serveur, logs d’accès WordPress si disponibles). Identifyiez les endpoints ou hooks qui ajoutent le script au HTML.

Ce n’est pas un luxe. Même si vous êtes pressé, ces étapes font gagner un temps énorme. Vous allez aussi réduire les allers-retours avec l’hébergeur, parce que vous arrivez avec des preuves.

Comprendre les voies d’injection les plus fréquentes

Sur WordPress, les injections malveillantes ont des chemins assez répétitifs. Je ne parle pas de “recettes universelles”, mais de schémas qu’on rencontre souvent sur des environnements réels.

Modification des fichiers de thème

Un thème peut être infecté via functions.php ou via des fichiers inclus indirectement. Parfois, le script n’est pas écrit directement dans le fichier visible, mais introduit via include ou require vers un fichier placé ailleurs, dans le thème ou dans un répertoire inattendu. Le payload peut s’activer seulement dans certains contextes, par exemple sur les pages front-office, pas sur l’admin.

Plugin compromis ou ajouté à la va-vite

Les plugins sont un point de contrôle naturel. Un plugin peut être:

un plugin tiers devenu vulnérable, un plugin initialement propre, puis modifié (avec un fichier falsifié), un plugin ajouté discrètement, portant des noms anodins.

Dans les environnements où l’accès FTP est exposé à des comptes faibles, ce scénario arrive très vite après une tentative de connexion.

Injection dans la base de données

Parfois, l’injection ne vit pas dans les fichiers. Elle réside dans des options WordPress, des métadonnées de thème, ou des champs utilisés pour l’affichage. On voit alors des scripts insérés via des hooks, mais leur contenu est stocké dans la base. C’est plus difficile à repérer si vous vous contentez de comparer le dossier wp-content.

Persistance via la création d’URL de redirection

Il arrive aussi que l’objectif ne soit pas juste d’injecter un script, mais de transformer le comportement de navigation: redirections, ouverture d’URL externes, ou chargement d’un script qui récupère l’URL de destination selon des critères.

Dans ces cas, vous avez souvent des indicateurs côté réseau: des appels sortants qui n’étaient pas là avant, parfois vers des domaines qui changent.

Procéder au nettoyage de manière fiable

Le nettoyage d’une infection WordPress comporte deux impératifs, parfois contradictoires: supprimer la menace et éviter la “re-contamination”. Cela signifie que le remède doit être complet, pas seulement cosmétique.

La méthode dépend de ce que vous trouvez, mais un socle robuste consiste à:

isoler l’environnement, désinfecter en remontant aux modifications, purger et remplacer ce qui a pu être altéré, puis valider que la sortie HTML et le chargement réseau ne révèlent plus d’indicateurs.

Isoler le site pour éviter la diffusion

Dès que vous avez des preuves d’injection, coupez les variables qui aggravent la situation. Si possible, mettez le site en mode maintenance ou restreignez l’accès au front. Ce n’est pas “pour punir les visiteurs”, c’est pour limiter les exécutions répétées, le bruit dans les logs, et les risques de propagation.

Si votre hébergeur propose un mode “maintenance” ou une redirection temporaire interne, c’est souvent suffisant. Si vous pouvez, conservez l’état infecté sous forme de copie horodatée: une image du code et des exports partiels. Vous pouvez ensuite comparer.

Remplacer plutôt que patcher à la main

Dans les cas d’injection, j’ai tendance à favoriser le remplacement contrôlé. Cela ne veut pas dire “supprimer tout et réinstaller en copiant au hasard”, mais plutôt:

réinstaller le cœur de WordPress depuis une source fiable, remplacer thèmes et plugins par des versions propres, supprimer les fichiers inconnus, et ne conserver que ce qui est explicitement attendu.

Le risque du patch manuel, c’est que vous “nettoyez” une branche, mais que la persistance est ailleurs. Par exemple, vous supprimez un eval dans un fichier, mais un autre fichier obfusqué reste chargé via require_once dans un chemin moins évident.

Décontaminer proprement wp-content

Sur la plupart des infections, le cœur de WordPress n’est pas le point d’entrée. La cible, c’est wp-content. Les actions typiques que vous devez envisager:

détecter les fichiers modifiés avec une comparaison, vérifier l’intégrité des thèmes et plugins, supprimer les fichiers ajoutés qui n’ont pas d’équivalent dans une installation saine, examiner les fichiers qui contiennent des patterns suspects.

Les patterns exacts varient, mais ce que je recherche souvent, ce sont les indicateurs d’exécution dynamique et d’obfuscation: fragments concaténés, fonctions d’exécution à la volée, chaînes longues sans sens, ou appels à des fonctions système côté PHP qui ne devraient pas être présents dans un thème.

Si vous utilisez un système de déploiement avec Git, c’est encore plus simple: vous comparez l’état attendu à l’état présent, et vous refusez toute modification en dehors du pipeline.

Si le payload est en base de données

Quand l’injection provient de la base, la désinfection devient plus “fonctionnelle”. Vous ne supprimez pas juste un fichier, vous devez:

identifier les options ou contenus qui déclenchent l’injection, retirer le contenu malveillant, vérifier que les hooks qui l’insèrent ne sont pas eux-mêmes altérés.

Selon la structure de votre site, cela peut impliquer de parcourir les options, les métadonnées du thème, et les contenus de zones où WordPress stocke des scripts. Sans entrer dans des procédures trop risquées, l’idée est claire: vous devez nettoyer la source des données, pas seulement le symptôme côté front.

Sécuriser l’accès pour arrêter la réinfection

Un site “désinfecté” qui reste vulnérable finit par re-recevoir le même type d’injection. Les injections de scripts sont souvent la phase visible, pas la cause racine.

J’ai vu des cas où tout avait été remis propre, puis re-pollué en moins de 48 heures. La cause était presque toujours un compte ou un vecteur d’accès.

Voici les leviers qui comptent le plus, dans un ordre pragmatique:

comptes: supprimer les utilisateurs suspects, forcer des mots de passe robustes, et appliquer une rotation quand vous avez des doutes, sécurité d’accès: limiter les tentatives de connexion, vérifier l’exposition brute de l’admin, et filtrer les accès non nécessaires, droits: corriger les permissions fichiers et les configurations d’hébergement, éviter que le serveur autorise plus que ce qui est nécessaire, plugins: supprimer ce qui n’est pas essentiel, mettre à jour ce qui reste, et retirer les thèmes ou plugins “maison” sans suivi de version si vous n’êtes pas sûr de leur provenance.

Si vous avez un hébergeur qui gère des protections WAF ou des règles de sécurité, utilisez-les. Mais gardez en tête qu’un WAF peut masquer un problème sans le résoudre.

Vérifier l’absence d’injections après nettoyage

La vérification est souvent le point le plus négligé, parce qu’on veut tourner la page. Pourtant, c’est là que vous gagnez la confiance.

Vous devez contrôler au moins trois niveaux:

Le code HTML généré: aucun script inconnu, aucune insertion inattendue. Le réseau: aucun chargement externe suspect, pas de redirection vers des domaines non liés. La présence de mécanismes de persistance: aucun fichier ou hook non attendu, pas de nouveau compte, pas de tâche planifiée douteuse.

Sur un site où l’injection était conditionnelle, on a dû tester sur plusieurs pages et plusieurs navigateurs. Sur certains cas, l’injection ne se déclenche que sous certains critères, par exemple un User-Agent spécifique ou une fenêtre de temps. Cela signifie que “ça a l’air propre chez moi” n’est pas un test suffisant.

Si vous utilisez des outils de scan, prenez-les comme signal, pas comme verdict absolu. Les scanners trouvent souvent des marqueurs, mais ils peuvent rater des injections obfusquées ou conditionnelles. L’inspection manuelle du rendu, même rapide, aide beaucoup.

Les pièges qui rendent le nettoyage inefficace

Le “nettoyage virus WordPress” ne rate pas toujours par manque de travail. Il rate par manque de stratégie.

Voici quelques erreurs que j’ai vues, parfois sur des équipes très compétentes:

Remettre en ligne le site sans rotation des identifiants, donc la menace revient. Supprimer seulement le script injecté, alors que le mécanisme de déclenchement reste dans un fichier inclus. Reprendre une sauvegarde “ancienne” qui contient déjà le payload. Mettre à jour WordPress et les extensions sans désinfecter la source, ce qui ne fait que déplacer le problème. Ne pas tester l’injection sur les pages où elle s’affiche réellement.

Il y a aussi un piège plus subtil: la restauration partielle. Une sauvegarde peut inclure la base mais pas les https://gardewp.fr/nettoyage-malware-wordpress/ fichiers, ou l’inverse. Si vous restaurez seulement la base sur un code déjà altéré, vous pouvez réintroduire le contenu malveillant, même si vous aviez désinfecté les fichiers.

Réinstaller sans casser le site (et sans recharger la menace)

Quand on décide de “repartir propre”, on doit le faire avec méthode. Reinstaller WordPress, c’est simple, reconstruire une stack fonctionnelle sans reintroduire l’infection, c’est moins simple.

L’approche que je privilégie consiste à:

repartir d’un WordPress propre, remettre les thèmes et plugins validés (ou des versions de référence), restaurer la base seulement si elle n’est pas altérée, ou si vous avez nettoyé les champs compromis, vérifier que les contenus dynamiques ne réactivent pas l’injection.

Le compromis, c’est le risque de perdre des réglages. Parfois, restaurer toute la base est plus rapide, mais si la base contient une persistance, c’est un boomerang. Si vous pouvez, exportez ce qui est critique, puis restaurez de façon contrôlée.

Cas concret: injection localisée et persistance via inclusion

Je vous raconte un scénario que j’ai rencontré assez souvent dans les audits.

Le site affichait des pages normales, mais un script inconnu apparaissait uniquement sur certaines routes. L’inspection a révélé un code injecté dans le HTML à l’instant où le thème chargeait un fichier “helpers”. Sauf que ce fichier helpers n’était pas celui attendu. Il avait la même logique apparente, mais des lignes ajoutées étaient responsables de l’injection.

La correction efficace a été double:

Remplacement du thème par une version issue du dépôt d’origine (ou d’un export propre), Vérification du fichier en question, car le script était chargé via un include dynamique.

La première tentative de nettoyage avait consisté à supprimer le bloc de script dans le fichier principal du thème. Ça semblait marcher sur la page test, puis la contamination revenait sur une autre route. La différence était le chemin de chargement des fichiers du thème. Une seule suppression ne suffisait pas.

Ce type de cas illustre pourquoi un nettoyage “symptôme” ne suffit pas. Il faut chercher la chaîne complète qui produit le résultat.

Checklist rapide de triage (sans se perdre)

Voici une checklist courte, utile quand vous travaillez dans l’urgence, tout en gardant une logique de preuve.

isoler le site (maintenance ou restriction) pour éviter la répétition, identifier comptes utilisateurs nouvellement créés et modifier toutes les clés de session, comparer thèmes et plugins avec une version de référence, supprimer le non attendu, inspecter les pages qui déclenchent l’injection et vérifier le code HTML et le réseau, nettoyer base de données si le contenu provient d’options ou de métadonnées compromises.

Cette liste ne remplace pas une méthode complète, mais elle évite le chaos.

Quand faire appel à l’hébergement ou à un spécialiste

Il y a des moments où les limites techniques deviennent évidentes. Si vous ne pouvez pas récupérer les logs d’accès, si vous n’avez aucun moyen de comparer les fichiers, ou si vous soupçonnez une compromission de l’hébergement (côté système), le travail devient plus risqué.

Contactez l’hébergeur si vous observez des choses comme:

des comptes FTP ou SSH inconnus, des connexions suspectes récurrentes impossibles à bloquer côté application, des tentatives de modification de fichiers réapparues après restauration.

Un bon acteur d’hébergement ne fait pas “juste redémarrer”. Il vous aide à comprendre si le vecteur a touché l’environnement au-delà de WordPress.

Remettre le site en ligne: critères de validation

Remettre en ligne ne veut pas dire “ça marche”. Vous voulez des critères de validation qui réduisent les risques de retour immédiat.

Je valide généralement:

pages les plus visitées: aucune injection dans le HTML, pages où l’injection était observée: pas de script, pas de chargements externes, admin inaccessible aux comptes non autorisés, plugins et thèmes à jour, et seulement ceux qui doivent exister, pas de nouveaux utilisateurs ou tâches inattendues apparus depuis le nettoyage.

Le délai de validation compte aussi. Si vous voyez des signes dans l’heure, vous n’avez pas de garantie. Sur certains cas conditionnels, la persistance se réactive après un certain pattern. Attendre un peu, même quelques heures, peut changer votre conclusion.

Éviter les prochaines infections

Le mieux reste de réduire la surface d’attaque. WordPress est un écosystème, et votre sécurité dépend rarement d’un seul plugin. Il y a une discipline de maintenance, souvent moins glamour que la désinfection, mais plus rentable.

Concrètement, gardez à l’esprit:

minimiser les plugins: chaque extension est un point potentiel de vulnérabilité, surveiller les mises à jour: ne pas retarder trop longtemps, mais vérifier ce qui est sensible chez vous, durcir les accès: mots de passe uniques, limitation des tentatives, et idéalement un second facteur, sauvegardes fiables: au minimum, fichiers et base, et surtout test de restauration, journalisation: logs d’accès et logs d’erreurs, pour repérer tôt.

Quand on a déjà vécu une injection de script, on ne veut plus découvrir le problème en se basant uniquement sur des plaintes utilisateurs.

Ce qu’on peut attendre d’un nettoyage réussi

Un nettoyage réussi se mesure à un retour à la normalité, mais aussi à la stabilité dans le temps. La décontamination doit supprimer la source, pas seulement masquer le symptôme.

Si vous avez traité un cas d’injection, vous devriez voir:

un HTML propre sur les pages concernées, aucune requête réseau externe suspecte, aucune persistance dans les thèmes, plugins, ou données, et un site qui n’est plus re-pollué au fil des heures.

C’est exigeant, mais c’est le seul moyen d’éviter le cycle “on nettoie, puis on recommence”.

Si vous devez retenir une idée, c’est celle-ci: le nettoyage virus WordPress est une enquête, pas un coup de balai. Vous cherchez une chaîne complète, vous coupez la persistance, puis vous vérifiez. Une fois cette logique adoptée, même les injections les plus sournoises finissent par céder.