Quand un site WordPress commence à “agir bizarrement”, on a souvent l’impression que le problème est technique, presque abstrait. Puis on constate les effets concrets, page après page: redirections, pop-ups, scripts qui se chargent sans raison, comptes admin créés “tout seuls”, ou encore du JavaScript injecté dans le front. C’est à ce moment-là qu’il faut passer en mode intervention, pas en mode recherche de confort.
Dans cet article, je vais décrire une méthode réaliste pour enlever virus WordPress et, plus précisément, retirer les scripts JavaScript malveillants. L’objectif n’est pas seulement d’effacer du code visible, mais de supprimer la cause, limiter la réinfection, et reprendre la main proprement.
Comprendre ce que vous avez réellement (avant de “nettoyer au hasard”)
Les scripts malveillants sur WordPress ne se présentent pas tous sous la même forme. Certains injectent du JavaScript via un fichier “dormant” qui se déclenche uniquement selon l’agent utilisateur ou la géolocalisation. D’autres modifient des fichiers WordPress “légitimes” en ajoutant quelques lignes discrètes au début ou à la fin. Parfois, c’est le navigateur qui est trompé par une redirection côté client, parfois c’est le serveur qui sert du contenu altéré.
J’ai déjà vu des cas où la première impression était “c’est un plugin qui bug”, alors qu’en réalité il s’agissait d’un script dans un fichier minifié, caché à l’intérieur de wp-content/uploads, avec un chargement dynamique. À l’inverse, j’ai aussi vu des sites “propres” mais dont le navigateur affichait des comportements suspects parce que la page chargeait une ressource tierce compromise. Donc, avant d’attaquer les fichiers, il faut observer.
Une bonne première étape consiste à regarder les différences. Si, sur une même page, le HTML contient soudain des balises ou fragments de script supplémentaires, ou si des requêtes réseau apparaissent vers des domaines inconnus, vous avez une piste solide. Le navigateur (onglet Réseau), le “Voir le code source” et, si vous êtes à l’aise, une comparaison avec une version “ancienne” du thème ou d’un déploiement précédent, donnent une base tangible. Ce n’est pas glamour, mais c’est efficace.
Indices concrets de scripts JavaScript injectés
Sans faire de diagnostic à l’aveugle, vous pouvez repérer des signaux fréquents. Je les mets ici en prose et avec quelques exemples typiques, car ce sont ceux qui reviennent le plus souvent.
Un indicateur classique, ce sont des scripts qui appellent une URL avec un nom banal mais un chemin étrange, ou qui ajoutent une balise
Autre signal: le script se trouve dans les endroits où vous ne vous attendez pas à en voir. WordPress, ce n’est pas seulement wp-content/plugins et wp-content/themes. Des surprises arrivent aussi dans wp-includes, dans des fichiers racine, dans .htaccess, ou encore dans des fichiers “uploadés” qui n’ont l’air de rien mais servent ensuite de déclencheur.
Enfin, il y a les requêtes réseau vers des domaines inconnus. Si vous voyez des appels récurrents vers des hébergeurs non liés à votre site, même si le site “fonctionne”, c’est presque toujours un signe d’injection côté client.
Stopper l’hémorragie: isoler le site sans le casser
Avant de toucher au code, stabilisez. En pratique, cela veut dire: empêcher la modification d’être amplifiée pendant que vous inspectez.
Selon votre hébergement, vous pouvez mettre le site en maintenance, ou, au minimum, restreindre l’accès aux pages publiques le temps du nettoyage. J’ai déjà perdu du temps à analyser des fichiers pendant que le site continuait de générer des contenus infectés à grande vitesse. À ce moment-là, le “nettoyage” devient une course. L’option maintenance, même simple, aide énormément.
Si votre hébergement offre un mode “maintenance” ou une règle de firewall, c’est utile. L’idée est de réduire l’exposition, sans bloquer votre accès admin ni empêcher vos outils de scanner de fonctionner.
Préparer une reprise sûre: sauvegarde, image, et état initial
Pour enlever virus WordPress proprement, la sauvegarde n’est pas un détail. C’est votre filet de sécurité, surtout quand vous devez manipuler des fichiers du noyau, des thèmes, des plugins, et la base de données.
Si vous avez des snapshots, c’est le moment de s’en servir. Sinon, faites au minimum une copie de:
- les fichiers du site (au moins wp-content, la racine, et tout fichier modifié récemment), la base de données (dump), votre configuration, notamment wp-config.php.
J’insiste sur un point pratique: un dump de base de données “fait vite” est souvent insuffisant s’il manque des tables ou si vous oubliez les préfixes. Prenez le temps de vérifier le préfixe (par défaut wp_ mais ce n’est pas systématique), et assurez-vous d’avoir une copie cohérente.
Là où il faut chercher d’abord: wp-content, fichiers de thème, et scripts
La grande majorité des injections “JavaScript malveillants” qu’on voit en production passent par wp-content. Les trois zones à inspecter en premier sont le thème actif, les thèmes additionnels, et les plugins.
Le réflexe est de “désactiver les plugins”. Mais désactiver ne suffit pas si le script est déjà injecté dans un fichier de thème ou si des fichiers uploadés servent ensuite à charger du contenu malveillant. Donc, la désactivation est utile pour réduire l’activité, mais vous devrez ensuite inspecter manuellement ce qui a été modifié.
Dans un incident réel, je regarde presque toujours:
- les fichiers du thème actif, surtout ceux qui gèrent le rendu du front, les plugins qui ont des droits et exécutent du code au chargement des pages, les fichiers présents dans wp-content/uploads qui ont des dates de modification inhabituelles, et, point important, les fichiers qui ne “servent à rien” mais contiennent des fonctions qui ajoutent du script côté client.
Comment repérer rapidement? Une approche pragmatique consiste à comparer les dates de modification des fichiers (et surtout à repérer ceux qui ont été touchés récemment). Un fichier modifié le jour même de l’apparition des symptômes mérite une inspection ligne par ligne.
Vérifier les modèles d’injection les plus fréquents
Les injections JavaScript se font souvent en contournant les flux habituels de WordPress. Par exemple, certains ajouts se glissent dans des hooks, d’autres dans les fichiers de template, et d’autres encore via un chargement depuis un “faux” fichier.
Je vois souvent trois mécanismes récurrents:
1) ajout direct dans un fichier PHP qui s’exécute sur les pages publiques, puis création d’une balise script en JavaScript, 2) chargement d’un script externe depuis une URL mise en dur, souvent dissimulée dans une chaîne, 3) utilisation d’un fichier uploadé ou d’un fichier racine pour servir une charge utile, puis exécution côté navigateur.
Ce qui compte, ce n’est pas seulement la ligne supprimée, c’est la chaîne complète: comment le script arrive, où il est injecté, et ce qui le déclenche.
Insister sur la base de données: les champs qui “pilotent” l’injection
Un piège classique, c’est de ne nettoyer que les fichiers. Or, WordPress peut stocker des options qui déclenchent des comportements au chargement, ou contenir des balises injectées dans des zones administrables.
Dans la base, cherchez des éléments inhabituels:
- options dont la valeur ressemble à du code (balises, scripts), articles ou pages dont le contenu contient des scripts ajoutés, utilisateurs, métadonnées, rôles, et éventuellement des champs de configuration liés à des formulaires, tables de cache ou de transients contenant du code (ça arrive, même si ce n’est pas la majorité).
Je conseille de faire une recherche “texte” dans le dump sur des fragments caractéristiques, par exemple script, document.createElement, src=, ou même des domaines suspects vus dans les requêtes réseau. Quand vous trouvez une occurrence, recoupez où elle est utilisée. Supprimer une valeur sans comprendre peut casser une autre fonctionnalité, mais laisser la valeur peut maintenir l’infection.
Réinitialiser les accès: empêcher la réinfection via les comptes
Un autre scénario fréquent: l’attaquant garde une porte d’entrée. Il crée un nouvel utilisateur admin, modifie un rôle, ou installe un mécanisme d’exécution “discret” via un plugin qu’il contrôle.
Après avoir retiré les scripts visibles, je fais toujours un passage rapide sur:
- la liste des utilisateurs et leurs dates de création, les sessions actives si votre installation vous donne ce niveau de contrôle, les rôles et capacités, et l’historique de modifications.
Un point concret: si vous repérez un compte créé récemment, commencez par le supprimer ou le neutraliser, puis vérifiez si d’autres comptes ont été touchés. Parfois, l’utilisateur “fraude” s’accompagne d’un plugin nouvellement installé, ou https://gardewp.fr/nettoyage-malware-wordpress/ d’une option modifiée.
Corriger les éléments serveurs souvent négligés (racine, .htaccess, cron)
Les scripts malveillants ne se limitent pas aux fichiers WordPress internes. Sur certains hébergements, l’infection passe par la racine, par .htaccess, ou par des tâches planifiées (cron).
Côté serveur, deux endroits reviennent souvent dans les “incidents JavaScript”:
- .htaccess modifié: redirections, règles de rewrite, ou injections via des conditions, cron jobs: un script qui reconstruit ou réinjecte le contenu.
Si vous trouvez des règles de redirection vers un domaine inconnu, ou un cron qui pointe vers un fichier inattendu, vous tenez la mécanique. Vous pouvez retirer le script, mais si une tâche la réécrit, la salve suivante arrive vite.
Approche pratique: un plan de nettoyage qui marche sur le terrain
Voici une méthode opérationnelle. Elle privilégie la sûreté et la traçabilité, parce que c’est ce qui évite de “nettoyer” en remettant la même cause.
Étapes recommandées (dans l’ordre)
Mettre le site en maintenance ou limiter l’accès au public, le temps d’intervenir, Faire une sauvegarde complète des fichiers et de la base, même si vous pensez “que c’est simple”, Inspecter thème actif, autres thèmes, plugins, puis repérer les fichiers modifiés récemment, Chercher dans la base des occurrences de fragments de script ou de domaines suspects, et supprimer les options ou contenus injectés, Supprimer les comptes suspects, vérifier les cron, et remettre uniquement ce qui est fiable.Entre ces étapes, vous pouvez faire des tests légers, par exemple une page type (accueil, une page produit, un article), avec le navigateur et l’onglet Réseau. La réussite se mesure à l’absence d’appels vers des domaines inconnus, et à la disparition de fragments de script injectés dans le rendu.
Quand supprimer un plugin ne suffit pas
Il y a un moment où vous allez envisager de supprimer un plugin. C’est sain, mais il faut le faire intelligemment.
Si un plugin est suspect, vous pouvez le désactiver. Ensuite, inspectez son code source pour repérer une charge utile cachée. Si vous voyez un ajout du type “ajoute un script”, “redirection”, “chargement depuis une URL”, alors vous avez une preuve. Dans ce cas, supprimez le plugin et remplacez-le par la version propre depuis un canal officiel.
Attention à un détail: parfois, l’attaquant a mis son code dans les fichiers du thème plutôt que dans le plugin. Supprimer le plugin ne change rien, et vous perdez du temps à “nettoyer à côté”.
Récupérer une installation saine: réinstallation partielle ou totale
Sur certains incidents, vous pouvez nettoyer à la main. Sur d’autres, la meilleure décision est de restaurer un thème ou des fichiers WordPress à partir d’une version propre.
Je me suis déjà retrouvé sur des sites où trop de fichiers avaient été modifiés, de façon trop dispersée, avec des traces dans plusieurs dossiers. Dans ce contexte, restaurer wp-content complet à partir d’une sauvegarde antérieure (si elle est suffisamment ancienne) est souvent plus rapide que de “comprendre” chaque injection.
Un compromis fréquent: vous réinstallez le thème uniquement, ou vous remplacez les fichiers du noyau, pendant que vous conservez vos uploads si vous avez la preuve qu’ils ne sont pas la source. Mais si les uploads contiennent des fichiers suspects ou si vous voyez des chargements depuis uploads, alors garder la totalité peut prolonger le problème.
Contrôler la réussite sans se contenter d’un “ça marche chez moi”
Une vérification simple consiste à ouvrir le site, parcourir une page, et constater que “la redirection ne se produit plus”. C’est nécessaire, mais parfois insuffisant.
Les scripts malveillants conditionnent souvent leur action. Selon le navigateur, selon l’IP, ou selon la langue, le comportement change. Pour être plus sûr, je fais au minimum:
- test sur une fenêtre privée, test avec un autre navigateur, vérification de l’onglet Réseau pour repérer les requêtes externes non prévues.
Si vous aviez un domaine malveillant identifié, cherchez-le explicitement dans les requêtes. C’est un signal propre.
Deux types de “mauvais nettoyage” que je veux éviter pour vous
Je vois deux erreurs revenir, et elles coûtent cher, surtout quand le site est déjà indexé.
D’abord, supprimer uniquement la ligne JavaScript sans retirer le point d’injection côté serveur. Le site peut alors reconstituer le script au prochain chargement via un hook, une option, ou un fichier “générateur”.
Ensuite, réutiliser les mêmes fichiers infectés après réinstallation partielle. Par exemple, vous restaurez un thème “à moitié”, mais vous gardez un fichier modifié caché ou un dossier uploads touché. Résultat: l’infection revient, et elle est parfois plus difficile à diagnostiquer car vous avez changé d’autres éléments autour.
Le bon réflexe consiste à travailler “source par source”: chaque symptôme doit avoir une suppression correspondant à la cause.
Durcir WordPress après nettoyage pour limiter le retour
Une fois les scripts retirés, il faut empêcher l’attaque de revenir. Ce durcissement dépend de votre contexte (accès admin, hébergement, gestion des plugins), mais il y a des principes stables.
Je recommande notamment de:
- changer tous les mots de passe des comptes ayant des droits élevés, activer une authentification plus robuste si vous pouvez (au minimum une approche MFA si votre configuration la supporte), mettre à jour thèmes, plugins et WordPress, mais seulement après avoir validé la disparition des comportements suspects, réduire les plugins au strict nécessaire, plus il y en a, plus la surface augmente.
Si l’incident est arrivé via un plugin vulnérable ou abandonné, gardez une trace. La prochaine fois, vous saurez quels noms éviter.
Mini-guide de diagnostic rapide quand vous voyez “du JS ajouté”
Pour ne pas rester bloqué au stade “c’est quoi ce script?”, voici un diagnostic ciblé, sans en faire une enquête interminable.
1) Repérez dans le code source les balises script supplémentaires ou les ajouts qui ne devraient pas être là.
2) Identifiez le chemin qui sert ce code. Est-ce une ressource dans uploads, un fichier du thème, un fichier plugin, une route liée à un endpoint? 3) Cherchez ce mécanisme dans les fichiers PHP (hooks, template tags, fonctions d’insertion). 4) Confirmez en base si une option ou un contenu contient déjà l’injection. 5) Enfin, supprimez la source, pas seulement le symptôme.Si vous devez choisir où commencer, commencez par le thème actif et les plugins récemment ajoutés ou modifiés, puis élargissez à la racine et à la base.
Exemple concret: le scénario “le script est dans le rendu, pas dans le code affiché”
Sur un incident que j’ai traité, l’équipe voyait des pop-ups et des redirections sur certaines pages, mais pas partout. En inspection, on a constaté que le HTML ne montrait pas beaucoup de choses, sauf au moment où la page chargeait un script dynamique depuis une URL externe. Le code injection était côté PHP dans un fichier du thème, avec une condition discrète.
Ce qui a fait gagner du temps, c’est d’ouvrir le site, puis de comparer le code source obtenu avec une version saine du thème. Le delta était minuscule, quelques lignes. Une fois retirées, les symptômes ont cessé immédiatement. Ensuite, on a quand même vérifié la base et les utilisateurs, parce qu’une condition dans le thème peut être le “dernier maillon”, pas la totalité de la chaîne.
Ce cas résume bien l’approche: l’injection se voit parfois peu, mais sa source se trouve souvent dans des fichiers qui s’exécutent sur chaque page.
Sécuriser votre processus de maintenance pour éviter la prochaine infection
Nettoyer WordPress n’est pas seulement “technique”, c’est aussi organisationnel. Une fois que vous avez réglé le problème, mettez en place des habitudes qui réduisent le risque.
La meilleure barrière n’est pas un seul plugin anti-malware. C’est un cycle régulier: mises à jour, réduction des plugins, sauvegardes testées, et contrôle des modifications. J’ai vu des équipes mettre en place des alertes de changement sur les fichiers sensibles et sur les créations d’utilisateurs. Dans un incident, ces alertes vous donnent une chronologie, et une chronologie réduit énormément le temps de diagnostic.
Quand faire appel à un spécialiste
Il y a des situations où on gagne du temps avec une expertise spécialisée, notamment quand:
- vous ne pouvez pas accéder aux fichiers en lecture détaillée, le site est largement réinfecté entre deux tentatives, des règles serveur complexes sont en jeu, ou si vous devez coordonner nettoyage, sécurité, et reprise SEO.
Dans ces cas, une intervention extérieure peut aussi aider à documenter les modifications et à remettre un environnement de confiance.
Récapitulatif opérationnel (sans magie)
Retirer les scripts JavaScript malveillants dans WordPress, c’est surtout une affaire de méthode: observer, isoler, sauvegarder, identifier la source, supprimer, puis vérifier. Ce n’est pas seulement une question de “nettoyer ce que je vois”.
Quand tout est fini, vous devriez pouvoir répondre clairement à ces questions:
- D’où venait le script côté navigateur. Quel fichier PHP ou quelle donnée en base l’insérait. Qu’est-ce qui empêchait la réinfection (comptes, cron, tâches, règles serveur). Comment vous avez vérifié, au-delà d’un simple affichage “normal”.
Si vous appliquez cette logique, enlever virus WordPress devient moins un stress permanent, et plus une procédure maîtrisable, même quand l’attaque est sale et discrète.
Si vous me décrivez le type de symptôme (redirection, pop-ups, URL inconnues observées, message d’erreur, et ce que vous voyez dans le code source), je peux vous aider à orienter le périmètre de recherche: thème, plugin, uploads, base, ou serveur.