Quand on découvre un site WordPress infecté, la première réaction est souvent émotionnelle, puis très vite technique. On regarde les plugins, on vérifie les mises à jour, on pense au thème, aux fichiers modifiés. Pourtant, dans beaucoup d’incidents réels, le nœud du problème n’est pas “un plugin malveillant” au sens classique. C’est une injection de script, parfois discrète, parfois massive, qui détourne WordPress ou les visiteurs pour exécuter du code.
Ce type d’attaque peut rester invisible longtemps, surtout si elle ne casse pas le site. Une page peut continuer à s’afficher comme avant, tandis que des scripts se chargent en arrière-plan, changent le contenu au moment du chargement, ou exfiltrent des données en exploitant des formulaires et des sessions.
Comprendre ce qui se passe, c’est gagner du temps. Pas uniquement pour “supprimer ce qui gêne”, mais pour éviter que l’infection revienne dès la première remise en ligne.
Ce que “l’injection de scripts” veut dire, concrètement
Une injection de scripts, dans le contexte WordPress, désigne une situation où du code malveillant est inséré dans l’environnement d’exécution de votre site. Le code peut être injecté dans :
- des fichiers PHP du thème ou des plugins, des fichiers de WordPress (core) ou des fichiers “temporaires” déposés sur le serveur, des pages ou fragments stockés en base de données, des paramètres, par exemple des fichiers robots ou des redirections.
Le point important, c’est que l’objectif n’est pas toujours de “défigurer” le site. Souvent, l’objectif est fonctionnel. Le script peut, par exemple, charger en cascade des scripts distants, injecter du JavaScript dans le HTML, ou déclencher une redirection selon le navigateur, l’IP, l’heure, la géolocalisation, ou une variable de session. Cette logique conditionnelle rend les tests “au clic” peu fiables.
J’ai déjà vu des cas où le site semblait correct à l’écran tant qu’on restait dans un navigateur “standard”. Sur certains navigateurs ou avec une identité différente (utilisateur non connecté, autre langue du navigateur, ou simple variation d’en-têtes), le contenu changeait. Les attaquants exploitent précisément cette fragilité du contrôle humain.
Les formes les plus fréquentes d’injection dans WordPress
Il n’y a pas un seul modèle d’attaque. En revanche, on retrouve des patterns qui reviennent, parce qu’ils sont pratiques pour les attaquants et difficiles à repérer à l’œil.
Injection côté PHP dans des fichiers “valides”
Un scénario classique consiste à modifier un fichier PHP qui est censé être légitime, comme un fichier du thème (functions.php, header.php, ou un template) ou un plugin. Le script ajouté est souvent minuscule par rapport au reste du fichier, avec une logique conditionnelle.
Ce que vous verrez rarement, c’est une modification immédiatement évidente. Plus souvent, c’est une poignée de lignes qui :
- décodent une charge utile encodée (base64, gzcompress, substitution), vérifient des conditions (utilisateur, referer, chemin, présence d’un cookie), exécutent ensuite un contenu distant ou injectent une chaîne dans la page.
Le piège psychologique est de regarder uniquement la taille du fichier ou de comparer “au contenu attendu”. Or un ajout de quelques dizaines de lignes dans un coin du code peut suffire.
Injection via base de données, notamment via contenu “stocké”
WordPress stocke beaucoup de choses en base : contenus des articles, pages, options, métadonnées. Une injection peut alors passer par des zones d’administration compromises, un éditeur utilisé par l’attaquant, ou un champ qui accepte du HTML ou du shortcode.
Même si vos fichiers ne changent pas, le site peut devenir dangereux. On peut avoir des pages “normales”, mais avec des fragments qui déclenchent du JavaScript au chargement, parfois seulement pour certains visiteurs.
Sur des sites très personnalisés, j’ai vu des injections dans des champs de type “description de catégorie” ou dans des variantes de champs gérés par un constructeur. Ce n’était pas une “section évidente”, mais le code y était pourtant.
Injections dans les hooks et les “points d’extension”
WordPress est conçu pour être extensible. C’est une force, mais c’est aussi une surface d’attaque. Les injections peuvent s’appuyer sur des hooks comme wp head, wpfooter, init, ou sur des filtres qui manipulent le HTML.
Quand l’attaquant vise le front, l’approche consiste souvent à “brancher” un morceau de JavaScript via un hook de sortie. Résultat : vous pouvez avoir l’impression que votre thème n’a rien, mais le contenu sort malgré tout.
Scripts distants, qui compliquent l’analyse
Autre caractéristique : l’injection peut être un simple déclencheur. Le code local ne fait qu’appeler une ressource distante qui contient la logique. Ainsi, pendant l’audit rapide, vous cherchez du code dans le site, mais ce qui compte est ailleurs.
Dans ce cas, même un nettoyage “fichier par fichier” peut sembler efficace, mais la logique peut revenir, car l’attaquant a laissé une méthode de rappel, par exemple une tâche planifiée, un hook récurrent, ou une réécriture.
Où l’injection trouve son point d’entrée
Pour corriger durablement, il faut comprendre l’amont. Une injection de scripts est la conséquence. La cause est souvent dans l’accès.
Quelques scénarios typiques :
- compte administrateur compromis via mot de passe faible, réutilisation, ou tentative de connexion, plugin ou thème avec vulnérabilité, permettant d’écrire dans des zones où l’attaquant peut déposer du code, uploads de fichiers mal protégés, modifications d’options WordPress (par exemple des options qui déclenchent des chargements de ressources), accès FTP ou accès serveur trop permissif, ce qui permet à l’attaquant de déposer des scripts sans toucher au niveau WordPress.
Le “point d’entrée” compte parce que la correction ne doit pas se limiter au nettoyage du symptôme. Si vous supprimez le script injecté sans corriger la faille d’accès, vous verrez l’infection revenir, parfois avec des variantes.
Symptômes qui orientent le diagnostic
Les symptômes d’un site infecté varient énormément. Certains sont spectaculaires : redirections en chaîne, affichage de pop-ups, pages de phishing. D’autres sont plus subtils : ralentissement, contenu modifié sur une partie des pages, requêtes réseau inhabituelles dans les DevTools.
Quand je fais une première cartographie, je cherche des signaux concrets, sans conclure trop vite.
On peut, par exemple :
- repérer dans les fichiers des occurrences de fonctions d’exécution et de décodage (selon votre contexte, ce n’est pas une preuve absolue, mais un indice), observer des requêtes vers des domaines inconnus lors du chargement de certaines pages, constater des modifications sans lien avec vos déploiements (horodatages, hash de fichiers, changement de taille), trouver des comptes utilisateurs nouveaux, ou des rôles élevés attribués sans raison.
Il est utile de rappeler un point pratique : la présence de scripts dans un thème ou un plugin n’est pas toujours une infection. Certains sites chargent volontairement des ressources tierces, et des libs peuvent inclure des minifications ou des encodages. L’enjeu, c’est la cohérence. Si cela n’existait pas avant, ou si c’est déclenché de façon conditionnelle et opaque, la suspicion augmente.
Diagnostiquer sans “casser pour mieux voir”
Le diagnostic d’une injection doit être méthodique. L’erreur fréquente est de “nettoyer trop vite” en remplaçant https://gardewp.fr/nettoyage-malware-wordpress/ des fichiers, ce qui efface des indices utiles. Une autre erreur est d’isoler le serveur trop tard, en laissant l’attaquant garder la possibilité de mettre à jour la charge utile.
Un bon réflexe est de partir d’un état reproductible :
Préservez l’état. Mesurez ce qui sort (requêtes, comportements). Reliez le comportement à une zone du code.Concrètement, avant de toucher à quoi que ce soit, je recommande de dupliquer le site ou de travailler sur une copie. Vous aurez besoin de comparer les fichiers, les hashes, et de vérifier les différences de base de données.
Pour gagner du temps, vous pouvez aussi observer le comportement avec deux ou trois conditions de test. Par exemple : utilisateur connecté et non connecté, page d’accueil et une page interne, un navigateur “propre” et un navigateur habituel.
Plan d’action quand vous suspectez une infection par injection
Voici une approche pragmatique, orientée “réduction du risque”, sans promesses irréalistes.
Isoler et limiter l’exposition, idéalement en passant le site en maintenance, ou en le rendant accessible uniquement à votre équipe via restrictions au niveau serveur ou pare-feu. Faire une copie intégrale, fichiers et base, puis calculer un état de référence (dates, hashes, taille des répertoires WordPress et des extensions). Analyser les points probables : fichiers de thème et plugins modifiés récemment, utilisateurs WordPress ajoutés, options inattendues, et ressources chargées depuis le front. Vérifier l’amont d’accès : comptes, journaux de connexion, activités plugin, clés API, accès FTP ou SSH, permissions système. Nettoyer en profondeur, pas seulement en supprimant des lignes : réinstaller WordPress et les composants compromis depuis des sources maîtrisées, puis régénérer identifiants, clés, et rôles.Cette séquence évite deux écueils : effacer la preuve trop tôt et oublier que le vecteur d’entrée peut rester actif.
Comment “nettoyer” correctement une injection, sans revenir en arrière
“Nettoyer” ne veut pas dire seulement enlever un fichier ou retirer une ligne suspecte. Dans les injections, il faut souvent casser une chaîne complète : déclencheur, stockage de données, récupération distante, persistance.
La stratégie la plus robuste, quand vous avez des doutes sérieux, consiste à repartir sur une base saine, tout en conservant vos contenus légitimes. WordPress lui-même et ses dépendances doivent revenir à un état connu.
En pratique, vous pouvez :
- réinstaller WordPress core depuis une source fiable, réinstaller les thèmes et plugins suspects depuis leurs versions exactes (ou supprimer ceux dont vous n’êtes pas sûr), nettoyer la base de données des zones où l’attaquant a pu écrire (options, champs, scripts stockés), supprimer les comptes utilisateurs créés ou escaladés, vérifier les tâches planifiées, webhooks, ou intégrations externes.
Le compromis, c’est le temps et les dépendances. Si vous avez un thème hautement modifié, une réinstallation brute peut vous faire perdre des personnalisations si vous n’avez pas de version de référence. C’est pour cela que la copie initiale et la comparaison sont cruciales.
Exemple de scénario : injection qui n’altère pas le rendu immédiat
Imaginons un site e-commerce WordPress. Vous constatez un ralentissement léger sur certaines pages, et un outil de sécurité côté navigateur signale “scripts chargés depuis une source inconnue”. En ouvrant les DevTools, vous voyez une requête vers un domaine non déclaré dans votre liste de fournisseurs.
En inspectant le HTML généré, vous découvrez un bloc script ajouté dans le header, ou une balise qui appelle un fichier JavaScript dynamique. Vous comparez la version de votre thème en local, et vous trouvez des différences dans functions.php : quelques lignes qui utilisent une logique conditionnelle, par exemple “si l’URL contient telle route, alors injecter tel fragment”.
Si vous supprimez seulement les lignes visibles, sans toucher aux déclencheurs côté base ou aux comptes compromis, l’attaquant peut réinjecter au prochain chargement, ou via une autre route. Le nettoyage doit donc viser la persistance.
Ce cas illustre pourquoi il faut suivre le comportement, pas uniquement le code.
Hardening, après la purge, pour que ça ne recommence pas
Une fois le site assaini, la question revient toujours : comment limiter le risque d’une nouvelle injection de scripts ?
Ce n’est pas une recette universelle. Tout dépend de votre stack, du niveau d’exposition, et de la maturité de vos accès. Mais il y a des mesures qui, à la pratique, changent vraiment la donne.
Vous pouvez agir sur :
- la gestion des comptes et des rôles, avec suppression des comptes inutiles et politique de mots de passe réaliste, la réduction de la surface plugin, en supprimant ce qui ne sert pas et en verrouillant les mises à jour, la limitation des permissions d’écriture, et la surveillance des modifications de fichiers, la mise en place de contrôles d’intégrité et d’alertes.
J’ai aussi constaté que la moindre dérive de permissions (dossier en écriture trop large, accès FTP partagé, “tout est modifiable par tout le monde”) transforme un incident ponctuel en incident récurrent. La sécurité n’est pas un verrou, c’est une discipline de limites.
Les pièges qui font perdre des semaines
Certains pièges sont “classiques”, et ils finissent par coûter cher, y compris en stress.
Le premier : croire que la suppression d’un fichier suffit. Si l’injection s’appuie sur une configuration dans la base, ou sur un script chargé à distance, la suppression partielle ne tient pas.
Le deuxième : remplacer WordPress et les plugins, mais laisser intactes des options et des données déjà contaminées. Dans WordPress, beaucoup de comportements viennent de la base, pas uniquement des fichiers.
Le troisième : oublier l’amont serveur. Un attaquant qui a gardé un accès via une clé SSH, un compte système, ou un paramètre serveur, peut réamorcer la même attaque.
Le quatrième : ne pas vérifier les logs. Sans logs, vous roulez à l’intuition. Or les injections sont souvent déclenchées par des événements répétitifs. Les journaux vous montrent parfois un pattern, un pic de tentatives, ou un chemin d’accès récurrent.
Comment détecter plus vite la prochaine injection
Vous ne pourrez pas tout empêcher, mais vous pouvez réduire le délai entre l’apparition et votre réaction.
Sans tomber dans des outils “magiques”, je conseille d’avoir des repères internes :
- un suivi de la liste des comptes WordPress, une surveillance des modifications de fichiers (au moins les répertoires qui comptent, thème, uploads, plugins), une vérification régulière des domaines et scripts chargés au front, une procédure d’audit après chaque déploiement.
Si vous gérez plusieurs sites, le gain est énorme quand vous consolidez vos habitudes de tri et d’analyse. Le jour où un signal de sécurité arrive, vous ne partez pas de zéro.
Quand faire appel à un spécialiste
Il y a des cas où l’intervention doit être rapide et externe, surtout si :
- vous avez des contraintes de continuité d’activité strictes, le site traite des données sensibles, l’infection est polymorphe ou se réactive de manière difficile à reproduire, vous observez des impacts de type redirections, mais sans trace claire.
Faire appel ne dispense pas de la préparation. Un intervenant aura besoin d’une copie, des logs, de la chronologie, et de votre analyse initiale. Ce que vous aurez documenté, même à petits pas, lui permettra de gagner un temps précieux.
WordPress, l’injection et la “confiance” dans votre contenu
Il existe aussi une dimension psychologique, et elle compte. Quand un site a été compromis, la question “est-ce que tout est fiable ?” revient sur vos pages, vos formulaires, vos emails, parfois même vos flux.
Une injection de script peut affecter les visiteurs sans que vous touchiez au contenu “visible”. Vous pouvez donc conserver des articles identiques visuellement, tout en ayant une contamination active dans le code rendu.
Dans ce type de contexte, reconstruire la confiance prend du temps : analyse, purge, réinstallation, contrôle, puis surveillance post-remise en ligne. Ce n’est pas une punition, c’est une manière de redonner de la maîtrise.
À retenir : comprendre la chaîne, pas seulement la trace
Un script injecté est comme une poignée de main trompeuse. Il se voit, mais il ne montre pas forcément l’origine. Pour corriger un site WordPress infecté, il faut relier trois éléments : le déclencheur (où le code est inséré), le vecteur (comment l’accès a été obtenu), et la persistance (comment l’attaque revient).
Quand vous construisez cette compréhension, vous passez d’une logique de “suppression de symptômes” à une logique de remise en sécurité. Et c’est là que la différence se fait, sur le long terme, quand l’incident ne se contente plus de disparaître, il ne revient plus.
Si vous voulez, décrivez votre cas en quelques lignes (symptômes observés, plugins récemment ajoutés, comportement selon navigateur ou utilisateur). Je peux vous aider à formuler des hypothèses de diagnostic et une stratégie de vérification ciblée, sans hypothèses extravagantes.