Scanner malware WordPress : étapes de remédiation après détection

Quand un site WordPress passe en rouge après un scan, la première réaction est souvent la même: courir partout, installer un plugin de “nettoyage”, changer des mots de passe à la volée. Ce réflexe vient d’une bonne intention, mais il peut aussi aggraver la situation si le malware a déjà modifié des fichiers stratégiques, créé des accès persistants, ou déposé des web shells.

La réalité, c’est qu’une détection n’est pas une preuve de l’étendue réelle de la compromission. Parfois, le scan repère un changement bénin, un plugin mal identifié, ou une signature obsolète. D’autres fois, il ne voit qu’une partie du problème. La remédiation après détection doit donc suivre un ordre logique: confirmer l’incident, contenir, analyser, nettoyer, puis verrouiller.
Partir du bon signal, sans paniquer
Les scanners “malware WordPress” existent en plusieurs formes: outils externes qui scrutent l’URL, solutions côté hébergement, scripts plus techniques, ou signatures de navigateurs qui s’appuient sur des analyses précédentes. Le point clé: la détection indique un risque, mais elle ne décrit pas toujours la cause.

J’ai déjà vu un scan signaler du “code malveillant” dans un thème. Après investigation, il s’est avéré qu’un thème enfant utilisait une mini-bibliothèque de parsing, et la signature était trop large. C’était un faux positif. Inversement, j’ai aussi vu l’inverse: la détection ne pointait que quelques lignes dans un fichier, alors que le vrai problème était en réalité une tâche planifiée et un compte administrateur ajouté.

Avant de toucher au site, prenez une minute pour noter ce que vous voyez dans l’alerte:
URL concernée type de fichier pointé (thème, plugin, uploads, racine) nom de la signature ou de la règle, s’il est donné date de détection et score ou niveau de confiance (si l’outil le fournit)
Cette trace servira ensuite, car le nettoyage “au hasard” fait perdre du temps et complique l’analyse.
Contenir tout de suite pour éviter l’aggravation
Une fois l’incident suspect, l’objectif immédiat est de stopper la propagation, limiter les exfiltrations et réduire la charge générée par le malware. Selon votre configuration et votre tolérance au risque, vous avez plusieurs options. La plus prudente consiste à mettre le site hors ligne pendant l’investigation.

Cela peut sembler brutal, mais dans les cas où du code injecté déclenche des redirections, des téléchargements ou des requêtes répétitives, le site peut continuer à servir des charges malveillantes pendant que vous “nettoyez”.

Dans les situations où la mise hors ligne totale n’est pas envisageable, une approche intermédiaire existe: restreindre l’accès admin, bloquer des IP suspectes au niveau du https://gardewp.fr/ https://gardewp.fr/ pare-feu, ou mettre en cache de manière restrictive certaines routes. Mais ces décisions dépendent de votre hébergement, de votre CDN et de l’architecture du site.

Si vous avez accès aux logs (serveur, hébergement, CDN, WAF), gardez-les. Les logs sont souvent la seule “chronologie” fiable quand on revient sur les faits.
Vérifier l’intégrité: ce qui a changé, quand et par qui
Avant même de supprimer quoi que ce soit, il faut comprendre le périmètre. WordPress est un système relativement prévisible: les fichiers de base changent peu, les thèmes et plugins ont des empreintes stables, et la partie uploads devrait contenir uniquement des https://gardewp.fr/nettoyage-malware-wordpress/ https://gardewp.fr/nettoyage-malware-wordpress/ médias.

La première démarche utile consiste à comparer l’état actuel avec une référence saine. Selon votre organisation, la référence saine peut être:
une sauvegarde récente avant la date de détection un release officiel de WordPress pour les fichiers de base des archives de plugins et thèmes tels qu’ils étaient avant incident
Techniquement, l’idéal est de travailler sur une copie du site. Si vous avez un accès SSH, du temps, et des outils d’intégrité, vous pouvez lancer un diff ciblé sur:
fichiers modifiés récemment fichiers exécutables dans des répertoires inhabituels (exemples typiques: un fichier PHP dans un dossier qui ne devrait recevoir que des images) changements dans la racine WordPress (fichiers comme wp-config.php, index.php, ou des fichiers qui ne sont généralement pas modifiés)
Le but n’est pas seulement de trouver “le malware”. C’est de comprendre si le site a été altéré de façon persistante: modifications dans des hooks, ajouts d’options en base, comptes administrateurs créés, tâches planifiées, scripts cachés via noms de fichiers trompeurs.
Lire les logs comme un enquêteur, pas comme un compteur
Un scanner malware WordPress repère des signatures, mais les logs racontent l’histoire. Regardez:
les requêtes anormales sur des endpoints uniques des pics de requêtes vers des scripts inconnus des tentatives de téléchargement de fichiers externes des POST inhabituels vers admin-ajax.php ou des URIs non liées à votre trafic normal
En pratique, les patterns d’attaque se répètent. Par exemple, certains malwares injectent un fragment qui ne s’exécute que pour certaines routes, ou qui ne répond pas toujours de la même manière. Les logs, eux, peuvent montrer une fréquence, des User-Agent récurrents, ou des origines géographiques inattendues.

