Quand un site WordPress se met à produire des pages toutes seules, la première réaction est souvent une forme de sidération. On pense à un plugin “qui a dérapé”, à une mise à jour, ou à un serveur instable. Et puis, en ouvrant l’interface, on remarque des URLs qui n’ont rien à faire là, des pages avec des contenus “génériques”, parfois en plusieurs langues, parfois bourrées de liens vers des sites externes. C’est à ce moment que la désinfection WordPress devient une nécessité, mais aussi un travail d’enquête.
La partie la plus délicate n’est pas seulement de supprimer ce qu’on voit. C’est de détecter comment les pages ont été créées automatiquement, avec quel degré de contrôle l’attaque a été réalisée, et surtout quels accès restent ouverts pour que cela ne recommence pas après le nettoyage.
Le symptôme le plus trompeur : “ça n’a l’air que de quelques pages”
Sur beaucoup de sites infectés, les pages automatiques commencent petit. Une semaine, on trouve deux URLs suspectes. Puis dix. Puis, un matin, la pagination du plan de site XML ne ressemble plus à celle du site habituel. Parfois, les pages sont ajoutées comme des brouillons, parfois elles sont directement publiées, parfois elles apparaissent surtout via des redirections.
Le piège, c’est de croire que le nombre de pages est proportionnel à la gravité. Dans certains cas, l’attaquant insère un mécanisme qui regénère des pages à la demande, ou qui les pousse à la publication par vagues. On peut supprimer les pages vues, mais si la commande de génération existe encore, elles reviendront.
J’ai déjà vu une situation où l’équipe “voyait” seulement des pages de type “landing” en HTTP, mais les logs côté serveur montraient un pic régulier d’accès à des scripts dans wp-admin et à des fichiers nouvellement modifiés dans des répertoires inattendus. Les pages étaient la vitrine, le vrai problème était derrière, souvent dans l’ombre.
Où regarder en premier, sans perdre de temps
Avant de partir dans des analyses longues, il faut collecter des indices. L’objectif est simple: relier des pages suspectes à une chaîne d’actions, ou au moins à un moment précis.
Commencez par vérifier si ces pages sont bien des pages WordPress (posts) ou si elles sont produites par autre chose (fichiers statiques, réécritures, scripts). Dans WordPress, l’emplacement logique est la table des contenus (posts), donc les dates de création et l’auteur peuvent déjà raconter quelque chose.
Ensuite, regardez la forme des URLs et la structure des slugs. Les pages créées automatiquement suivent souvent des patterns: préfixes répétitifs, suites numériques, mots-clés “SEO” insérés sans cohérence, ou encore des titres qui reprennent le nom du site + une requête. Ce n’est pas une preuve à elle seule, mais c’est un excellent point de départ pour regrouper les cas.
Un indice concret utile: comparez l’heure de création des pages suspectes avec les heures des accès inhabituels côté serveur. Si vous avez accès à nginx/apache logs, vous pouvez parfois voir une requête déclenchante du type “admin-ajax.php” ou l’appel d’un script au moment où le contenu apparaît. Sans cette corrélation, on avance souvent à l’aveugle.
Identifier les pages suspectes dans WordPress, proprement
Dans l’administration WordPress, les pages automatiques peuvent être visibles comme des “pages” ou comme des “articles”, selon la manière dont l’attaque a fonctionné. Parfois, elles portent un statut incohérent, par exemple publiées mais sans lien dans le menu, ou encore elles apparaissent dans la recherche mais pas dans les pages “normales”.
Sur une installation saine, les auteurs sont cohérents: un admin crée des pages à des moments qui s’alignent avec l’activité éditoriale. Sur une installation compromise, on voit souvent:
- un auteur “admin” ou “éditeur” sans logique un auteur fictif, créé à la volée des pages avec une date de création qui tombe pendant des pics d’accès non expliqués des pages qui partagent un template exact, ou un contenu très similaire
Le détail qui aide beaucoup: regardez “auteur” et “date de création” pour plusieurs pages. Si la plupart ont la même minute ou la même heure, ce n’est généralement pas un humain. Même en cas de mise en production manuelle, on n’a pas tendance à publier dix pages à la seconde près.
Les signaux d’un contenu généré automatiquement
Les pages générées automatiquement ont parfois un style “passe-partout”. Mais comme le SEO évolue, certains attaquants prennent des précautions et produisent des textes suffisamment “fluents” pour tromper. Ce qui reste généralement révélateur, ce sont les incohérences structurelles.
Voici des signaux fréquents que j’ai rencontrés sur des cas réels:
Titres et slugs trop systématiques, répétant des mots-clés sans lien avec l’architecture éditoriale. Liens externes ajoutés en masse, avec des ancres variées mais vers des domaines d’un même thème douteux. Meta et contenu “trop formatés”, par exemple des blocs identiques et des paragraphes qui changent peu d’une page à l’autre. Présence de shortcodes ou de blocs que vous ne déployez pas d’habitude, ou qui ne correspondent pas à votre page-builder. Des images “génériques” ou des images chargées depuis l’extérieur, parfois avec des URLs qui ne ressemblent pas à votre stockage.Cette liste n’est pas un diagnostic final, c’est une grille d’observation. Le but est de regrouper les pages suspectes pour ensuite vérifier, dans l’historique et les logs, si une même action d’écriture a été répétée.
Détecter la création “automatique” côté données, pas seulement côté interface
Une fois que vous avez repéré des pages, l’étape suivante consiste à remonter à “qui” et “comment”. Dans WordPress, deux axes sont particulièrement utiles: les fichiers modifiés et les événements dans la base.
Sur le plan “fichiers”, cherchez les modifications récentes dans:
- le thème actif et les thèmes enfants certains plugins, même ceux que vous pensez “inoffensifs” le dossier wp-content/uploads wp-config.php et les fichiers à la racine du site tous les fichiers dont les dates changent sans explication
Sur le plan “base de données”, les pages suspectes sont des enregistrements. Les champs à examiner, selon votre méthode d’accès, incluent l’auteur, le type de contenu, le statut, et la date de création. Si vous voyez un utilisateur nouvellement créé, avec peu ou pas d’activité normale, c’est un énorme drapeau rouge. Souvent, cet utilisateur a servi de relais, ou bien l’attaque a utilisé un compte existant pour écrire et publier.
Le point délicat: WordPress a des mécanismes de sauvegarde, d’import, d’auto-publi, et des plugins peuvent aussi créer des contenus. C’est pour ça qu’il faut garder une approche prudente. Par exemple, un import de flux peut créer des pages d’un type “posts” avec un auteur technique. Si l’import tourne à une heure fixe, vous devez le comparer avec vos heures suspectes. Sinon, vous allez désinfecter un “faux positif” et laisser la vraie porte ouverte.
Comprendre les scénarios d’attaques les plus courants
On ne peut pas toujours déterminer l’attaque exacte, mais on peut classer. Les pages créées automatiquement proviennent souvent de l’un de ces schémas.
Le premier scénario est l’attaque via un compte compromis. L’intrus se connecte en tant qu’utilisateur, puis crée ou modifie des contenus. Dans ce cas, les dates de création sont proches d’une connexion réussie, et les auteurs peuvent être cohérents avec l’utilisateur compromis. Le nettoyage doit alors inclure la rotation des mots de passe, la suppression des sessions actives, et le retrait des rôles indus.
Le second scénario est l’injection dans un plugin ou un thème. L’attaquant modifie un fichier pour ajouter une logique cachée, souvent déclenchée au chargement de certaines pages, ou par un cron-like interne. Il peut aussi écrire des pages de manière “batch” à intervalles réguliers.
Le troisième scénario ressemble à du spam SEO plus “ingénieux”: un mécanisme génère des pages à partir de modèles, en récupérant des variables depuis la requête (paramètres), ou en faisant appel à des services externes. Dans ce cas, vous pouvez observer des patterns répétitifs dans les slugs et des pages qui semblent “varier” dans des détails, mais gardent la même base.
Le quatrième scénario, plus rare mais réel, est la génération via une fonction système ou une tâche planifiée sur le serveur. Par exemple un cron ou une commande déclenchée par le serveur. Les pages apparaissent alors même si WordPress est “bien” de son point de vue applicatif, mais les fichiers écrits sur disque trahissent une compromission plus profonde.
La meilleure stratégie, quand on cherche la cause, consiste à relier quatre choses: les pages (leur date et leur auteur), les fichiers modifiés (leur date), les logs (leurs heures et urls), et les comptes utilisateurs (leur création et leurs activités). Quand ces éléments convergent, la cause devient beaucoup plus évidente.
Construire une chronologie simple, sans se noyer
Avant d’agir, je recommande presque toujours de faire une chronologie. Pas besoin d’un tableau complexe, juste une séquence claire dans votre tête (ou sur papier). Par exemple: “20 juin, 09:12 apparitions de 3 pages, 09:13 augmentation du trafic sur wp-admin, 09:20 modification d’un fichier dans wp-content/plugins”. Si vous constatez qu’un événement précède un autre, vous tenez un fil.
C’est là que les logs deviennent vos meilleurs alliés. Si vous n’avez pas accès aux logs, un autre levier est de comparer la date de dernière modification des fichiers, en particulier ceux liés à WordPress et à vos plugins. Les attaquants modifient rarement quelque chose sans laisser de trace de modification de fichier, même si ces traces peuvent être trompeuses (copie, écrasement, mise à jour).
Un détail pratique: les dates de modification sur le système peuvent être en décalage selon le fuseau horaire du serveur. WordPress stocke aussi des heures selon la configuration. Les écarts peuvent vous faire croire que “ça ne colle pas”. Prenez 10 minutes pour aligner les fuseaux avant d’en tirer une conclusion.
Méthodes concrètes pour repérer les mécanismes de génération
Il y a des approches “artisanales” et des approches plus outillées. L’important est de ne pas brûler des étapes.
https://gardewp.fr/nettoyage-malware-wordpress/Vous pouvez commencer par repérer des fichiers récemment modifiés qui contiennent des chaînes suspectes, comme des fonctions d’URL, de base64, de gzinflate, ou des mécanismes de lecture/écriture de fichiers. Mais prudence, il existe des libs et des fonctions légitimes qui peuvent contenir des chaînes similaires. La différence se fait souvent dans le contexte: assemblage de fragments de code, appel à des endpoints internes, conditions d’exécution bizarres.
Ensuite, cherchez les entrées suspectes dans la base de données qui peuvent correspondre à une logique d’automatisation, par exemple des options anormales, des champs de configuration, ou des codes dans les meta. Encore une fois, ne prenez pas une correspondance seule comme preuve. WordPress a des plugins qui stockent beaucoup d’options. Vous cherchez plutôt des valeurs “visiblement” hors norme, ou une structure associée à des pages produites.
Enfin, vérifiez le chargement côté front. Sur certaines attaques, le mécanisme déclenche de la génération au moment où une page précise est demandée, ou au premier affichage après un intervalle. Si vous savez quelles URLs déclenchent des nouvelles créations, vous pouvez tester dans un environnement contrôlé (idéalement après coupure temporaire de l’accès public) pour observer si la génération s’emballe.
Le point qui change tout: couper avant de désinfecter
Beaucoup d’administrateurs veulent supprimer les pages tout de suite. C’est compréhensible. Mais si le mécanisme d’attaque est toujours actif, supprimer et attendre seulement quelques minutes suffit parfois à voir le contenu réapparaître.
Je conseille souvent d’adopter une logique de frein. Le frein peut être aussi simple que:
- limiter temporairement l’accès aux zones sensibles (wp-admin) mettre le site en maintenance désactiver des plugins suspects un à un (avec prudence) bloquer le trafic entrant sur des routes ciblées si vous identifiez clairement la source
Le trade-off est réel: si vous coupez trop agressivement, vous perdez de la donnée de diagnostic. Si vous désactivez au mauvais moment, vous pouvez aussi empêcher l’attaque de montrer ses traces, ce qui complique l’enquête. C’est pour ça qu’il vaut mieux préparer une copie des fichiers et une copie de la base de données avant toute action lourde.
Désinfection WordPress : une approche par étapes, et une discipline de preuve
La désinfection WordPress ne devrait pas être une suite de “suppression au feeling”. On peut agir vite, mais on doit agir proprement, sinon on ne sait pas ce qui a été réparé.
Voici une séquence de travail que je trouve efficace dans la majorité des cas:
- Commencer par l’isolement: copier le site, figer l’état, puis couper l’exposition si nécessaire. Identifier le vecteur: fichier modifié, plugin altéré, compte créé, tâche planifiée, ou redirection. Supprimer les pages créées automatiquement, mais seulement après avoir stoppé le mécanisme de génération, sinon elles reviennent. Réparer: remettre les fichiers sains, reconfigurer les paramètres, supprimer les comptes suspects. Contrôler: vérifier la base, les fichiers, et les logs sur une période suffisante pour confirmer que la génération ne reprend pas.
Le dernier point est crucial. Un nettoyage “qui a l’air bon” peut durer 24 heures puis rechuter si le mécanisme est encore partiellement présent. Souvent, il y a un délai avant la prochaine vague.
Comment traiter les pages déjà créées, sans abîmer votre SEO
Supprimer des dizaines de pages générées automatiquement peut sembler immédiat. Mais il y a un coût. Si certaines pages ont été indexées, la suppression brute peut provoquer des erreurs 404 et un bruit de crawl.
Dans la pratique, vous pouvez choisir une approche progressive. Si les pages sont manifestement du spam et n’ont aucune valeur pour les visiteurs, passer par un statut cohérent est plus propre que de laisser des URLs fantômes. L’objectif est de gérer la transition sans laisser des redirections en boucle.
J’ai vu des sites se retrouver avec des chaînes de redirections parce que l’attaquant avait modifié des règles .htaccess ou les réglages de permaliens. Dans ces cas, supprimer des pages sans corriger les règles peut laisser le moteur de recherche recevoir un comportement instable. D’où l’importance de traiter d’abord les mécanismes, ensuite seulement l’arsenal de suppression.
Sécuriser après la désinfection, sinon c’est juste une reprise de souffle
Après la désinfection, il faut renforcer l’accès. Le problème n’est pas “le site était infecté une fois”, c’est “le site a permis qu’un script écrive des pages”.
Un nettoyage efficace inclut presque toujours une rotation des identifiants, une suppression de sessions, et un audit des rôles. Les attaquants reviennent souvent par réutilisation: si vous changez un mot de passe mais laissez un autre compte avec le même mot de passe que vous utilisez encore ailleurs, vous offrez un nouvel accès.
Autre angle souvent sous-estimé: l’environnement d’hébergement. Si des fichiers ont été modifiés, vérifiez les droits d’écriture, la configuration des sauvegardes, et l’absence d’outils non nécessaires. Un site WordPress peut être “propre” dans son code, mais vulnérable parce que le serveur accepte des écritures trop larges.
Et puis il y a la surveillance. Je ne parle pas de “tout monitorer en temps réel” si vous n’avez pas les moyens. Je parle d’avoir au moins une alerte quand un nouvel utilisateur apparaît, quand un plugin est activé, et quand des pages sont publiées par un utilisateur inattendu. Ça change la vie quand l’attaque est silencieuse.
Un mini-plan de contrôle, utile même si vous êtes pressé
Si vous voulez une check rapide orientée “détection des pages créées automatiquement”, sans partir en investigation profonde tout de suite, vous pouvez suivre ce court protocole:
- Repérer 5 à 10 pages suspectes, noter leur type (page ou article), leur auteur, et leur date exacte de création. Comparer ces dates avec les pics de trafic sur wp-admin et des scripts connus dans les logs. Vérifier les comptes utilisateurs créés autour des mêmes heures que les pages. Rechercher les fichiers récemment modifiés dans wp-content, thème et plugins, surtout ceux avec un contenu étrange. Mettre le site en maintenance ou restreindre wp-admin pour stopper temporairement les écritures, puis reprendre l’analyse.
Cette approche ne remplace pas une désinfection complète, mais elle vous évite de faire du nettoyage “à l’aveugle”.
Cas limites: quand ce n’est pas une attaque, mais que ça ressemble
Il existe des situations où des pages “apparaissent” sans que le site soit compromis. Un import, un outil de contenu, un plugin de migration, ou un flux RSS mal configuré peuvent créer des pages en masse. Le problème, c’est que ces mécanismes sont souvent planifiés et reproductibles. Ils laissent des patterns différents.
Si vous voyez des pages avec un auteur unique correspondant à votre compte d’édition, et si le contenu suit la logique attendue du plugin (par exemple article par article depuis un flux), vous êtes probablement face à un problème de configuration. À l’inverse, si les auteurs changent, si des comptes apparaissent, si des fichiers se modifient et si les heures ne collent pas à votre planning, l’hypothèse de la compromission devient beaucoup plus solide.
Un détail qui m’a déjà fait gagner du temps: les plugins légitimes ont souvent des journaux internes ou des paramètres d’activation. Les scripts malveillants, eux, laissent rarement un “récit” cohérent dans l’admin. Même si l’admin a l’air normale, les traces côté fichiers et base racontent une autre histoire.
Ce que j’attends quand je “détecte” vraiment
Détecter les pages créées automatiquement, ce n’est pas seulement confirmer qu’elles existent. C’est reconstruire le mécanisme et le périmètre.
Quand la désinfection WordPress est bien faite, on peut répondre à des questions précises, même si on ne connaît pas tous les détails techniques:
- Ces pages ont été publiées par un compte existant, ou par un compte créé après coup? Les pages partagent-elles un même template ou un même pattern de création? Quel est le moment déclencheur le plus probable? Un fichier précis a-t-il été modifié juste avant la première vague? Le site produit-il encore du contenu après arrêt temporaire de certains accès?
Si vous n’avez pas ces réponses, vous pouvez nettoyer et espérer. Mais vous jouez au loto. Et les attaques aiment bien les approches “au loto”.
Les pages automatiques sont souvent le premier symptôme visible. La vraie désinfection commence quand vous reliez ce symptôme à une cause. Prenez le temps de collecter des dates, des auteurs, des traces de modification, et des signaux dans les logs. Ensuite seulement, supprimez, réparez et sécurisez. C’est plus long, mais c’est aussi ce qui réduit le risque de voir revenir exactement le même problème, quelques jours plus tard.