WordPress est robuste, mais il a un point faible classique: il attire des tentatives automatisées. Quand ça tourne mal, on ne parle pas d’un simple “bug”. On peut se retrouver avec des pages qui redirigent, des formulaires qui récoltent des données, des téléchargements qui propagent du code, ou une charge serveur qui grimpe alors que votre site ne fait rien de nouveau. Dans ces moments-là, l’objectif n’est pas seulement de “supprimer le virus”, c’est de reprendre le contrôle et d’empêcher la réinfection.
Je l’ai vécu sur plusieurs sites clients. Le scénario revient souvent: une première alerte (défacement SEO, trafic anormal, emails de phishing signalés, services de sécurité qui crient), puis un décalage entre ce que l’administrateur voit, et ce que le serveur exécute réellement. Le code malveillant peut être discret dans des fichiers inattendus, caché dans des options de la base de données, ou relié à un compte qui a été “verrouillé” par l’attaquant pour revenir même après nettoyage.
Ce guide suit une logique pragmatique: on vérifie d’abord l’étendue du problème, on nettoie les fichiers et les points d’exécution, on assainit la base de données, puis on purge les accès et on renforce la façon de gérer WordPress.
Symptômes: savoir où chercher avant de toucher à tout
Avant de supprimer quoi que ce soit, j’insiste toujours sur un réflexe: collecter des indices. Pas besoin d’être parano, mais assez pour orienter l’analyse.
Quelques signaux typiques:
- redirections vers des domaines bizarres, parfois seulement sur mobile ou certaines plages d’IP; des pages qui affichent du contenu “normal” puis basculent vers une autre destination après quelques secondes; du spam généré via des formulaires WordPress, ou des tentatives d’inscription qui “collent”; des plugins ou thèmes qui “s’installent” tout seuls; une augmentation de requêtes au niveau serveur, ou des fichiers modifiés alors que personne ne s’en est occupé.
Une anecdote qui parle bien: sur un site e-commerce, les rapports de sécurité montraient une infection, mais en explorant l’espace public, tout semblait correct. C’est en regardant les journaux d’accès et les fichiers récemment modifiés qu’on a trouvé une charge utile dans un script appelé seulement dans un cas précis: une action AJAX déclenchée par une requête spécifique. Si on avait supprimé au hasard, on aurait peut-être effacé le symptôme sans traiter la porte d’entrée.
L’idée est simple: l’infection peut ne pas se voir à l’œil nu sur la page d’accueil. Elle peut exister dans une fonction, un hook, un fichier inclus indirectement, ou une option de configuration stockée en base.
Préparer le nettoyage: sauvegarde, limitation de dégâts, accès contrôlé
Quand on est en situation d’incident, la tentation est de “nettoyer vite”. Le bon rythme est plutôt: sauvegarder proprement, couper ce qui diffuse, puis agir.
Si votre hébergeur propose un mode de récupération, utilisez-le. Sinon, voici la logique que j’applique:
Sauvegarde complète du dossier WordPress et de la base de données. Copie locale pour analyse, au lieu de modifier directement l’environnement de production. Si le site redirige des visiteurs, limitez l’exposition le temps du traitement (mise en pause, ou protection temporaire via règles d’accès).Le piège fréquent est de modifier le site pendant que vous perdez des preuves. Même si vous voulez aller vite, documentez ce que vous trouvez: dates de modification, fichiers suspects, comptes qui ont été ajoutés, options de base de données modifiées, URL invoquées dans les requêtes.
Comprendre le vecteur le plus courant: l’accès d’abord, le code ensuite
Dans beaucoup d’incidents, le “virus” n’est pas seulement un fichier. C’est souvent un accès obtenu via un mot de passe faible, une session oubliée, ou une faille dans un plugin obsolète. L’attaquant peut alors déposer un petit fichier, modifier des hooks, ou ajouter un utilisateur qui sait revenir.
Avant de chercher des lignes suspectes dans tous les fichiers, regardez du côté de l’accès:
- comptes administrateur ajoutés récemment; rôles inattendus (éditeur ou administrateur non justifiés); tentatives de connexion infructueuses en forte hausse; plugins installés ou activés sans action de votre part.
Cette étape est utile même si vous êtes certain de la “source” (par exemple après avoir installé un thème nul). Je l’ai vu plus d’une fois: le code a été planté, mais la porte d’entrée était ailleurs.
Nettoyer les fichiers: méthode “moins de suppositions, plus de preuves”
Le nettoyage de fichiers ne consiste pas à supprimer “au feeling” des lignes de PHP. Il faut penser en exécution: qu’est-ce qui est appelé dans WordPress, dans vos pages, ou via des hooks?
Où se cachent les charges utiles
Les emplacements fréquents, sans certitude absolue, incluent:
- fichiers PHP déposés dans des dossiers inhabituels, parfois sous des noms qui ressemblent à des scripts système; code injecté dans des fichiers WordPress “propres” mais modifiés, comme index.php, wp-config.php, ou des fichiers dans wp-includes ou wp-admin; utilisation de base64_decode, eval, ou fonctions de génération dynamique de code; fichiers avec des permissions atypiques, ou des dates de modification incohérentes.
Je fais une chose qui paraît simple, mais qui évite beaucoup d’erreurs: je compare à une version saine. Si vous avez un miroir ou une copie de votre site avant l’incident, utilisez-la. Sinon, réinstallez WordPress depuis une version connue pour identifier ce qui ne correspond plus.
Réinstallation contrôlée de WordPress (sans perdre le contenu)
Une stratégie prudente consiste à remplacer uniquement les fichiers noyau de WordPress, en conservant le dossier wp-content tel quel pour l’inspection. Cela réduit l’espace de recherche, et limite le risque de casser un thème.
Le principe: WordPress est un ensemble de fichiers standard. Votre contenu réel (thèmes, plugins, médias) est dans wp-content. Si vous réinstallez le noyau, vous éliminez une partie des modifications qui pourraient être malveillantes dans des fichiers standard.
Ce qui demande du jugement: si vos fichiers ont aussi été touchés dans wp-content, ne remplacez pas tout en une passe sans vérifier. On évite de “réinjecter” la charge utile.
Traquer intelligemment, pas mécaniquement
Vous pouvez chercher des motifs dans le contenu des fichiers, mais je préfère une approche par preuves:
- repérez les fichiers modifiés récemment; vérifiez les fichiers qui ne devraient pas exister; inspectez ceux qui contiennent des mécanismes d’obfuscation.
Par obfuscation, j’entends des choses concrètes: chaînes codées, concaténations d’octets, appels dynamiques, ou inclusion conditionnelle.
Si vous trouvez du code douteux, ne supprimez pas tout. Analysez la logique, puis confirmez que le fichier n’est pas nécessaire. Sur un site vivant, certains plugins ont des mécanismes avancés, mais ils sont généralement cohérents avec leur rôle. Un script qui écrit des fichiers sur le serveur, ou qui contacte un serveur externe sans raison, doit être traité comme un signal fort.
Exemple concret de “fausse alerte” et comment éviter le piège
Une difficulté fréquente: vous trouvez une ligne suspecte dans un plugin, mais ce plugin peut aussi être utilisé pour du cache ou de la compression. Un motif “eval” peut exister dans des bibliothèques qui font du traitement dynamique.
D’où le conseil pratique: vérifiez le contexte du code. Une fonction d’évaluation dans un fichier de plugin, avec des entrées contrôlées et sans communication externe inhabituelle, peut être légitime. À l’inverse, si le code construit une URL, télécharge une payload, ou modifie des options WordPress à la volée, là vous avez une direction claire.
C’est pour ça que je documente. Sans contexte, “nettoyer” devient une loterie.
Nettoyer la base de données: les options et les injections qui restent même après suppression de fichiers
Même si vous supprimez les fichiers malveillants, la base de données peut contenir des paramètres qui déclenchent encore des comportements. L’exemple le plus classique est une option modifiée pour injecter du contenu via les hooks. Un code peut aussi être stocké comme une “shortcode” ou via des champs personnalisés, puis utilisé ensuite.
Les tables et champs à inspecter en priorité
Je n’établis pas une règle universelle, mais sur WordPress, certains endroits reviennent souvent.
- wp_options: options liées aux injections de contenu, au cache, ou à des paramètres anormaux. wp_postmeta: métadonnées de pages ou d’articles créés ou modifiés récemment. tables d’utilisateurs: création ou modification d’enregistrements utilisateurs.
L’approche pratique: exportez, puis comparez. Regardez surtout les entrées “nouvelles” et celles dont les valeurs ne collent pas au fonctionnement attendu. Par exemple, un champ qui contient un script PHP stocké, ou une valeur qui ressemble à un code obfusqué, doit être considérée sérieusement.
Étape souvent sous-estimée: vérifier les pages et articles “louches”
Les infections “SEO spam” peuvent créer des pages ou articles, ou modifier des contenus existants, pour rediriger, ou pour présenter un contenu trompeur. Tant que vous ne regardez pas l’historique, vous ne voyez pas.
Sur certains incidents, l’attaque était capable de créer du contenu, mais aussi d’y attacher des scripts via des champs meta.
Donc oui, inspectez aussi le contenu WordPress: les pages, articles, et surtout les éléments créés récemment, ou dont l’auteur n’est pas cohérent.
Assainir les comptes: le point qui fait la différence entre un nettoyage temporaire et une reprise durable
Si vous ne traitez que les fichiers et la base, l’attaquant peut revenir. Un compte compromis fait ça très bien, même sans réinstaller des fichiers visibles.
Ce que je fais systématiquement
Je vérifie:
- la liste des utilisateurs, en repérant les ajouts récents; les rôles et droits, par exemple un administrateur non documenté; les tentatives de connexion infructueuses et dates inhabituelles, si votre système le permet; les sessions et cookies en cours.
Ensuite, selon le contexte:
- suppression des comptes inattendus; changement de mots de passe pour les comptes légitimes; révocation des sessions si possible; vérification des emails d’administration, car parfois l’attaquant a modifié des paramètres de notification.
Traitement des mots de passe: pas juste “changer”, mais assainir
Changer un mot de passe ne suffit pas si l’attaquant a encore des mécanismes d’accès. Mais c’est indispensable si un mot de passe a été compromis.
Je conseille des mots de passe longs, uniques, et l’activation d’une méthode d’authentification forte si vous pouvez. Sur des sites WordPress, la double authentification réduit énormément le risque de retour, surtout après une tentative de brute force.
Plugins et thèmes: réinstaller plutôt que “patcher” au hasard
Quand WordPress est compromis, les plugins et thèmes sont souvent le vecteur. Même si vous nettoyez un fichier, un plugin malveillant peut rester activé, ou contenir une logique dormante.
La bonne approche est généralement de:
- désactiver les plugins non essentiels; vérifier ceux qui sont liés à des injections, à des scripts externes, ou à des modifications fréquentes; remplacer par des versions officielles.
Je l’ai déjà vu: un plugin “analytics” ou “security” était en fait le cheval de Troie. Le site semblait amélioré, car l’UI affichait des rapports “propres”. Derrière, le code faisait une action d’injection sur certaines pages. Ce genre d’attaque passe au travers des contrôles superficiels.
Plan de nettoyage recommandé (pragmatique et sans excès)
Je vous propose un plan orienté action, mais toujours avec contrôle. C’est un bon compromis entre rigueur et temps de traitement.
- Mettez le site en état limité si la redirection est active, et faites une sauvegarde complète. Remplacez les fichiers noyau de WordPress par une version saine, sans toucher wp-content pour l’analyse. Inspectez wp-content et repérez les fichiers récemment modifiés, dossiers non attendus, et patterns d’obfuscation. Assainissez la base en inspectant wp_options et les contenus publiés récemment, puis supprimez les entrées manifestement malveillantes. Purgez et sécurisez les comptes: suppression des utilisateurs inattendus, changement de mots de passe, révocation des sessions.
Ce plan ne remplace pas une expertise, mais il évite les erreurs classiques: supprimer trop tôt, ou oublier un compte.
Reconnaître les signatures sans tomber dans le folklore
Les blogs sécurité parlent souvent de “tests” ou de “signatures”. Ce sont des indices utiles, mais ils ne garantissent rien. Un attaquant peut adapter sa payload. À l’inverse, un administrateur peut tomber sur un code qui ressemble à une charge utile, mais qui est légitime dans un plugin spécifique.
Le bon réflexe, c’est de combiner trois signaux:
Cohérence du comportement (qu’est-ce que le fichier cherche à faire); Cohérence temporelle (dates de modification, créations d’entrées); Cohérence fonctionnelle (est-ce aligné avec la mission du plugin ou du thème).Quand ces trois signaux vont ensemble, vous êtes sur du solide. Quand un seul signal suffit, il faut investiguer davantage.
Edge cases: cas réels où “nettoyer” peut casser le site si vous êtes trop agressif
Il y a des scénarios où une approche trop radicale crée de nouveaux problèmes.
- Un plugin de cache peut stocker des fichiers dans le répertoire avec des permissions ou des dates qui ressemblent à une modification récente. Le nettoyage doit alors cibler le contenu exécutable, pas le cache lui-même. Certains thèmes utilisent des includes dynamiques. Une recherche de mots-clés isolés peut faire supprimer un bout de logique nécessaire. Si vous remplacez un thème ou un plugin par une version qui a changé depuis l’incident, vous pouvez perdre des réglages ou des options personnalisées.
C’est pour cela que je recommande souvent de conserver des copies des versions actuelles pendant l’analyse. Le nettoyage devient une reconstruction maîtrisée, pas une suppression à l’aveugle.
Réinjecter la confiance: validation après nettoyage
Une fois le nettoyage fait, vous devez valider. Sinon, vous ne savez pas si vous avez vraiment éradiqué le problème, ou si vous l’avez juste déplacé.
Les validations utiles sont généralement:
- tester les pages qui posaient problème, pas seulement la home; vérifier que les formulaires n’écrivent pas de contenu inattendu; surveiller les logs pendant quelques heures ou jours, selon la taille du site; refaire un scan sécurité et un contrôle manuel sur les fichiers qui ont été touchés.
Un point important: les infections peuvent être déclenchées par des conditions. Exemple courant: certaines payloads s’activent seulement après un certain nombre de requêtes, ou pour certaines “cibles” (user-agent, IP, géolocalisation). Ne vous contentez pas de “ça marche chez moi” si le problème était subtil.
Prévenir la réinfection: hygiène d’accès et gestion WordPress au quotidien
Nettoyer une infection, c’est une urgence. Empêcher le retour, c’est votre travail sur la durée, et c’est là que les risques financiers disparaissent.
Il y a deux axes qui comptent le plus:
- limiter la surface d’attaque (plugins, thèmes, permissions, mise à jour); rendre l’accès plus robuste (mots de passe, MFA, réduction des exposés).
Voici un petit rappel en format check, utile pour stabiliser après incident:
- Désactivez et supprimez les plugins inutiles, et mettez à jour ceux qui restent. Remplacez les mots de passe et activez une authentification forte pour les comptes à privilèges. Vérifiez régulièrement les nouveaux utilisateurs et les changements de rôles. Surveillez les journaux serveur et les changements de fichiers sur les zones sensibles. Gardez une sauvegarde testée, que vous savez restaurer vite.
Deux conditions font la différence: régularité, et capacité à répondre rapidement si un signal revient.
Quand demander de l’aide, et comment cadrer la demande
Si vous gérez plusieurs sites, ou si vous manquez de temps pour analyser les fichiers et la base, vous pouvez externaliser. Dans ce cas, cadrer la demande réduit la facture et évite de “tourner en rond”.
Ce que je demande d’habitude à un prestataire ou à un support technique:
- quels artefacts ils ont trouvés (fichiers, options, comptes); ce qui a été supprimé et ce qui a été réinstallé; comment ils valident qu’il n’y a plus de persistance.
Un prestataire sérieux vous répond sur la méthode et les preuves, pas seulement sur “c’est nettoyé”. Même si vous n’êtes pas technique, vous pouvez demander un résumé précis des points d’entrée et des actions menées.
Dernières précautions avant de rouvrir complètement au trafic
Si votre site a été mis en pause ou limité, pensez à l’étape finale: réouvrir sans relancer l’environnement compromis.
Je conseille de:
- réactiver seulement les plugins et thèmes nécessaires; revalider les pages sensibles; garder un œil sur les logs dès la reprise.
Si vous relancez tout d’un coup, y compris des plugins suspects, vous augmentez le risque de retour. Et si l’attaque était côté serveur via un accès persistant, ce retour peut se produire très vite.
Quelques questions à vous poser maintenant
Si vous devez décider où concentrer votre effort, posez-vous ces questions, directement et sans jargon:
Votre site redirige-t-il encore, même légèrement? Avez-vous identifié un compte ajouté récemment? Des fichiers ont-ils été modifiés sur des emplacements qui ne devraient jamais bouger? Des options ou des contenus ont-ils été créés récemment dans la base? Le problème revient-il après une réinstallation partielle ou une restauration?
Quand vous avez ces réponses, vous ne “nettoyez” plus à l’aveugle. Vous reprenez une maîtrise technique, et vous transformez une urgence en plan d’assainissement.
Et c’est exactement le sens de enlever virus WordPress, au fond: pas seulement supprimer un morceau de code, mais refermer les chemins d’accès, assainir la persistance, puis redonner au site une base saine sur laquelle repartir.