Si vous utilisez un CDN ou un WAF, vérifiez aussi les événements: blocages, règles déclenchées, ou réponses erronées. Vous cherchez un fil conducteur: quand l’activité a commencé, et si elle se poursuit.
Identifier les points d’entrée les plus probables
Une fois que vous avez une liste de fichiers et de modifications suspectes, il faut relier cela à une hypothèse de point d’entrée. Les malwares WordPress arrivent souvent via quelques voies récurrentes. Sans tomber dans la paranoïa, ces pistes orientent le nettoyage et surtout la sécurisation après.

Les causes fréquentes sont:
identifiants compromis (phishing, réutilisation de mot de passe, session existante) plugins ou thèmes vulnérables non mis à jour fichiers uploadés via une fonctionnalité où il ne devrait pas y avoir de PHP modifications dans des fichiers de configuration exploitation d’une faiblesse côté serveur (moins fréquent, mais possible)
Ce diagnostic influence votre remédiation. Si vous avez un malware “injection de contenu” mais que vos mots de passe admin sont inchangés depuis des mois, vous aurez peut-être nettoyé la surface, mais laissé la porte ouverte.
Travailler sur une copie: nettoyage sans casser ce qui prouve
L’erreur classique consiste à supprimer tout ce qui semble suspect dès le premier moment, puis à se rendre compte que la preuve disparaît. Sur un incident réel, la preuve est utile, même si le but final est de remettre le site en ligne.

Ma recommandation pragmatique: faites une copie de travail. Travaillez sur cette copie pour:
conserver les fichiers suspects annoter ce qui a été retiré et pourquoi enregistrer un “avant nettoyage” pour comparaison préparer une restauration si vous supprimez trop
Concrètement, gardez les chemins complets des fichiers modifiés, et stockez une archive locale de la copie. Ensuite seulement, supprimez ou corrigez.
Nettoyer: supprimer le code malveillant, mais aussi les mécanismes de persistance
Le malware WordPress n’est pas toujours un fichier qui “fait tout”. Souvent, il s’appuie sur des mécanismes de persistance. Le nettoyage doit donc être plus large que le simple retrait de quelques lignes dans un fichier.

Voici les zones où il faut regarder avec une attention renforcée, sans supposer que tout est là. Les cas typiques incluent:

1) Thèmes et fichiers PHP modifiés
Beaucoup d’incidents laissent des traces dans le thème (y compris le thème enfant) via des fonctions ajoutées dans functions.php ou via des fichiers inclus conditionnellement. Le code peut être discret, par exemple il ne s’exécute que si un paramètre est présent, ou uniquement pour certains navigateurs.
2) Plugins
Un plugin compromis peut ajouter un hook WordPress, modifier la sortie, ou charger du contenu distant. Parfois, la modification ne touche qu’un petit fichier, parfois c’est un dossier entier avec des noms “banals”.
3) Répertoires inattendus dans wp-content/uploads
Un malware peut déposer du PHP dans uploads, ou créer des fichiers masqués qui ressemblent à des médias. Si vous avez un plugin de scan qui indique un fichier dans uploads, traitez-le comme prioritaire.
4) La base de données
Même si les fichiers semblent propres, la base peut contenir des options malicieuses, des redirections configurées, ou des utilisateurs ajoutés. Il faut vérifier les tables liées aux options, aux utilisateurs, et aux événements planifiés.
5) Cron et tâches programmées
Beaucoup d’attaques utilisent le système cron de WordPress pour maintenir l’accès, réinjecter du code, ou exécuter des téléchargements. Si le site utilise wp-cron (le cas par défaut), la persistance peut s’activer à la fréquence que le système déclenche. Une approche méthodique de suppression
Plutôt que “supprimer et espérer”, procédez par remplacement contrôlé:
remplacez les fichiers de base WordPress par une version saine pour les thèmes et plugins, comparez les versions exactes et remplacez par des archives officielles si possible supprimez les fichiers déposés ailleurs que là où vous les attendez restaurez les fichiers que vous pouvez valider comme corrects
Ce qui est délicat, c’est le cas des modifications légitimes: customisations, surcharges, intégrations spécifiques. Si vous remplacez naïvement, vous perdez des fonctionnalités. Ici, votre capacité à différencier “modification légitime” et “modification malveillante” fait toute la différence.
Sécuriser la base: comptes, sessions, rôles et sessions persistantes
Le nettoyage ne suffit pas si un compte administrateur a été créé, ou si un compte existant a été compromis. Même si votre scan ne le mentionne pas, vérifiez.

