Une désinfection WordPress ne ressemble pas à une simple “mise à jour et on verra”. Quand un site commence à rediriger vers des pages bizarres, quand des scripts inconnus apparaissent au cœur des pages, ou quand la base de données se remplit de lignes qui n’ont rien à voir avec votre contenu, on n’est plus dans le confort. On est dans l’enquête.
J’ai déjà vu des infections qui laissent des traces très discrètes, suffisamment pour que tout “fonctionne” encore. Visiteurs et moteurs de recherche finissent toutefois par tomber sur du contenu injecté, des iframes externes, des redirections en chaîne, ou des formulaires qui ne vont nulle part. Le piège, c’est de traiter le symptôme sans éliminer la cause. Les injections de code reviennent, parfois en changeant légèrement de forme, parce qu’un mécanisme persistant continue à se nourrir de votre site.
Le bon réflexe consiste à comprendre ce qui a été ajouté, comment l’attaquant s’est gardé un accès, et à nettoyer au bon endroit, au bon niveau de profondeur.
Les injections de code, concrètement, ça ressemble à quoi ?
Une injection de code, sur WordPress, peut se manifester à plusieurs étages. Les attaquants visent souvent des points où du code ajouté “se répercute” automatiquement sur la génération de pages.
Par expérience, trois formes reviennent souvent :
D’abord, le code injecté dans des fichiers PHP côté serveur. Par exemple, des lignes cachées ajoutées dans un thème ou dans un plugin. Souvent, la charge utile est minifiée, noyée dans des conditions ou masquée derrière une base64. Visuellement, vous ne verrez parfois qu’une ou deux lignes ajoutées au milieu, avec un nom de fonction ou une variable “banale”.
Ensuite, les injections via la base de données. WordPress stocke beaucoup de choses en base, et certains champs ou méta peuvent être modifiés pour afficher du contenu indésirable à des endroits précis. Dans ces cas, les fichiers du thème peuvent paraître “propres” alors que le site injecte toujours quelque chose, car la logique s’appuie sur des valeurs stockées.
Enfin, le code injecté dans des assets ou des fichiers chargés en premier. Un script malveillant peut s’ajouter dans une feuille CSS ou dans un fichier JavaScript “apparemment anodin”, ou bien être déclenché via une balise HTML insérée dans le thème. Les effets sont alors côté navigateur : redirections, exécution de scripts externes, collecte de données, ou chargement de contenus à la demande.
Le signal le plus utile, ce sont les différences. Si votre site a toujours chargé le même ensemble de ressources, puis soudainement une nouvelle URL apparaît, ou un script inconnu se charge avant même votre contenu, c’est un indice fort. Une désinfection WordPress propre démarre par la comparaison, pas par la supposition.
Distinguer l’infection “visible” du code persistant
Un point frustrant, c’est que tout n’est pas égal.
Certaines infections sont “statiques”. Le code a été ajouté, il s’exécute, mais il ne modifie pas tout seul. Si vous supprimez la portion malveillante, tout s’arrête généralement.
D’autres infections sont “dynamiques” ou persistantes. Elles utilisent un mécanisme de re-planting. L’attaquant peut avoir mis en place un système pour réintroduire le code, selon un déclencheur (au prochain chargement, toutes les X minutes, quand un plugin est activé, quand un fichier est modifié, etc.). Dans ce cas, vous pouvez nettoyer une première fois, puis constater une réapparition le lendemain.
Le mécanisme persistant se trouve fréquemment dans :
- un fichier PHP légèrement modifié dans un thème ou un plugin, un fichier placé dans un dossier “exotique” que WordPress ne devrait pas utiliser, une entrée dans la base de données, parfois liée à des paramètres de plugin ou à des options, ou un accès légitime obtenu par l’attaque (compte administrateur, jeton, capacité d’ajouter du code via un champ non prévu, etc.).
C’est pour cela que la désinfection WordPress sérieuse ne se limite pas à “effacer ce que vous voyez”. Elle doit vérifier la persistance. Sinon, vous travaillez en boucle.
Les voies d’entrée les plus fréquentes sur WordPress
Je ne vais pas lister des causes au hasard, mais en pratique, les vecteurs d’accès reviennent souvent. Ce n’est pas une question de “mauvaises pratiques” abstraites, c’est presque toujours une combinaison de :
Un WordPress pas à jour ou incomplet. Les mises à jour corrigent des failles, mais elles n’effacent pas les altérations déjà faites. Si l’attaque a réussi avant la mise à jour, rester “un peu derrière” peut garder la porte ouverte.
Des plugins ou thèmes non maintenus. Un plugin ancien peut devenir le point d’atterrissage idéal, notamment si vous lui avez accordé des permissions larges. J’ai vu des sites où un seul plugin “abandononné” portait la totalité du risque, même quand le reste était à jour.
Des identifiants exposés. Un compte compromis, parfois via réutilisation de mot de passe, parfois par brute force, parfois après un phishing. Quand l’attaquant a un accès admin, la désinfection se complique parce qu’il peut modifier des contenus et installer du code “comme s’il s’agissait de vous”.
Un manque de durcissement. Sans limitation de tentatives, sans surveillance des modifications de fichiers, sans journalisation, l’intrus a plus de temps pour préparer un retour. Et sans rotation des clés ou vérification des sessions, l’accès peut rester valide même après une première suppression.
Une bonne approche consiste à considérer l’attaque comme un incident, pas comme une simple panne logicielle. Vous voulez expliquer comment l’attaquant est entré, même si vous ne pouvez pas remonter à l’instant exact.
Commencer par les symptômes : ce que vous devez observer dès maintenant
Avant de supprimer quoi que ce soit, prenez des captures et conservez des éléments. Je parle ici d’observation, pas de collecte lourde. L’objectif est de ne pas effacer trop vite ce qui pourrait vous aider à identifier le point d’injection.
Les symptômes typiques, côté admin et côté visiteur, incluent :
- des redirections vers des domaines qui ne correspondent pas au vôtre, l’apparition de mots-clés non pertinents dans le HTML rendu, des iframes ou scripts chargés depuis des domaines étrangers, une hausse anormale des requêtes réseau, ou des erreurs PHP uniquement sur certaines pages.
Un détail que je regarde souvent : l’endroit exact où le code apparaît dans le HTML final. Si le code se trouve dans le head, c’est souvent lié à une injection dans le thème, dans un hook, ou via des options utilisées par un plugin. Si cela se trouve dans le corps, on pense plutôt à un filtre qui modifie le contenu, à un shortcode piégé, ou à un champ de page injecté.
Si votre hébergeur fournit des logs de requêtes ou un accès aux journaux PHP, ils peuvent aider, surtout quand vous associez des timestamps à la période d’apparition.
Où chercher, sans se perdre : logique d’enquête par profondeur
Le risque en désinfection WordPress, c’est de passer trop de temps à “tout refaire” sans cible. Ce type d’action peut casser votre site, ou pire, détruire des indices sans enlever la persistance.
Je travaille généralement en profondeur, du plus probable vers le plus “spécifique”.
D’abord, thèmes et plugins. Même si le site n’utilise que quelques extensions, ce sont elles https://gardewp.fr/ qui ont la capacité d’accrocher du code au rendu. Un fichier qui a été modifié récemment est un bon suspect, mais on peut aussi avoir une modification plus ancienne, masquée, qui n’a pas attiré l’attention.
Ensuite, les fichiers “racine” et les fichiers spécifiques WordPress. Les injections peuvent être faites dans des fichiers chargés au démarrage. Un simple append dans un fichier de configuration peut suffire à déclencher une charge utile discrète.
Puis, la base de données. Quand la logique d’injection dépend de valeurs stockées, vous pouvez nettoyer les fichiers sans effet. Par exemple, un champ option peut contenir un script qui s’insère via un hook. Une autre variante consiste à modifier des métadonnées de posts pour déclencher un contenu sur des pages précises.
Enfin, les comptes et permissions. Un mot de passe changé ne supprime pas forcément une persistance si un compte compromis existe encore, si un rôle admin a été ajouté, ou si des sessions restent valides.
Cette progression évite la chasse aux “symptômes” et favorise l’élimination du point de contrôle.
Identifier le code malveillant : repères pratiques
Il est tentant de chercher “ce qui ressemble à du malware”. En réalité, le code malveillant peut être très stylé, propre, presque “projet”. Les attaquants savent intégrer leur logique dans des structures WordPress.
Ce que je recommande, c’est de repérer les signaux faibles, ceux qui trahissent une insertion récente ou une logique étrangère au fonctionnement habituel du site :
Les modifications de fonctions ou de hooks. Par exemple, voir apparaître une logique qui “enveloppe” le contenu d’un post, ou qui ajoute des scripts seulement pour certaines conditions (langue, rôle, pays, page). Les conditions sont parfois très larges, mais un détail technique peut confirmer l’infection, comme une variable non utilisée auparavant ou un appel inattendu.
Les chaînes obfusquées. Base64, gzinflate, str_rot13, concaténation de morceaux. Ce n’est pas une preuve absolue, car du code légitime peut utiliser ces techniques. Mais sur un site WordPress “standard”, si vous voyez une obfuscation dans un fichier de thème qui n’en avait pas avant, c’est un drapeau rouge.
Le chargement externe. Une requête vers un domaine non lié à votre stack. Si votre site ne consomme aucun service externe, et qu’un nouveau script arrive depuis un domaine nouveau, c’est un indice fort. Il faut toutefois vérifier que vous ne confondez pas avec un outil marketing légitime.
Les fichiers ajoutés. Un dossier avec un nom étrange, un fichier PHP avec un “include” conditionnel, ou un script qui s’exécute uniquement dans certaines circonstances.
La meilleure preuve, ça reste la comparaison. Avoir un backup du même site juste avant l’incident, même s’il date de quelques jours, accélère énormément. Sinon, vous pouvez comparer votre code actuel à une version saine de vos fichiers (en refaisant une installation propre des thèmes et plugins que vous utilisez, puis en comparant).
Repères rapides (ce que je vise en priorité)
Ciblage sur les fichiers modifiés récemment (date de modification). Recherche des appels inhabituels à des fonctions d’exécution, d’obtention de contenu distant, ou de décodage. Comparaison HTML rendu entre une page saine supposée et une page infectée. Vérification des options WordPress, notamment celles liées à l’insertion de scripts. Contrôle des comptes et rôles, avec suppression de tout accès non justifié.(La liste ci-dessus n’est pas une procédure pas à pas, plutôt un filtre mental, pour ne pas tout traiter au même niveau.)
Étape de nettoyage : supprimer l’injection, puis couper la persistance
Une désinfection WordPress se déroule souvent en deux temps : retirer la charge utile, puis empêcher la réinfection.
La suppression “propre” implique de ne pas seulement effacer la ligne visible. Quand vous supprimez un morceau de code injecté, vérifiez aussi les dépendances : fichiers appelés, classes ajoutées, variables utilisées. Une injection peut être fractionnée sur plusieurs emplacements.
Sur les thèmes et plugins, la méthode la plus sûre est souvent de remplacer les fichiers par ceux d’une version saine. Le point clé, c’est de ne pas conserver des fichiers corrompus. Si vous avez une version saine (source officielle, ZIP du plugin, copie Git), vous remplacez, puis vous réappliquez uniquement vos modifications légitimes.
Sur la base de données, vous supprimez ou corrigez les champs modifiés. Mais attention aux approches “au hasard”. Une option supprimée peut casser un plugin légitime ou désactiver une fonctionnalité. Je privilégie l’analyse du contenu avant suppression : quel champ a été altéré, quel plugin l’utilise, quel est son rôle.
Si la persistance vient d’un compte compromis, la logique change. Vous pouvez nettoyer le code et voir le site rester infecté, parce que l’attaquant réinjecte via une interface. Dans ce cas, vous devez traiter l’accès en premier : suppression des comptes non reconnus, rotation des clés, invalidation des sessions actives, et reprise de contrôle.
La difficulté, c’est que vous pouvez être tentés de “faire vite”. Sur WordPress, faire vite peut provoquer une réinfection, surtout quand l’attaquant est encore en ligne, ou quand il reste un mécanisme d’automaintenance.
Exemple de scénarios, pour comprendre pourquoi “ça revient”
J’ai en tête deux situations typiques.
Dans la première, tout semblait venir d’un thème. Le code malveillant était dans un fichier du thème enfant. En le supprimant, le site cessait de rediriger. Puis, deux jours plus tard, les redirections revenaient. En crevant le problème plus profondément, on a découvert que le compte admin compromis réinjectait le code à la prochaine session. Le même fichier avait été modifié avec une charge utile identique, mais légèrement reformulée.
Dans la seconde, les fichiers du thème étaient propres. Pourtant, des scripts apparaissaient dans le HTML rendu. La base de données contenait une option qui servait à injecter un fragment de code via un hook. Le remplacement des fichiers n’avait rien changé, car la source de l’injection était ailleurs. On n’a réussi à stabiliser le site qu’en corrigeant l’option contaminée, puis en vérifiant l’absence de plugin supplémentaire caché.
Ces cas montrent un principe simple : si vous ne traitez que l’apparence, vous restez exposé à la persistance.
Sécurité et nettoyage : éviter les fausses bonnes idées
Certaines actions semblent évidentes, mais peuvent compliquer une désinfection WordPress.
Par exemple, remplacer un dossier thème ou plugin sans vérifier les personnalisations. Sur un site réel, il y a souvent du code ajouté au fil du temps : fonctions du thème enfant, overrides, templates custom. Remplacer “à l’aveugle” peut vous faire perdre des éléments et vous laisser une version cassée, ce qui rend ensuite la remontée du problème encore plus difficile.
Autre piège : chercher uniquement du code malveillant dans les fichiers, alors que l’injection est alimentée par la base de données ou par un paramètre stocké. Vous effacez le symptôme et vous le revoyez revenir.
Enfin, nettoyer sans changer le mode de contrôle de l’accès. Si un compte a été compromis, ou si un identifiant admin reste valide, vous pouvez nettoyer autant que vous voulez, l’attaquant aura la capacité de remettre la charge utile.
Dans tous ces cas, la qualité de la désinfection dépend moins de “l’outil” que de la méthode de validation après correction.
Comment valider que la désinfection a réellement fonctionné
Une fois que vous pensez avoir supprimé l’injection, il faut valider, pas seulement “recharger la page”.
Je fais en général une validation à trois niveaux : rendu, chargements externes, et cohérence du code.
Le rendu doit être identique à votre fonctionnement normal. Si vous aviez une mise en page stable, comparez des pages types (accueil, une page standard, une page de blog, éventuellement une page qui utilisait un template spécifique). Faites-le sur plusieurs navigateurs, pour éviter qu’un effet ne soit perceptible dans un seul environnement.
Ensuite, examinez le HTML final. Si vous aviez remarqué un script étranger, cherchez s’il est toujours présent. Si vous aviez observé une redirection, vérifiez qu’elle ne déclenche plus.
Enfin, vérifiez que le code suspect n’est plus dans les fichiers ou la base. Un “je ne le vois plus” visuel n’est pas suffisant si vous aviez une injection obfusquée, car elle peut rester partiellement présente.
La validation est aussi un moment pour surveiller. Sur une fenêtre de 24 à 72 heures, en fonction du niveau d’activité, si de nouveaux signaux apparaissent, c’est que vous n’avez pas atteint la persistance.
Mettre les protections en place après le nettoyage
La partie la plus sous-estimée, c’est la prévention post désinfection WordPress. Nettoyer une fois, puis laisser les mêmes failles d’accès, c’est accepter de recommencer.
Il existe plusieurs améliorations utiles, mais elles doivent être adaptées à votre contexte. Un verrouillage trop agressif peut bloquer vos propres actions.
Sans transformer ça en catalogue, les mesures que je considère vraiment prioritaires après une infection sont : réduire les surfaces d’attaque (versions à jour, suppression des plugins inutiles), renforcer l’accès (mots de passe uniques, limitation des tentatives, révocation des sessions si un compte a été compromis), et surveiller les changements (fichiers modifiés, événements admin, mises à jour inattendues).
Je garde aussi une règle pragmatique : si vous avez un thème enfant très personnalisé, gardez une trace claire de ce qui est custom. Vous saurez quoi réappliquer après un remplacement propre des fichiers.
Quand faire appel à quelqu’un, et quand vous pouvez traiter en interne
Il n’y a pas de honte à demander de l’aide. Une désinfection WordPress peut être simple quand l’injection est localisée et que la persistance est absente. Elle devient plus difficile quand il y a plusieurs couches, des plugins ajoutés, des redirections complexes, ou un accès admin compromis.
Faites-vous aider si :
- vous ne parvenez pas à identifier la source après quelques cycles de comparaison, vous observez une réinfection rapide, votre site a un niveau d’activité critique et toute interruption coûte cher, ou si vous suspectez une compromission plus large de votre hébergement (pas seulement WordPress).
En interne, vous pouvez avancer si vous avez au moins un backup sain, un accès FTP ou au gestionnaire de fichiers, et la capacité de comparer code et contenu. Et surtout, si vous pouvez prendre le temps de valider.
Répondre aux questions fréquentes que je reçois sur les injections
“J’ai trouvé des scripts dans un fichier, je les supprime, c’est bon ?”
Souvent non. Si la persistance existe, le code reviendra. Il faut vérifier comptes, options et mécanismes d’injection.“Mon plugin est infecté, mais je l’ai remplacé. Pourquoi le problème continue ?”
Parce que le code peut être ailleurs que dans le plugin lui même. Par exemple, dans un fichier du thème qui appelle une option contaminée, ou dans la base. Ou parce que l’accès admin a été utilisé pour réinjecter ailleurs.“Je n’ai pas de backup sain. Je fais quoi ?”
Vous devez vous baser sur la comparaison avec une installation propre. Remplacer thèmes et plugins par leurs versions officielles, puis inspecter ce qui diffère. C’est plus long, mais faisable.“Et si ça vient d’une compromission du serveur, pas seulement WordPress ?”
Dans ce cas, nettoyer WordPress ne suffit pas. Si vous observez des fichiers qui ne sont pas propres au site, ou si des tâches cron ou des scripts système existent, il faut traiter au niveau hébergement.Ces questions sont normales. L’infection WordPress est parfois “localisée”, parfois “systémique”. Le bon diagnostic dépend de votre capacité à observer, comparer, et valider.
Une check rapide, mais utile : garder le fil jusqu’au bout
Je reviens à une approche simple, sans jargon, qui aide à éviter les oublis.
- Assurez-vous d’avoir un état de référence avant modification quand c’est possible. Identifiez le point d’injection en observant le HTML rendu et les fichiers suspects. Remplacez les thèmes et plugins par des versions saines, plutôt que de “corriger au scalpel” quand vous avez un doute. Coupez l’accès si un compte a été compromis, en supprimant ce qui n’a pas sa place. Surveillez après correction, parce que la persistance n’avertit pas toujours tout de suite.
Si vous faites ça, vous ne vous contentez pas de “désinfecter”. Vous reprenez le contrôle.
Le sujet que personne n’aime, mais qui décide tout : la qualité du suivi
Une désinfection WordPress finit rarement à la première intervention. Le vrai travail, c’est le suivi. Les infections avancées sont parfois graduelles, elles s’activent en fonction de conditions. Par exemple, un script peut s’exécuter seulement sur certains types de visiteurs, ou seulement à partir d’un horaire précis. Vous pouvez donc croire que c’est bon, puis voir un comportement étrange revenir plus tard.
Je préfère donc intégrer un suivi court, réaliste. Surveillez la page et les ressources chargées. Vérifiez les logs liés aux tentatives de connexion, et observez si de nouveaux changements de fichiers apparaissent. Et si vous avez un système d’alertes côté hébergement, activez-le ou configurez-le avec des seuils adaptés.
WordPress est très tolérant, il pardonne beaucoup de choses. Cette tolérance est une force, mais en sécurité c’est aussi un piège, parce que l’infection peut continuer à fonctionner tout en restant partiellement invisible.
Quand on comprend l’injection de code comme un mécanisme, pas comme un “accident de fichier”, on traite le problème au bon niveau. Ensuite seulement, on stabilise, on durcit, et on repart sur des bases saines.
Si vous voulez, décrivez-moi votre cas avec trois détails (symptôme observé, extensions ou thèmes concernés, et ce que vous avez déjà essayé). Je peux vous aider à formuler une stratégie de désinfection WordPress plus ciblée, avec les points de validation les plus fiables pour votre situation.