Quand un site WordPress commence à publier des pages sans que personne ne les ait écrites, ce n’est plus un simple “bug”. Ce genre d’incident ressemble souvent à une prise de contrôle, ou à une compromission plus subtile, où l’objectif n’est pas de casser le site tout de suite, mais https://gardewp.fr/ de l’empoisonner progressivement: génération de pages pour du référencement parasite, redirections vers des domaines suspects, chargements de scripts malveillants, et parfois un retour arrière difficile une fois que plusieurs couches ont été mises en place.
Dans ce billet, je vais me concentrer sur un symptôme très précis, les pages générées automatiquement, et sur la façon de les nettoyer sans empirer le problème. Je parle en conditions réelles, avec les pièges qu’on rencontre quand on “désinfecte” au lieu de “réparer”.
Quand WordPress génère des pages toutes seules, qu’est-ce que ça signifie ?
WordPress ne fabrique pas des pages par lui-même. Si du contenu apparaît dans la partie Pages, des articles populent, ou des URLs nouvelles sont visibles dans le sitemap alors qu’aucune création n’a été déclenchée, il y a généralement un mécanisme automatisé derrière.
Les scénarios les plus fréquents que j’ai vus sur des sites clients ressemblent à ceci :
- un utilisateur a été ajouté avec des droits élevés, parfois en masquant l’action derrière un plugin de gestion ou un script récurrent ; des fichiers PHP ont été modifiés dans le thème, un plugin, ou parfois directement à la racine pour exécuter du code au chargement ; une tâche planifiée (souvent via cron) réécrit des pages, injecte du contenu, ou appelle une URL externe ; la base de données contient des entrées créées par un script (posts et pages), parfois avec des patterns reconnaissables dans le contenu ou les métadonnées ; un fichier de type .htaccess ou un script d’optimisation a été détourné pour injecter du contenu ou rediriger.
Avant de “nettoyer”, il faut donc comprendre ce qui crée vraiment les pages. On peut désinfecter un symptôme, mais si on laisse le mécanisme actif, le contenu reviendra. C’est la différence entre retirer une tache, et empêcher une fuite.
Signaux d’alerte qui reviennent souvent
Les indices qui accompagnent la génération automatique de pages sont rarement isolés. Ils forment un tableau, et ce tableau aide à deviner le niveau de compromission.
Si vous observez l’un de ces points, traitez-le comme une urgence, pas comme un simple nettoyage :
- de nouvelles pages apparaissent avec un contenu incohérent, des textes “mélangés”, ou des sections répétées sur plusieurs URL ; le site redirige vers des pages étrangères, ou charge des scripts depuis des domaines qu’on ne reconnaît pas ; le trafic augmente sans raison, surtout sur des URLs qui ne devraient pas exister ; des thèmes et plugins changent de version “tout seuls” dans l’interface, ou des fichiers modifiés apparaissent dans votre gestionnaire de fichiers ; le fichier wp-content, particulièrement les dossiers plugins et uploads, contient des fichiers inattendus, avec des noms aléatoires ou des extensions non standard.
Le piège, c’est de croire que “c’est juste du spam SEO”. Oui, parfois c’est surtout du spam SEO. Mais dans la pratique, le spam SEO est souvent l’étape visible, tandis que les accès et la persistance sont le vrai danger.
Ce qu’il faut éviter pendant le nettoyage
Quand on enlève un virus WordPress, le réflexe humain est d’agir vite. Mais certains gestes accélèrent la propagation ou rendent la suppression plus coûteuse.
Première erreur : supprimer au hasard. Si vous supprimez des fichiers pendant que le site tourne, vous risquez d’empêcher un diagnostic utile, tout en laissant une autre porte d’entrée en place.
Deuxième erreur : restaurer sans couper la persistance. Une restauration depuis une sauvegarde ancienne peut être efficace, mais seulement si vous supprimez les mécanismes qui réalimentent les pages.
Troisième erreur : ne pas regarder la base. Beaucoup de “pages générées” sont en réalité des entités ajoutées dans la base, donc même si vous corrigez quelques fichiers, les contenus déjà injectés restent, ou de nouvelles versions sont régénérées.
Quatrième erreur : “re-téléverser WordPress” sans vérifier les thèmes et plugins. Réinstaller le core WordPress remplace des fichiers du système, mais ne neutralise pas un plugin compromis, ni une altération de thème, ni un script en racine.
Je le dis simplement : l’objectif n’est pas de remettre WordPress en état “standard”. L’objectif est de retrouver ce qui exécute le code, puis d’éliminer l’exécution.
Comprendre le mécanisme de génération : ce que vous pouvez vérifier sans casser
Avant d’entrer dans le dur, il y a des vérifications qui orientent. Elles ne demandent pas forcément des outils exotiques.
Les indices côté contenu WordPress
Dans l’administration, regardez les pages nouvelles et essayez de repérer des motifs. Un contenu généré automatiquement a souvent :
- des structures répétées, des titres nombreux et proches ; des sections “remplies” avec des phrases qui n’ont pas de sens éditorial ; parfois des liens sortants en masse, vers des domaines non cohérents.
Si vous avez accès aux timestamps et aux auteurs, regardez aussi si les pages ont un auteur “technique”, ou si le champ date colle à un pic d’activité serveur.
Les indices côté fichiers
Sur un site WordPress compromis, le point de départ le plus courant reste le trio : thèmes, plugins, et quelques fichiers “piégés” en racine ou dans wp-content.
Ciblez en priorité :
- un thème modifié, un plugin installé récemment ou jamais utilisé, des fichiers dans wp-content/uploads dont la présence n’a pas de raison logique.
Je ne recommande pas de se limiter aux fichiers PHP. Parfois la compromission passe par du JavaScript injecté, des fichiers cachés, ou des scripts chargés au chargement.
Les indices côté base de données
Les pages générées sont des entrées dans la base, donc cherchez :
- les créateurs, les utilisateurs ajoutés récemment, les posts typés page ou article, des champs de contenu contenant des marqueurs d’injection (par exemple des balises inattendues ou du code encodé).
Sans vous forcer à “lire la base à la main”, au minimum repérez les dates d’apparition des entrées suspectes. Cela vous aide à isoler le moment où la persistance a commencé à fonctionner.
Nettoyer efficacement : une méthode orientée “preuves”
La désinfection sérieuse suit rarement une logique “je supprime et j’espère”. Elle ressemble plus à une enquête.
Étape 1 : verrouiller le site pour stopper la génération
Dès que vous identifiez des pages en création, coupez la génération au plus vite. Sinon, vous nettoyez pendant que quelqu’un vous réinfecte.
Selon votre niveau d’accès, vous pouvez réduire l’exposition :
- mettre le site en maintenance, bloquer l’accès à l’administration si vous suspectez des connexions frauduleuses, limiter l’exécution du code suspect (sans casser tout le site).
Si le site génère via cron, le blocage doit agir sur l’environnement, pas uniquement sur les pages visibles.
Étape 2 : dresser un inventaire rapide des modifications
Avant de toucher, prenez une “photo” de l’état actuel.
Sur un site compromis, les fichiers changés sont souvent visibles via la comparaison ou par la date de modification. Sur un hébergement qui expose des fonctions de comparaison, c’est pratique. Sinon, un relevé simple des dossiers touchés, et une liste des fichiers récemment créés, fait déjà gagner du temps.
Vous cherchez surtout :
- des plugins ou thèmes apparus récemment, des fichiers PHP avec un contenu inhabituel, des modifications dans wp-config.php ou .htaccess, des scripts dans des emplacements non attendus.
Étape 3 : éliminer la source d’exécution avant de supprimer le contenu
C’est un point clé. Si vous supprimez uniquement les pages générées, et qu’une porte d’entrée reste active, elles reviendront.
À ce stade, il faut traiter l’exécution :
- neutraliser ou retirer les plugins et thèmes suspects, vérifier les fichiers modifiés, supprimer les backdoors.
Sur WordPress, la backdoor ne se cache pas toujours dans un fichier exotique. J’ai vu des compromissions où le code malveillant était inséré dans un fichier censé gérer une fonctionnalité classique, et ça passait pour “un ajustement”.
https://gardewp.fr/nettoyage-malware-wordpress/Étape 4 : nettoyer la base après avoir stoppé la persistance
Une fois la génération stoppée, vous pouvez nettoyer les entités injectées. Ici, l’objectif n’est pas d’effacer toute votre base, mais de supprimer ce qui a été créé pendant la fenêtre de compromission.
Ce travail est plus sûr si vous :
- identifiez la période approximative, supprimez uniquement les pages et posts suspects, vérifiez aussi les utilisateurs créés, et les métadonnées associées.
Si vous avez des captures des pages ou des URL, vous pouvez les recouper avec la base.
Vérifier la présence d’un accès frauduleux et corriger la persistance
Les pages automatiques viennent souvent d’un accès. Un utilisateur compromis peut lancer des actions via l’interface, ou via un script.
Commencez par regarder les comptes :
- utilisateurs ajoutés récemment, rôles anormaux, noms d’utilisateurs qui ne correspondent à aucune pratique interne, comptes qui ont des habitudes de connexion étranges.
Puis corrigez la sécurité :
- changer tous les mots de passe des comptes WordPress et des comptes ayant accès au serveur, invalider les sessions, vérifier la présence d’outils tiers qui ajoutent des comptes ou modifient le profil.
Un détail qui m’a déjà fait perdre une journée : sur certains hébergements, l’accès a pu être conservé côté système (shell, FTP, SFTP) même après avoir supprimé l’utilisateur WordPress. Donc, si vous avez accès au serveur, vérifiez aussi les logs d’authentification.
Réinstaller le core WordPress : utile, mais pas suffisant
Réinstaller WordPress core est une étape classique. Elle sert à remplacer les fichiers “propres” du système.
Mais je veux être clair sur le cadrage : réinstaller le core n’enlève pas un plugin compromis, ni un fichier malveillant dans wp-content, ni un cron injecté. Ça remet au propre uniquement ce qui relève du core.
En pratique, ça s’intègre comme un rempart :
- après avoir identifié et retiré la source dans thèmes et plugins, avant de remettre le site en production, avec une vérification que les fichiers re-téléversés ne se régénèrent pas tout de suite.
Si après une réinstallation le site se réinfecte immédiatement, c’est un signal : la porte d’entrée n’est pas dans le core.
Un plan d’action concret, quand vous devez agir vite
Voici une façon de procéder qui limite la casse. L’idée est de gagner en certitude rapidement, sans tout détruire.
- Mettre le site en maintenance et couper l’exécution si possible, pour stopper la création des pages. Faire un inventaire des fichiers récemment modifiés dans wp-content, thèmes et plugins, ainsi que des fichiers racine suspects. Désactiver puis supprimer les thèmes et plugins non indispensables, surtout ceux apparus récemment. Contrôler les utilisateurs et les rôles, supprimer les comptes ajoutés sans justification. Nettoyer la base après stabilisation, en supprimant les pages générées dans la période identifiée.
Ce plan est volontairement “large”. Il vous donne une logique de tri avant d’entrer dans le diagnostic fin.
Nettoyer les pages générées automatiquement : quoi supprimer, et quoi préserver
Le nettoyage des pages est le moment où beaucoup d’administrateurs se sentent capables, parce que le problème est visible dans l’interface.
Le risque, c’est de supprimer aussi des contenus légitimes, ou de supprimer des pages de manière qui brise des liens internes.
Dans un site compromis, j’aime travailler avec une approche par fenêtre :
- si vous identifiez la date à laquelle les pages ont commencé à apparaître, vous supprimez ce lot, au lieu de “tout effacer” ; si vous repérez des modèles de contenu, vous pouvez cibler les entrées dont le contenu ressemble au gabarit généré.
Si vous avez des outils de gestion ou des exports, cela peut aider. Par exemple, vous pouvez exporter un échantillon des pages injectées, repérer des marqueurs récurrents, puis appliquer le même principe pour identifier le reste.
Et n’oubliez pas les répercussions SEO. Supprimer des dizaines ou centaines d’URL sans stratégie de redirection peut créer une nouvelle vague de 404. La bonne approche dépend du volume et de votre maturité en gestion SEO, mais au minimum, gardez à l’esprit que “effacer” n’équivaut pas toujours à “remettre propre”.
Traquer le code malveillant : les patterns qui reviennent
Sans entrer dans une recette universelle, il existe des patterns fréquents dans les compromissions qui génèrent des pages.
Ce que je recherche typiquement :
- des appels à des fonctions d’exécution dynamique dans des fichiers où elles n’ont pas vocation à être présentes ; des chaînes encodées puis décodées au chargement ; des inclusions conditionnelles basées sur des paramètres d’URL ou un agent utilisateur ; des requêtes sortantes vers des domaines externes, au moment où WordPress charge une page.
Le détail important : parfois le code n’est pas dans le fichier “principal” qu’on s’attend à trouver. Il est dans un fichier appelé très tôt, via une dépendance ou un mécanisme d’amorçage. C’est pour ça que “je vois un truc dans un plugin, je le supprime” ne suffit pas toujours. Il faut suivre le chemin d’exécution.
Les cas limites qui compliquent le nettoyage
Sur le terrain, il y a plusieurs situations où la procédure “standard” donne des résultats incomplets.
1) Le contenu revient après une suppression
Si les pages reviennent après suppression, vous avez presque toujours un mécanisme actif :
- cron, tâche planifiée, script d’événement, ou une persistance dans un plugin encore présent, même désactivé.
Sur certains environnements, la désactivation de plugins côté administration ne stoppe pas une exécution si le code est ailleurs. D’où l’importance de contrôler les fichiers et les tâches.
2) Le site semble propre, mais les pages apparaissent ailleurs
Le générateur peut ne pas utiliser l’interface WordPress classique. Il peut injecter des contenus “latents”, ou publier sans que vous voyez immédiatement tout dans l’admin. Dans ce cas, les logs et la base deviennent vos meilleures sources d’information.
3) Votre sauvegarde est “contaminée”
Restaurer une sauvegarde prise après la compromission, sans s’en rendre compte, peut remettre la porte d’entrée en place. C’est un piège fréquent dans les organisations où les sauvegardes sont automatisées et peu contrôlées.
La solution n’est pas forcément “changer la sauvegarde”, parfois il suffit de choisir une sauvegarde antérieure et de valider par inspection que les fichiers clés ne sont plus modifiés.
Sécuriser après nettoyage, pour éviter la rechute
Le nettoyage enlève des symptômes. La prévention limite la probabilité d’un retour.
La sécurisation passe souvent par quelques fondamentaux :
- mots de passe forts et uniques, y compris côté hébergement ; mise à jour régulière des thèmes et plugins, pas au hasard, mais sur une base de compatibilité ; suppression des plugins inutilisés, car c’est souvent une surface d’attaque ; durcissement des accès à wp-admin et wp-login, selon vos contraintes ; surveillance simple des modifications de fichiers et des créations d’utilisateurs.
Je préfère aussi une approche “observabilité” légère : garder un œil sur les logs d’accès et sur les pics d’activité. Quand un script commence à recréer des pages, il faut le voir le plus tôt possible.
Comment vérifier que le site est vraiment nettoyé
On ne peut pas promettre une propreté absolue au sens mathématique, mais on peut valider avec des signaux concrets.
Avant de remettre le site en ligne sans restrictions, cherchez :
- plus de nouvelles pages générées sur une période significative ; aucune nouvelle modification dans les dossiers suspects ; aucune création d’utilisateurs imprévus ; un contenu rendu propre, sans scripts externes nouveaux ; un trafic et des requêtes stables, sans patterns automatiques.
En pratique, sur un incident “pages générées automatiquement”, j’accorde une importance particulière au fait que l’apparition s’arrête. Si tout s’arrête après suppression de la source, vous avez généralement gagné.
Outils et automatisation : utiles, mais à cadrer
Les scanners et outils de détection peuvent aider, surtout pour identifier des signatures connues ou des fichiers modifiés. Mais dans un incident de pages générées automatiquement, j’insiste sur le fait que l’outil ne remplace pas l’enquête.
Un scanner peut :
- trouver des fichiers suspects, signaler des comportements anormaux, vérifier l’intégrité de certains répertoires.
Mais si la persistance passe par une voie non couverte par l’outil, vous pouvez avoir un faux sentiment de sécurité. Le bon usage consiste à s’appuyer sur les résultats, pas à s’y abandonner.
Enlever virus WordPress, le point de décision le plus important
Le moment critique, c’est quand vous devez choisir entre “désinfecter” et “reconstruire”. Si le site est central dans votre activité, ou si la compromission a touché plusieurs couches, reconstruire peut être plus rentable qu’une désinfection artisanale.
Reconstruire, dans les cas graves, signifie souvent :
- réinstaller proprement le site (core, thèmes, plugins validés), restaurer uniquement le contenu légitime après validation, vérifier chaque élément de persistance, puis rétablir l’accès.
Ce n’est pas forcément plus “cher”. C’est surtout moins incertain, surtout quand le site a déjà eu plusieurs cycles de nettoyage.
Si, au contraire, vous avez une compromission localisée, une source de génération identifiée, et des délais maîtrisés, la désinfection ciblée fonctionne très bien.
Un dernier réflexe : documenter ce que vous découvrez
Après un incident, la mémoire s’efface vite. Pourtant, ce que vous notez devient votre guide lors de la prochaine alerte.
J’encourage simplement à garder :
- la date approximative du début, les fichiers ou plugins responsables identifiés, les utilisateurs compromis supprimés, la méthode de nettoyage utilisée, et les contrôles effectués avant remise en ligne.
C’est ce qui permet, la prochaine fois, de ne pas refaire toute l’enquête depuis zéro.
Si vous voulez, décrivez-moi ce que vous observez exactement (nombre de pages, période d’apparition, plugins ou thèmes récemment installés, et si vous voyez des redirections). Je peux vous aider à formuler une stratégie de nettoyage plus ciblée, adaptée à votre configuration.