Recherchez:
nouveaux utilisateurs et dates d’inscription proches de l’incident rôles élevés inattendus (administrateur, éditeur) URLs d’édition ou comportements typiques après connexion modifications d’options liées à la redirection ou aux fonctionnalités
Côté sessions, il faut aussi couper. WordPress conserve des cookies et des tokens. Après la remédiation, forcez une déconnexion globale:
changez les mots de passe des comptes admins et éditeurs invalidez les sessions si votre configuration le permet vérifiez l’activation de “Remember Me” ou de tokens persistants
En parallèle, modifiez les clés de sécurité WordPress si nécessaire. Ces clés ne “nettoient” pas un malware, mais elles réduisent la persistance de sessions si l’attaquant avait conservé des accès via cookies ou tokens.
Remettre les bonnes versions, proprement
Après suppression du code et correction de la base, l’étape qui stabilise le site consiste à réinstaller proprement les composants.

Quand c’est possible, je conseille de:
mettre à jour WordPress vers une version saine et récente mettre à jour tous les plugins et thèmes utilisés, ou désactiver ceux dont vous ne pouvez pas évaluer la sécurité supprimer les plugins inutiles, car c’est un vecteur courant d’entrée
Il existe un compromis important. Mettre à jour tout d’un coup peut casser des intégrations ou du custom. Dans un incident, la priorité reste la sécurité, mais vous pouvez atténuer le risque en réinstallant en deux temps: d’abord remettre le site fonctionnel via des composants validés, puis procéder aux mises à jour plus larges.
Ajouter du contrôle: durcir après le nettoyage
Une fois le site propre, l’objectif devient d’éviter la rechute. Le problème, c’est que beaucoup d’équipes installent “un plugin de sécurité” et considèrent que c’est réglé. Or, la sécurité durable vient d’un mélange de pratiques et de contrôles.

J’ai vu des incidents revenir car le même plugin vulnérable était resté en place, ou car l’équipe n’avait pas changé les mots de passe après compromission. Le durcissement doit couvrir la chaîne complète: accès, fichiers, patch management, et surveillance.

La surveillance n’a pas besoin d’être sophistiquée. Elle doit être continue et utilisable. Par exemple, monitorer l’intégrité des fichiers et recevoir une alerte quand un fichier PHP modifié apparaît dans un répertoire où vous n’en attendez pas.
Un plan de remédiation pratico-pratique (sans se perdre)
Voici un déroulé que j’utilise quand un scanner malware WordPress remonte une alerte. Il n’est pas “universel”, mais il fonctionne bien parce qu’il sépare les décisions critiques des actions de détail.
Étapes immédiates (le premier cycle) Mettre le site en mode restriction ou hors ligne, le temps de limiter l’exposition. Sauvegarder fichiers et base de données, puis travailler sur une copie. Rechercher tous les fichiers modifiés et vérifier si des comptes ou options ont été ajoutés. Remplacer WordPress, thèmes et plugins par des versions saines quand l’origine du changement est incertaine. Forcer la déconnexion, changer les mots de passe et invalider les sessions.
Ces étapes sont volontairement “frontières”. Elles évitent le cas classique où on nettoie en production, puis on s’aperçoit qu’une persistance reste active.
Contrôler l’exécution: tester avant de re-publier
Avant de remettre le site accessible au public, testez de manière ciblée. L’objectif est de vérifier que le site ne redirige plus, ne charge plus de scripts externes inattendus, et ne déclenche plus de comportements étranges.

Les contrôles pratiques incluent:
vérifier les pages concernées par l’alerte (et des pages voisines) tester l’accès admin et vérifier qu’aucun compte “fantôme” n’existe inspecter le HTML rendu et le chargement des ressources, pour repérer des scripts ajoutés vérifier que les erreurs PHP anormales ont disparu (les malwares laissent parfois des traces en logs)
Quand vous remettez en ligne, faites-le de manière progressive. Un redémarrage brutal avec l’intégralité du trafic peut réactiver des comportements si quelque chose reste en place. Par prudence, vérifiez d’abord depuis un environnement de test ou via une fenêtre de déploiement.
Relancer le scan, mais interpréter intelligemment
Relancer un scan est utile, mais ce n’est pas un bouton magique. Les outils peuvent:
rater une variante ou un chemin caché signaler des faux positifs persistants dépendre de l’état exact du contenu servi à un moment donné
L’interprétation doit rester alignée avec votre investigation. Si le scan redevient vert mais que vous voyez encore des comptes ajoutés ou des fichiers modifiés récents, il faut continuer.

