Quand un site WordPress “part en vrille”, on parle souvent d’un virus, alors que le tableau réel est plus large: code malveillant injecté dans des fichiers, redirections cachées, spam SEO, comptes admin créés, formulaires détournés, base de données contaminée, ou encore thèmes et plugins devenus un vrai cheval de Troie. Ce qui rend l’épreuve particulièrement frustrante, ce n’est pas seulement de supprimer le contenu indésirable, c’est d’éviter qu’il revienne dès le lendemain, après une “suppression” trop superficielle.
J’ai vu des équipes remettre le site “à neuf” en supprimant des fichiers visibles, puis découvrir 48 heures plus tard la même redirection, ou pire, une nouvelle porte dérobée. La différence entre un nettoyage qui tient et un nettoyage qui échoue tient souvent à la discipline de la remise en état, puis à l’hygiène anti-réinfection. La checklist ci-dessous est conçue pour couvrir les deux phases, sans magie, avec des décisions praticables.
Commencer par vérifier: symptômes, périmètre, responsabilité
Avant de toucher aux fichiers, prenez deux minutes pour cadrer. Les symptômes orientent le diagnostic et évitent de “nettoyer” le mauvais endroit.
Si vous voyez des redirections vers des domaines inconnus, un trafic SEO bizarre, des pages qui s’affichent différemment selon l’IP, ou des fichiers récemment modifiés, c’est généralement côté fichiers (thèmes, plugins, racine, uploads) ou côté base (options, cron, tables wp_users). Si ce sont des connexions qui échouent en boucle, puis un compte admin réapparaît, c’est souvent un sujet d’accès, de mots de passe, ou de persistance via un point d’entrée déjà en place.
Côté méthode, je recommande de travailler en “chaîne de preuves” plutôt qu’en “coup de masse”:
- identifier ce qui a bougé récemment, isoler la cause, reconstruire proprement ce qui doit l’être, puis fermer les portes.
Mise en sécurité immédiate avant de supprimer quoi que ce soit
La plupart des dégâts se produisent pendant la manipulation, pas uniquement avant. Une fois que vous êtes certain qu’il y a une compromission, bloquez l’accès inutile et préparez une restauration possible.
Quelques réflexes qui évitent de transformer l’incident en catastrophe:
- mettez le site en maintenance ou au moins limitez l’accès public (un simple filtre au niveau serveur ou un mode maintenance WordPress), coupez l’accès SSH et FTP si vous n’en avez pas besoin le temps du nettoyage, ou verrouillez les comptes utilisés, sauvegardez les éléments concernés (fichiers et base), même si l’idée vous donne envie de “passer à autre chose” tout de suite.
Oui, sauvegarder “après” est souvent trop tard. Une sauvegarde faite tôt permet de comparer, de revenir en arrière, et de vérifier l’absence de persistance.
Checklist anti-réinfection en 15 points (en pratique)
Cette partie est volontairement orientée terrain. Les points ne sont pas “jolis”, ils sont utiles. Et certains se chevauchent, parce que la persistance malveillante aime jouer sur les zones grises.
1) Confirmer l’ampleur de la compromission
Déterminez si c’est uniquement du contenu injecté, ou si des comptes, des tâches cron, ou des entrées base de données ont été modifiées. Un site peut rester “visible” tout en étant compromis, et l’inverse arrive aussi.
2) Prendre une sauvegarde propre de départ
Faites une copie des fichiers et de la base de données avant modifications. Gardez aussi une copie des fichiers injectés présumés, au cas où vous devriez comparer après restauration.
3) Isoler le site du monde extérieur pendant l’analyse
Mettez en maintenance ou bloquez temporairement certains endpoints. L’objectif est de stopper la propagation et d’éviter que des scripts malveillants continuent d’écrire.
4) Relever les fichiers modifiés récemment
Dans le dossier racine et les dossiers wp-content, repérez les créations et modifications récentes. Dans beaucoup d’incidents, le “truc” se cache dans un fichier qui a été touché quelques heures ou quelques jours avant le début des symptômes.
5) Identifier l’entrée de persistance
Cherchez les mécanismes de persistance typiques: fichiers dans uploads, injections dans wp-config.php ou dans des inclusions, scripts dans des thèmes ou plugins, ou hooks liés à des actions WordPress. L’idée est de trouver “d’où ça se relance” après nettoyage.
6) Désactiver et supprimer ce qui est suspect (sans casser l’hypothèse)
Commencez par couper les plugins et thèmes qui ont un comportement anormal ou qui contiennent des ajouts non standard. Si un plugin “normal” a été remplacé par une variante corrompue, le mieux n’est pas de patcher au hasard, c’est de remplacer.
7) Reconstruire plutôt que réparer au cutter
Quand vous suspectez une compromission sur un thème ou un plugin, la reconstruction est souvent plus fiable que “on retire les lignes bizarres”. Téléchargez les versions officielles, puis recroisez avec des checksums si votre pratique le permet.
8) Nettoyer la base sans aveuglement
Contrôlez les tables et options qui peuvent stocker du contenu injecté. Typiquement, on vérifie la cohérence des contenus, l’existence d’éléments inattendus, et la présence de champs ou d’entrées qui n’ont pas de raison d’exister.
9) Traquer les comptes utilisateurs compromis
Vérifiez les utilisateurs WordPress, les rôles, les dates de création, et les méthodes d’accès. Si un compte admin a été ajouté, supprimez-le, changez les mots de passe, et vérifiez les sessions actives.
10) Couper les accès persistants côté serveur
Contrôlez les accès SSH, FTP, et les clés. Beaucoup d’attaques s’appuient sur des identifiants valides qui ont été récupérés. Si vous réinitialisez WordPress mais laissez un accès serveur compromis, vous ne faites que retarder l’échéance.
11) Supprimer les tâches cron et mécanismes programmés douteux
WordPress peut exécuter des tâches via cron. Si une tâche a été ajoutée pour ré-injecter le code, elle se remettra à fonctionner. Faites le tri dans les événements programmés et surveillez le comportement après correction.
12) Purger les redirections et contenus injectés dans les fichiers “silencieux”
La persistance adore des endroits peu regardés: fichiers de configuration, includes, templates, parfois des fichiers dans wp-content/upgrade ou des sous-dossiers d’uploads. Inspectez aussi les fichiers dont le contenu ressemble à du PHP “normal” mais contient des blocs obscurs.
13) Mettre à jour le cœur WordPress et tout ce qui dépend
Le nettoyage “en surface” ne règle pas les failles. Une fois le code malveillant enlevé, mettez à jour WordPress, puis les plugins et thèmes, idéalement ceux dont vous avez réellement besoin. Si vous remplacez un plugin déjà compromis sans mettre à jour, vous gardez la porte ouverte.
14) Renforcer l’accès: mots de passe, 2FA, gestion des rôles
Réinitialisez les mots de passe à un niveau qui a du sens, limitez les rôles, et activez une authentification forte. Si vous avez plusieurs contributeurs, l’hygiène de base (rôles minimaux, rotation, révocation immédiate) réduit drastiquement le risque.
15) Surveiller et contrôler après nettoyage, pas juste “cocher une case”
Une fois le site remis en état, surveillez les journaux, contrôlez les fichiers modifiés, et observez le comportement du trafic. La détection rapide est votre meilleure anti-réinfection.
Ce qui compte, dans ces 15 points, c’est l’enchaînement. Supprimer sans reconstruire laisse des “relais” en place. Mettre à jour sans nettoyer laisse des persistances qui réinfectent.
Comment identifier ce qui est réellement “mal” (sans paniquer)
Le piège du diagnostic, c’est de croire qu’un seul symptôme prouve tout. J’ai déjà vu des cas où un plugin de cache très bavard faisait des changements côté contenu, donnant l’impression d’une injection. À l’inverse, des sites très “propres” visuellement étaient pourtant infectés via des redirections déclenchées uniquement par certains agents, ou via une règle conditionnelle basée sur l’URL.
Pour garder la tête froide, je fais une lecture croisée:
- examen des fichiers modifiés, inspection du contenu PHP et des inclusions, comparaison entre versions attendues et versions actuelles, consultation des journaux d’erreurs et d’accès.
Le rôle des plugins de sécurité et des outils de scan
Les scanners peuvent aider, mais ils ne remplacent pas une reconstruction sérieuse. Leur limite principale est qu’ils peuvent repérer le contenu connu ou suspect, sans garantir que la chaîne complète de persistance est fermée. Par ailleurs, certains outils signalent des faux positifs, surtout quand des plugins injectent du code pour du caching, du tracking ou du lazy loading.
Mon approche: utiliser les scans pour guider la recherche, puis confirmer par analyse et par comparaison des versions officielles quand cela concerne des thèmes et plugins.
Réinfection: pourquoi ça revient (même après “suppression”)
La question revient tout le temps, et la réponse est souvent simple: la persistance n’a pas été coupée.
Les causes typiques, observées sur le terrain:
- un compte admin a été créé à nouveau, parce que l’accès original n’a jamais été verrouillé, un fichier injecté s’est reconstitué via cron, ou via une inclusion automatique, un plugin corrompu a été “nettoyé” mais remplacé seulement partiellement, une faille a permis à l’attaque de revenir, même après retrait du code initial, les identifiants serveur ou de déploiement (CI, clés SSH) restent exposés.
Autre détail, plus subtil: certains sites passent par des scripts d’automatisation, synchronisation, ou déploiement qui “réappliquent” des versions stockées. Si la version stockée est déjà contaminée, la réinfection devient quasi instantanée après nettoyage.
Exemples concrets de décisions à prendre
Un incident banal: un thème enfant “custom” contient une modification minime, mais des redirections apparaissent sur certaines pages. En regardant de près, on constate que la logique a été ajoutée au niveau d’un fichier d’include, pas dans le template visible. Le bon geste n’est pas d’effacer un seul bloc, c’est de comparer à une version de thème attendue, puis de https://gardewp.fr/nettoyage-malware-wordpress/ reconstruire le thème enfant en gardant uniquement le code réellement nécessaire.
Autre cas réel: un site qui ne se “casse” pas, mais dont le SEO change en douceur. Le nettoyage “fichiers + base” donne l’impression d’être réussi. Puis, une nuit plus tard, on revoit des pages légères et du contenu injecté. Le problème était un mécanisme programmée, cron côté WordPress. Tant qu’il n’était pas retiré, le site se réécrivait.
Même logique pour les comptes: la suppression d’un utilisateur malveillant sans réinitialisation complète des accès et sans vérification des logs donne une fausse tranquillité. Si l’attaquant a conservé un moyen d’accès, il repassera par là.
Mini check pour vos premiers contrôles (avant restauration totale)
Voici un petit cadrage utile quand vous démarrez. Ce n’est pas le nettoyage complet, juste la collecte de signaux.
- Les fichiers modifiés récemment se trouvent-ils dans wp-content, uploads, ou à la racine ? Des identifiants de style “admin” ou “wp-admin” ont-ils été créés à une date cohérente ? Des tâches cron ou des événements programmés ont-ils été ajoutés récemment ? Les redirections ou scripts sont-ils déclenchés seulement sur certains URLs ? Un plugin ou un thème a-t-il été mis à jour, puis remplacé par une version non officielle ?
Si plusieurs réponses convergent vers une zone précise, vous pouvez concentrer vos efforts au lieu de tout ouvrir.
Remettre le site debout: stratégie de reconstruction propre
Une reconstruction propre ressemble plus à un chantier qu’à une chirurgie. Vous ne “débrouillez” pas, vous refaites ce qui doit l’être.
En pratique, je privilégie:
- restaurer le cœur WordPress depuis une version officielle compatible, reconstruire thèmes et plugins depuis les sources officielles, réimporter uniquement le contenu dont l’intégrité est démontrée (médias, pages, articles), vérifier la base après restauration et corriger ce qui a été contaminé.
Ce point vaut surtout pour “enlever virus WordPress” de façon durable: le risque n’est pas uniquement le code malveillant, c’est le mélange indétecté de code fiable et code compromis dans un même fichier. Remplacer réduit l’espace pour l’erreur.
Sécuriser pour de vrai après le nettoyage
Une fois le site propre, l’étape sécurité ne se limite pas à activer un module. Elle implique des habitudes: gestion des accès, mise à jour, suppression de ce qui ne sert plus, et visibilité.
Quelques décisions qui font la différence:
- n’accorder que le minimum de droits aux utilisateurs, limiter les tentatives de connexion, imposer une authentification forte pour les comptes à privilèges, surveiller les journaux d’accès et les erreurs serveur, vérifier régulièrement la liste des plugins installés et supprimer les “anciens dont personne ne se sert”.
Je garde une règle personnelle: si un plugin n’est pas indispensable, il est candidat à la suppression. Les plugins ajoutent de la surface d’attaque, même quand ils ne sont pas malveillants.
Note sur les “cas limites” (quand c’est compliqué)
Certains environnements compliquent l’enquête:
- sites multi-sites, mises à jour automatisées via des pipelines, hébergeurs avec caches ou mises en avant qui modifient le contenu, thèmes sur mesure très imbriqués, gestion des fichiers via un outil qui reversionne et réécrit.
Dans ces cas, la checklist reste valable, mais les chemins d’exécution changent. Par exemple, si un déploiement automatique remonte des fichiers depuis un dépôt, vous devez aussi vérifier que le dépôt est sain. Sinon, vous nettoyez le site, puis le système vous “rend” la version contaminée.
Ce que j’exigerais en interne comme “preuve de fin” du nettoyage
Avant de relâcher le site, je veux des preuves, pas juste l’impression. Là encore, je reste pragmatique.
Voici les éléments que je considère comme des signaux forts de stabilisation:
- Aucun fichier suspect n’a changé depuis le dernier cycle de contrôle Les pages redeviennent cohérentes, y compris pour des requêtes déclenchées sur des URLs à risque Aucun compte inattendu n’apparaît dans wp_users Les événements programmés WordPress ne déclenchent pas de réécriture non expliquée Les journaux ne montrent pas de tentatives de réexploitation répétées sur les mêmes points
S’il manque un seul de ces signaux, je ne laisse pas le site en “mode normal”. Je traite ça comme un chantier en cours.
Et maintenant, une approche simple pour votre prochain incident
Si vous devez retenir une logique, c’est celle-ci: enlever le code est nécessaire, mais ce n’est pas suffisant. Vous devez aussi fermer les portes qui ont permis de remettre du code, et vous assurer que votre environnement ne réapplique pas une version infectée.
Si vous voulez une méthode d’exécution que vous pouvez adapter à votre équipe, partez de cette séquence: mise en sécurité, sauvegarde, collecte des modifications récentes, identification des mécanismes de persistance, reconstruction depuis sources fiables, verrouillage des accès, contrôle cron et base, puis surveillance renforcée.
Enfin, gardez un réflexe de maintenance: un site WordPress qui “respire” bien, avec des plugins minimaux et des mises à jour régulières, ne vous rend pas invulnérable, mais il réduit fortement les probabilités de récidive.
Si vous avez déjà vu des injections revenir, dites-moi votre contexte (plugins principaux, type d’hébergement, symptômes, période approximative). Je peux vous aider à adapter la checklist à votre cas précis, notamment sur les zones à inspecter en priorité pour limiter le temps perdu.