Quand un site WordPress commence à “agir bizarrement”, on peut perdre des heures à chercher la cause au mauvais endroit. Un plugin modifié, des droits trop ouverts, une injection de contenu dans le thème, un compte admin qui n’est plus sous contrôle, une base de données contaminée… Dans la pratique, le diagnostic avance vite si vous suivez une logique. Pas seulement “scanner malware WordPress”, puis attendre un rapport, mais vérifier ce que le rapport dit, ce qu’il ne dit pas, et surtout si le site revient à un état propre.
Ce qui suit est une check-list de diagnostic en 10 étapes. Elle est volontairement orientée terrain, avec des choix pragmatiques en cas de doute.
1) Clarifier le symptôme et le contexte
Avant de lancer des scans, prenez deux minutes pour décrire exactement ce qui se passe. Le site a-t-il perdu du trafic, affiché un message “page introuvable”, redirige-t-il vers une autre URL, ou une partie seulement du contenu a-t-elle été altérée (par exemple le footer, un encart en bas de page, ou une poignée d’articles) ?
Cherchez aussi le contexte temporel. La contamination s’est-elle produite après une mise à jour WordPress, un changement de thème, l’installation d’un plugin, l’ajout d’un nouveau compte, ou une modification côté hébergement (crons, cache, règles WAF) ? J’ai déjà vu des “malwares” qui étaient en fait un plugin fraîchement activé qui cassait le cache, puis rendait des pages incohérentes. À l’inverse, j’ai aussi vu des sites qui semblaient “instables” pendant des jours, avant que la redirection malveillante ne devienne visible.
Notez également l’étendue : une page, tout le site, le backend seulement, ou uniquement sur certains navigateurs et pays. Cela guide les priorités.
2) Isoler le site pour éviter la propagation
Si vous suspectez une infection active (redirection, pages qui changent, formulaires qui injectent du contenu), évitez de continuer à produire du trafic. Le but n’est pas de “cacher” le problème, c’est de stopper les mécanismes qui aggravent la situation.
Concrètement, commencez par vérifier que votre accès aux fichiers et à la base de données reste fonctionnel. Ensuite, selon votre configuration, limitez les visites anonymes, coupez temporairement l’exécution des traitements déclenchés par des requêtes (par exemple certains cron) si vous savez lesquels. En cas de doute sur l’impact, privilégiez une mise en maintenance et un blocage au niveau de l’edge (si vous avez un WAF ou un reverse proxy) plutôt que de supprimer au hasard.
Je recommande aussi de sauvegarder tout de suite une copie “avant nettoyage” des éléments que vous allez toucher: fichiers WordPress, configuration (notamment .htaccess), et export de la base si possible.
3) Vérifier le compte admin et la cohérence des utilisateurs
Les malwares WordPress ne se limitent pas aux fichiers. Le contrôle d’un compte admin est un chemin fréquent, surtout après un vol de mot de passe. Avant de passer au code, inspectez les utilisateurs WordPress.
Regardez les créations récentes, les rôles, et les adresses associées. Un compte admin avec un email étrange, créé récemment, ou un nom d’utilisateur que vous ne reconnaissez pas, n’est pas une preuve absolue de compromission, mais c’est un signal fort. Vérifiez aussi les connexions suspectes si votre hébergeur ou votre plugin de sécurité expose des logs.
Un détail qui aide beaucoup : WordPress enregistre parfois des changements de mot de passe et des événements liés aux sessions. Si vous voyez des modifications en décalage avec votre activité, c’est une piste majeure.
4) Relever les fichiers et bases modifiés récemment
Une fois l’accès “humain” stabilisé, passez au niveau “système”. L’objectif est de repérer des modifications hors contexte, en commençant par les fichiers qui servent souvent de point d’entrée.
Ciblez:
- les dossiers de plugins et thèmes (surtout si un fichier PHP a des dates de modification très récentes), les fichiers racine (index.php, wp-config.php, .htaccess, éventuellement des fichiers souschargés), les scripts dans des dossiers inattendus (un contenu peut être déposé dans /uploads ou dans des sous-dossiers qui n’ont rien à faire là).
Si vous travaillez avec un hébergement standard, utilisez la date de modification et la taille pour repérer des anomalies. Sur certains cas, un fichier “normal” a une taille légèrement supérieure à la version attendue, signe qu’il a été modifié. Sur d’autres, c’est plus radical, le fichier est remplacé ou contient du code obfusqué.
Gardez ces observations, car un scan automatisé peut trier par “score”, mais votre cerveau suit mieux l’évolution.
5) Lancer un scanner malware WordPress, mais avec méthode
Oui, il faut des scans. Non, ils ne suffisent pas.
Commencez par un scanner “orienté fichiers” et, si disponible, un scanner “orienté base de données”. L’idée n’est pas de croire aveuglément au résultat, mais de l’utiliser comme carte. Quand un outil identifie une signature suspecte, notez exactement:
- le chemin du fichier, l’empreinte ou le snippet identifié, le niveau de confiance mentionné, si l’outil recommande une suppression ou une remise à l’état d’origine.
Attention aux faux positifs. Un plugin légitime qui utilise un minifier ou une logique de cache peut ressembler à un pattern malveillant si le scanner est trop approximatif. À l’inverse, certains malwares “vivants” changent ou s’exécutent seulement sous certaines conditions. Un scan ponctuel peut manquer le mécanisme.
À ce stade, vous cherchez surtout des priorités de vérification manuelle.
6) Contrôler la présence de redirections et injections côté serveur
Un malware WordPress cherche souvent à pousser du trafic vers ailleurs ou à injecter du contenu. Les redirections peuvent être:
- explicites dans .htaccess, dissimulées dans des fichiers PHP du thème ou d’un plugin, déclenchées par une condition (user agent, pays, requêtes à certains chemins).
Votre diagnostic doit donc examiner les règles de redirection, y compris celles “indirectes”. Par exemple, si un fichier est censé contenir une configuration de performance et qu’il inclut un bloc conditionnel autour de $ SERVER ou de substr($SERVER[…]), c’est un drapeau rouge.
Si vous voyez des injections de scripts dans le HTML final, vérifiez le point de sortie: footer.php, header.php, ou des hooks ajoutés par un plugin. Dans des cas sournois, la page semble normale au premier chargement, mais un script est ajouté via un appel asynchrone.
7) Inspecter les hooks WordPress et les points d’entrée PHP
WordPress offre des points d’entrée très pratiques pour “se greffer” sans casser tout le site. Sur un site compromis, on retrouve souvent des fonctions qui enregistrent des hooks, ou des fichiers PHP ajoutés à la volée.
Là, je préfère une approche ciblée plutôt qu’une lecture exhaustive. Cherchez:
- des fichiers PHP qui ne correspondent à aucun plugin ou thème réellement installé, des inclusions “dynamiques” (require, include) vers des chemins bizarres, des appels à base64 decode, eval, gzinflate, strrot13, ou des déchiffrements en chaîne.
Un plugin légitime peut utiliser certaines de ces fonctions, mais dans un contexte différent. Ce qui compte, c’est la structure autour, la manière dont l’exécution est conditionnée, et la cohérence avec le rôle du plugin.
Si le scan malware WordPress vous donne un fichier suspect, ce fichier devient votre centre de gravité. Lisez-le comme vous liriez une lettre, en repérant l’intention: “à quel moment ça s’exécute” et “vers où ça envoie”.
8) Vérifier la base de données: options, contenus, et champs inattendus
Un autre angle, souvent sous-estimé, concerne la base. Selon le type de compromission, les charges utiles peuvent être:
- stockées dans wp_options (par exemple des scripts, des paramètres, des drapeaux d’exécution), injectées dans la table de posts ou dans des meta, ou cachées dans des champs utilisés pour des shortcodes ou des widgets.
Le scanner peut détecter certains patterns dans la base, mais parfois il ne sait pas interpréter un contenu qui n’est pas “signature-based”. D’où l’intérêt d’observer les anomalies liées au stockage: options nouvellement créées ou très modifiées, entrées dont la valeur n’a rien à faire là.
Concrètement, si vous avez l’habitude de gérer WordPress, vous saurez ce que “devrait” contenir une option standard. Tout ce qui ressemble à un code exécutable ou à une chaîne de déchiffrement mérite une vérification.
Trade-off réel ici : remplacer intégralement la base par une sauvegarde peut être propre, mais pas toujours possible si la sauvegarde est trop ancienne. Dans ce cas, un nettoyage ciblé de champs identifiés est parfois le meilleur compromis, au prix d’un travail plus fin.
9) Confirmer l’état “propre” avant toute suppression totale
Une erreur classique consiste à supprimer un fichier suspect sans comprendre comment il s’insère, puis constater que le site garde des symptômes. Pourquoi ? Parce que la charge utile a d’autres points de lancement, ou parce qu’un compte compromis reste actif, ou parce que le même script est régénéré ailleurs.
Avant d’effacer à grande échelle, faites une boucle de vérification:
- après la correction d’un fichier ou d’une option, testez des pages clés, vérifiez l’interface publique et le backend, surveillez la présence de redirections ou de scripts ajoutés.
Je recommande aussi de faire des tests “contradictoires”. Par exemple, si le problème n’affecte que certaines pages, testez une page non exposée pour confirmer que vous n’avez pas cassé un élément normal. Si le site redirige certains navigateurs, testez au moins avec deux configurations de navigateur, idéalement avec et sans cache.
Le but n’est pas d’être parano, c’est de minimiser les cycles “on supprime, ça revient”.
10) Réparer vraiment: rotation des secrets, durcissement, et plan de retour
Quand vous arrivez à un état où le site ne redirige plus et n’affiche plus de contenu injecté, le travail n’est pas terminé. Une infection peut laisser derrière elle une porte ouverte, et un nettoyage partiel peut se transformer en récidive.
Pensez en “réparation” plus qu’en “nettoyage”. Les actions de fond qui font la différence sont:
- changer tous les mots de passe susceptibles d’avoir été exposés, notamment les comptes admin, révoquer les sessions actives si c’est possible, régénérer des clés WordPress (AUTH SALTS) si votre configuration le permet, remettre les thèmes et plugins à leur état d’origine, idéalement via des téléchargements depuis les sources officielles, réexaminer les droits d’écriture sur les fichiers, et limiter les chemins où un plugin peut déposer du contenu.
Sur le plan pratique, si vous avez une sauvegarde saine, la méthode la plus robuste reste de restaurer à partir de cette sauvegarde, puis de réappliquer uniquement les changements nécessaires. Si vous n’avez pas une sauvegarde suffisamment récente, alors vous devez compenser par une vérification fine de ce que vous remettez en place.
Voici la check-list récapitulative en 10 étapes, en version action.
Clarifier le symptôme et le contexte, en notant la période et l’étendue. Isoler le site pour éviter la propagation, au moins en limitant les accès non essentiels. Vérifier les utilisateurs WordPress, en particulier les comptes admin récents et inattendus. Relever les fichiers et dossiers modifiés récemment, surtout plugins, thèmes, racine, .htaccess, wp-config.php. Lancer un scanner malware WordPress, puis noter précisément les résultats et limites (faux positifs, exécution conditionnelle). Contrôler les redirections et injections côté serveur, notamment dans .htaccess et les sorties HTML. Inspecter les hooks WordPress et les points d’entrée PHP, avec lecture ciblée des fichiers signalés. Vérifier la base de données, en examinant options, contenus et champs meta inattendus. Confirmer l’état prope après chaque correction, via tests de pages publiques et backend. Réparer vraiment avec rotation des secrets, remise à l’origine des composants, durcissement, et plan de retour.Deux pièges qui coûtent cher
Premier piège, compter uniquement sur “le scan”. Les outils sont utiles, mais ils ont deux faiblesses classiques: ils ne voient pas toujours les charges dynamiques et ils peuvent sous-estimer les modifications logicielle sans signature.
Deuxième piège, corriger le symptôme sans verrouiller https://gardewp.fr/nettoyage-malware-wordpress/ les accès. Un compte compromis peut réinstaller la même charge utile en quelques minutes. Si vous ne changez pas les secrets et que vous ne révoquez pas les sessions, vous “nettoyez” en réalité une branche, pas la racine.
Ce que j’attends d’un résultat de scanner, et ce que j’en fais
Quand je traite un incident, je traite chaque alerte comme une hypothèse, pas comme une sentence. Je rassemble:
- les fichiers signalés, les chemins d’exécution suspectés, les changements de date, et les signes fonctionnels (redirections, injection de scripts, comportements conditionnels).
Ensuite seulement, je décide si je restaure, si je remplace des dossiers entiers, ou si je corrige une portion précise.
Cette méthode réduit les “coups de scalpel ratés”. Elle permet aussi d’expliquer le diagnostic à un client ou à une équipe: vous n’êtes pas en train de “faire au hasard”, vous suivez une chaîne logique qui relie preuve technique et impact observable.
Checklist de diagnostic en 10 étapes, version courte (sans détours)
| Étape | Objectif | |---|---| | 1 | Décrire symptôme, période, étendue | | 2 | Isoler le site pour limiter l’aggravation | | 3 | Contrôler utilisateurs, rôles, connexions | | 4 | Repérer fichiers modifiés récemment | | 5 | Lancer scanner malware WordPress, relever et trier | | 6 | Vérifier redirections et injections serveur | | 7 | Inspecter hooks et points d’entrée PHP | | 8 | Contrôler base: options, posts, meta | | 9 | Valider l’état propre après chaque correction | | 10 | Réparer: rotation secrets, remise à l’origine, durcissement |
https://gardewp.fr/Une dernière question à vous poser avant d’agir
Si vous ne deviez répondre qu’à une seule question, ce serait celle-ci: “comment le site a été compromis, et quelle porte reste ouverte ?” Sans cette réponse, vous serez toujours en train de rattraper des symptômes.
Si vous voulez, dites-moi ce que vous observez (redirection, pages modifiées, messages navigateur, impact sur le backend, plugins installés récemment, et ce que le scanner malware WordPress a remonté). Je peux vous aider à transformer ce diagnostic en plan de corrections, avec l’ordre le plus sûr dans votre cas.