La meilleure pratique est de vérifier la cohérence de plusieurs signaux: logs, intégrité des fichiers, base de données, et comportement applicatif.
Check rapide de “cohérence” après nettoyage Aucun fichier PHP en dehors des zones attendues (racine WordPress, thèmes, plugins). Base de données: pas de comptes ou options ajoutés récemment, ou au moins compris et justifiés. Cron: pas de tâches inconnues ou récurrentes liées au malware. Site: pages concernées ne redirigent plus, et ressources chargées restent cohérentes. Mots de passe et sessions: comptes clés réinitialisés et accès admin verrouillé.
Cette mini-validation évite le scénario où on se contente d’un scan externe et on oublie la persistance.
Cas limites: quand la détection ne suffit pas
Il y a des situations où l’alerte est claire, mais le reste est ambigu. Quelques cas que j’ai rencontrés:
Faux positif sur un plugin populaire: la signature repère une fonction courante. Solution: comparer la version exacte du plugin et faire une vérification d’intégrité sur les fichiers. Compromission “lente”: le scan remonte une trace, mais l’attaque a déjà évolué. Ici, les logs sont essentiels, car les fichiers peuvent déjà avoir été modifiés ou nettoyés par le malware lui-même. Problème de permissions: vous remplacez des fichiers, mais le serveur ne respecte pas les permissions attendues. Résultat: le malware peut réécrire ou le code légitime peut être empêché. Dans ce cas, l’analyse des droits système est une partie du remède. Site géré via dépôt ou déploiement: le malware peut survivre dans la source si votre pipeline pousse des artefacts “contaminés”. Si vous utilisez un système de déploiement, vérifiez la provenance des fichiers.
Ces cas limites rappellent un point: la remédiation n’est pas uniquement technique, c’est aussi un effort de compréhension.
Ce qu’il faut éviter pendant la remédiation
Même avec les bonnes intentions, certaines actions aggravent les dégâts.

D’abord, éviter de réinstaller “par-dessus” sans analyse. Remettre une copie saine peut être efficace, mais si la base ou des droits d’accès restent compromis, vous relancerez l’incident.

Ensuite, éviter de changer des mots de passe avant de contenir. Si l’attaquant a déjà une session active, changer un mot de passe peut n’avoir aucun effet immédiat.

Enfin, éviter de désactiver les logs ou de supprimer l’historique. Quand l’incident revient, vous devrez comprendre pourquoi, et sans chronologie, c’est difficile.
Mettre à jour la stratégie de prévention, pas juste le plugin de sécurité
Une fois le site remis en ligne, la prévention mérite une attention particulière. Le but n’est pas d’installer “tout ce qui existe”, c’est de choisir ce qui correspond à votre contexte.

Par exemple, si votre équipe dépend fortement d’un thème personnalisé, vous devrez intégrer une routine de revue de changements. Si vos plugins ne sont pas maintenus avec discipline, il faut prioriser la réduction de surface: supprimer les plugins inutiles, mettre en place des mises à jour régulières, et surveiller les plugins orphelins.

Et si vous gérez plusieurs sites, standardisez les accès: comptes séparés, principe du moindre privilège, et une procédure de déploiement qui utilise des sources propres.
Garder une trace pour la prochaine fois
Quand tout est redevenu stable, prenez une heure pour documenter. Cela paraît administratif, mais c’est ce qui permet de gagner du temps la prochaine fois.

Notez:
quel signal a déclenché l’alerte quels fichiers et quelles tables ont été modifiés quelles actions ont réellement stoppé la persistance quelles mesures de durcissement ont été ajoutées
C’est aussi un moyen de calmer l’incertitude. Les incidents WordPress se ressemblent, mais vos preuves et vos corrections doivent être spécifiques à votre site.
Règle d’or: la remédiation suit une logique, pas une émotion
Un scanner malware WordPress peut vous dire qu’il y a un risque. La partie la plus importante, c’est de transformer ce signal en plan d’action rationnel: contenir, comprendre le périmètre, nettoyer avec méthode, verrouiller l’accès et vérifier la cohérence.

Le plus frustrant dans ce type d’incident, c’est la sensation de “finir sans être sûr”. Or, avec une démarche structurée et une validation de cohérence, on retrouve le contrôle. Vous ne cherchez pas seulement à faire disparaître l’alerte, vous cherchez à rendre le site résilient, avec des preuves et des garde-fous pour la suite.