Quand un site WordPress se fait infecter, le plus difficile n’est souvent pas de “nettoyer”. C’est d’empêcher le retour du problème, parfois par vagues, parfois avec des symptômes qui changent. On supprime une charge malveillante, puis deux semaines plus tard on constate des redirections bizarres, une augmentation du trafic vers des pages pornos, ou encore des comptes administrateurs qui “réapparaissent” alors qu’on croyait avoir tout restauré.
J’ai vécu plusieurs cas où le nettoyage initial semblait propre, mais où l’infection avait surtout été traitée en surface. Les fichiers malveillants sont un morceau du puzzle. L’autre morceau, c’est l’accès. Si une porte d’entrée reste ouverte, le malware revient comme un locataire indésirable qui connaît déjà le code de la serrure.
Voici une approche pragmatique, centrée sur une idée simple: supprimer le malware WordPress, oui, mais surtout fermer les chemins de réinfection.
Comprendre ce qui doit être éradiqué (pas seulement supprimé)
Sur WordPress, un malware peut être:
- un script injecté dans le thème, les fichiers PHP, ou des fichiers “exécutables” placés dans des dossiers inattendus, une porte d’entrée via un plugin ou une fonction mal configurée, une compromission via un compte (mot de passe réutilisé, session volée, jeton de connexion compromis), un usage de l’infrastructure (serveur, base de données, tâches cron, règles de reverse proxy) pour garder la main.
Le piège classique, c’est de se concentrer uniquement sur les fichiers. On remplace le dossier du thème, on réinstalle quelques plugins, puis on relance. Si la base de données contient des options https://gardewp.fr/ modifiées ou des utilisateurs créés à l’insu, le site réinfectera son propre cache, réinstallera des charges, ou continuera à exécuter du code via des hooks.
À l’inverse, on peut “réparer l’accès” sans repérer les fichiers corrompus. Résultat: le site semble stable quelques jours, puis les scripts de persistance se déclenchent, souvent via un cron, un événement, ou un appel à une page précise.
L’objectif des mesures ci-dessous est de traiter les trois niveaux: fichiers, base de données, accès.
Les 7 mesures qui réduisent vraiment le risque de re-infection
1) Faire un inventaire avant de toucher à quoi que ce soit
Avant de supprimer quoi que ce soit, prenez le temps de figer l’état. Sur les sites déjà en production, je conseille de procéder avec une copie et un plan de retour. Un nettoyage “à l’aveugle” peut faire disparaître des indices importants, et certains malwares modifient des fichiers au moment où ils détectent un changement.
Concrètement, cela veut dire:
- sauvegarder fichiers et base de données (au minimum une copie de la base + un export, plus un snapshot des répertoires WordPress et des extensions), lister les fichiers modifiés récemment (dates et tailles changées), relever les plugins installés et leurs versions, et noter ceux qui ont été ajoutés ou mis à jour dans la période d’incident, vérifier les logs disponibles (erreurs PHP, accès web, éventuels logs du panneau d’hébergement).
Cette étape paraît lente, mais elle évite les “on a supprimé trop tôt” ou “on a restauré sans savoir d’où ça venait”.
2) Passer au crible les points d’exécution WordPress et les emplacements typiques
Supprimer malware WordPress, ce n’est pas juste effacer des lignes. C’est repérer ce qui s’exécute réellement.
Sur WordPress, les zones qui servent souvent de levier sont:
- le fichier wp-config.php (ou des ajouts suspects à la configuration), les thèmes et leurs fonctions (fichiers PHP dans le thème enfant ou parent), le dossier wp-content/plugins et, plus finement, les fichiers PHP des plugins, les fichiers “cachés” ou inattendus dans wp-content/uploads (parfois le malware se dépose en fichiers PHP camouflés, ou déclenche via une requête), les mécanismes de persistance côté base de données: options, transients, événements d’action.
Je recommande une logique d’examen plutôt que “recherche de mots-clés au hasard”. Une recherche de chaînes comme “base64” ou “eval” aide parfois, mais des malwares sérieux ont appris à se déguiser. Le bon réflexe, c’est de comparer avec une installation saine de la même version WordPress, et de repérer ce qui n’a rien à faire là.
Edge case que j’ai rencontré: un thème “fait maison” a été compromis, mais il contient aussi du code légitime spécifique. Le nettoyage doit donc être précis, pas une réinitialisation totale. Si vous effacez les fonctions métier du thème, vous allez créer une nouvelle crise, et parfois le malware réinjecte le code modifié en exploitant les différences.
3) Restaurer à partir d’une base saine, plutôt que “patcher au fil de l’eau”
Une approche qui marche souvent, surtout quand l’infection est diffuse, consiste à restaurer WordPress depuis une source saine, puis à réinjecter uniquement le nécessaire.
Dans la pratique:
- on réinstalle les fichiers WordPress “core” à l’identique, on remplace thèmes et plugins par des versions officielles ou des versions vérifiées, on régénère les fichiers de cache, on traite la base de données avec précision (pas seulement un “reset” global).
Le bon compromis, c’est d’éviter le “on nettoie fichier après fichier, sans cadre”. Quand le malware est déjà installé, il peut avoir modifié des références, injecté dans des options, ou créé des hooks qui se rebranchent sur un fichier plus tard.
En revanche, si votre site est très personnalisé (thème sur-mesure, plugins internes), une restauration complète peut être trop risquée. Dans ce cas, l’approche “restauration partielle” est préférable: restaurer tout ce qui est standard, puis vérifier manuellement le sur-mesure pour ne pas effacer des fonctionnalités essentielles.
4) Révoquer immédiatement l’accès: mots de passe, sessions, comptes fantômes
C’est la mesure la plus sous-estimée. On peut supprimer tous les fichiers malveillants visibles et laisser derrière soi une méthode d’accès encore valide.
Dès que l’incident est identifié, traitez l’accès comme compromis, même si vous ne voyez rien d’anormal. Changez les mots de passe des comptes WordPress, et si possible ceux de l’hébergement (au minimum FTP/SFTP, accès base de données, comptes administrateur panneau). Révoquez les sessions actives si votre configuration le permet.
Ensuite, vérifiez:
- les utilisateurs WordPress existants (y a-t-il un compte créé sans raison? Un rôle administrateur ou éditeur “inhabituel”?), les utilisateurs dont l’email ou le pseudo ne correspond à aucun acteur connu, les modifications dans la base de données liées aux rôles et capacités.
J’ai déjà vu des cas où un compte “admin” apparaissait après le nettoyage. Le malware n’avait pas besoin d’être présent dans les fichiers au long cours, il lui suffisait d’avoir un accès valide. Une fois le mot de passe changé et les sessions révoquées, le problème s’est arrêté net.
Trade-off: si vous avez une équipe avec un SSO, des comptes partagés ou des outils d’automatisation, la rotation de mots de passe peut casser des intégrations. Prévoyez une fenêtre d’intervention et anticipez les clés API.
5) Nettoyer la base de données avec méthode (options, cron, hooks, transients)
Beaucoup de malwares WordPress se “branchent” via la base de données. C’est souvent là que l’on retrouve le cœur de la persistance: options modifiées, URLs de redirection, contenu injecté, données de planification.
Le point de vigilance, c’est que WordPress stocke énormément d’informations dans la base. Supprimer “au hasard” des tables ou des lignes peut casser votre site. L’idéal est de procéder par comparaison et par corrélation.
Voici ce que je vérifie typiquement pendant un incident:
- les options qui contiennent des URLs ou des scripts inattendus, les transients et contenus “cache” qui peuvent accélérer la réinfection, les événements planifiés (cron WordPress) si votre site a été cible de tâches automatiques, les tables liées aux utilisateurs et leurs rôles, les tables liées à l’activité ou à certains plugins de sécurité si elles sont présentes.
Pour être concret, imaginons un malware qui redirige chaque visite vers une page externe. Si vous corrigez les fichiers PHP mais que l’option de redirection reste dans la base, le site continuera d’exécuter le mécanisme via un hook standard.
Edge case: certains plugins de sécurité ou d’optimisation utilisent la base pour stocker des règles ou des caches. Une suppression globale peut supprimer des paramètres légitimes. Il faut donc une logique de “cible d’abord, suppression ensuite”.
6) Mettre à niveau, mais surtout combler la faille d’entrée (et vérifier les plugins)
Une fois le malware supprimé et l’accès révoqué, il reste une question: par où est-il entré?
WordPress est souvent compromis via un plugin vulnérable, un thème non maintenu, ou une configuration qui laisse des surfaces d’attaque ouvertes. Ici, la simple mise à jour “pour dire” ne suffit pas si votre plugin vulnérable est resté utilisé.
Je recommande d’aligner trois actions:
- mettre à jour WordPress (core) vers une version stable et supportée, mettre à jour les plugins et thèmes, ou les remplacer si l’éditeur ne maintient plus, supprimer les plugins non utilisés, surtout ceux qui n’ont pas de suivi clair.
Vous devez aussi vérifier la cohérence: si un plugin a été ajouté juste avant l’incident, même s’il semble “normal”, traitez-le comme suspect tant que vous n’avez pas validé son intégrité.
Trade-off important: mettre à jour peut casser des compatibilités. Sur un site critique, on teste d’abord en environnement de préproduction ou au moins sur une phase de maintenance courte. Mais rester sur un plugin vulnérable est un pari beaucoup plus risqué que gérer quelques ajustements fonctionnels.
7) Renforcer la surveillance, la détection et la prévention de persistance
Après un incident, le site doit être surveillé comme un système qui a été compromis, même si tout semble revenu à la normale. Le but n’est pas d’obséder, c’est d’attraper la réinfection tôt, avant qu’elle ne se propage, et avant qu’elle n’endommage votre réputation.
Sans faire une usine à gaz, je mets en place un trio:
- une vérification régulière des fichiers et des modifications (intégrité, détection de changements), une surveillance des comptes et des actions (nouvel utilisateur, nouveaux rôles), un suivi des redirections, erreurs anormales, et pics de trafic suspects.
Selon votre hébergement, des logs supplémentaires peuvent être disponibles. Si vous avez accès aux logs web, cherchez des patterns: appels à des endpoints inexistants, requêtes répétées vers des fichiers bizarres dans des dossiers qui ne devraient pas exécuter du code.
Une mesure très “pratique” consiste aussi à limiter ce qui peut exécuter. Les permissions de dossiers, les exclusions, et les règles d’exécution côté serveur comptent. Mais là, les détails dépendent de votre stack (Nginx, Apache, panel d’hébergement). L’idée reste universelle: réduire la surface où une charge peut persister.
Si vous utilisez un plugin de sécurité, considérez-le comme un capteur. Il ne remplace pas le nettoyage correct. Et certains plugins peuvent être eux-mêmes ciblés, donc leur présence ne prouve pas l’absence de malware.
À quoi ressemble une re-infection, et comment réagir sans aggraver
La re-infection n’est pas toujours identique. Parfois, les fichiers infectés ont été nettoyés, mais les hooks dans la base persistent. Parfois, le malware profite d’un répertoire uploads accessible en exécution. Parfois, c’est un mécanisme d’accès qui revient.
Sur mes audits, les signes qui reviennent souvent sont:
- apparition de nouvelles pages ou contenus sans logique éditoriale, redirections vers des domaines externes, surtout visibles sur mobile ou après un parcours précis, baisse soudaine des performances liée à des requêtes internes, nouveaux comptes ou modification des rôles, augmentation de requêtes 404 vers des chemins inconnus, changements dans les fichiers de thème ou de plugin juste après un nettoyage.
La réaction doit être disciplinée. Si vous voyez un signe, ne supprimez pas “encore un dossier” au hasard. Reprenez votre inventaire, comparez avec la sauvegarde saine, et ciblez la zone où le site a recommencé à diverger.
Un réflexe utile: si vous avez fait une sauvegarde avant nettoyage, comparez à nouveau. C’est là que vous récupérez votre autonomie, vous évitez le cercle “ça revient, on réinstalle, ça revient encore”.
Erreurs fréquentes qui coûtent cher (temps, SEO, crédibilité)
Plusieurs schémas reviennent dans les incidents, même sur des sites sérieux.
Première erreur: nettoyer sans sauvegarde exploitable. Quand tout part en fumée, vous perdez l’option de comparaison, et vous finissez par restaurer au plus vite sans certitude.
Deuxième erreur: réinstaller WordPress et quelques plugins, puis garder le thème et les paramètres tels quels. Si le thème a été le vecteur, il ramènera le problème. Si la base contient une option persistante, le problème revient.
Troisième erreur: changer le mot de passe admin sans vérifier les comptes et les sessions actives. Certains malwares créent des utilisateurs ou exploitent des sessions déjà ouvertes.
Quatrième erreur: supprimer des tables ou des lignes “parce que ça a l’air bizarre”. WordPress peut fonctionner sans certaines données, mais la base devient instable, et vous perdez du temps à déboguer ce que vous avez cassé.
Enfin, cinquième erreur: rester sur une faille d’entrée. Le malware ne se nourrit pas de nostalgie, il se nourrit d’un accès. Si le vecteur n’est pas corrigé, la réinfection n’est pas une question de “si”, c’est une question de “quand”.
Comment je planifierais une intervention sur un site réel
Si je devais donner une méthode opérationnelle sans transformer ça en procédure industrielle, je suivrais cette logique en quatre moments:
1) stabiliser et sauvegarder, relever logs et anomalies, 2) nettoyer en ciblant les points d’exécution (fichiers + base), 3) révoquer l’accès, vérifier utilisateurs et sessions, 4) corriger la faille d’entrée, puis surveiller.
Cette séquence réduit les risques de “nettoyage partiel” et limite la période pendant laquelle le site est vulnérable. Elle limite aussi les risques d’erreur humaine, parce que chaque étape prépare la suivante.
Une mesure de réalité: le risque zéro n’existe pas, mais on peut le rendre négligeable
Il existe des scénarios très compliqués, par exemple une compromission au niveau du serveur, ou un accès à l’hébergement compromis. Dans ces cas, le malware peut revenir même si WordPress est “propre”. C’est rare, mais je l’ai vu sur des environnements où les identifiants de l’hôte ou les clés SSH étaient compromis.
Si vous constatez des retours systématiques malgré un nettoyage complet et une rotation de mots de passe, la bonne décision peut être d’escalader: audit serveur, vérification du système de fichiers, reconfiguration des accès, parfois re-déploiement complet de l’environnement.
Pour la majorité des cas WordPress, les sept mesures décrites ici suffisent à casser la chaîne de réinfection. Le point clé est de traiter simultanément le contenu malveillant et la possibilité d’accès, pas seulement l’apparence du site.
Si vous voulez, dites-moi votre situation: plugin/waswo, thème sur-mesure, hébergement (Nginx ou Apache), et ce que vous observez (redirections, accès admin, contenus injectés). Je pourrai vous proposer une check de priorités adaptée, sans tomber dans un “tuto” généraliste.