Utiliser WP-CLI pour nettoyer un site WordPress infecté (guide pratique)

Quand un site WordPress “tombe malade”, on a rarement envie d’attendre. Le trafic chute, des pages deviennent bizarres, parfois des redirections se mettent à tourner, et souvent le service support reçoit les mêmes messages: “On voit du contenu louche”, “Google n’aime plus votre site”, “il y a des liens vers des sites inconnus”.

Dans ce genre de situation, WP-CLI peut devenir votre outil le plus rapide, à condition de l’utiliser avec méthode. L’objectif n’est pas juste de supprimer un dossier ou de “désinfecter au hasard”, mais de retrouver un état fiable: fichiers cohérents, base nettoyée, plugins et thèmes sains, droits corrects, et une piste claire sur ce qui a causé l’infection.

Ce guide pratique explique comment procéder avec WP-CLI, quoi vérifier avant de modifier quoi que ce soit, et comment éviter les pièges classiques. Je parle volontairement d’actions concrètes, parce que sur un incident réel, les détails comptent autant que la stratégie.

Le bon réflexe: distinguer infection, compromission et “symptômes”

Avant de lancer des commandes, prenez deux minutes pour qualifier ce que vous observez.

Une infection au sens large, sur WordPress, se manifeste souvent par:

du contenu injecté (PHP dans des fichiers de thèmes, scripts malveillants dans des pages, liens cachés), des utilisateurs créés ou des rôles élevés sans raison, des modifications dans la base de données (options, postes, métadonnées, meta d’admin), des comportements réseau comme des redirections.

Mais parfois, ce que vous appelez “infection” est en réalité une compromission par mot de passe, une configuration exposée (ancien plugin non mis à jour), ou une erreur humaine (fichier ajouté pour du tracking qui finit par injecter autre chose).

WP-CLI ne remplace pas l’analyse, il accélère l’assainissement. Si vous travaillez sans hypothèse minimale, vous risquez de nettoyer la surface pendant que la source reste en place.

Préparer l’intervention: accès, sauvegarde, fenêtre de restauration

Avant toute commande WP-CLI, vérifiez que vous avez une voie sûre pour revenir en arrière. Sur un site infecté, un mauvais ordre d’opérations peut empirer la situation.

Concrètement, assurez-vous d’avoir:

une sauvegarde récente des fichiers et de la base (même si vous la refaites ensuite), un accès SSH ou au moins un accès exécutable à WP-CLI, un moyen d’isoler le site (désactivation temporaire, page de maintenance, restriction d’accès) si nécessaire.

Si vous n’avez pas de sauvegarde propre, l’option la plus prudente reste de faire une copie maintenant, avant de toucher à quoi que ce soit. Oui, ça rallonge, mais dans un incident, perdre une heure à cause d’une mauvaise manip coûte souvent plus cher que le temps gagné.

Installer et vérifier WP-CLI

Sur un serveur déjà configuré, WP-CLI est souvent disponible. Sinon, vous pouvez l’installer localement ou via un script d’amorçage côté serveur. Le détail dépend de votre hébergement, je ne vais pas inventer de procédure universelle, mais gardez l’idée suivante: WP-CLI doit fonctionner de manière fiable, sinon vous nettoierez “en aveugle”.

Un test rapide consiste à obtenir des informations sans changer le système:

Wp --info Wp core version

Si ces commandes échouent, ne lancez pas de nettoyage. Réglez d’abord la configuration, sinon vous pourriez vous connecter à la mauvaise base, au mauvais répertoire, ou à un environnement partiellement configuré.

Se placer au bon endroit: repérer la racine WordPress et la bonne instance

WP-CLI doit pointer vers le dossier WordPress. Si vous avez plusieurs installations (ou un WordPress dans un sous-répertoire), une erreur ici est classique.

Une vérification simple:

Wp site list --format=ids

Cette commande dépend du contexte (multisite ou non). Si vous n’êtes pas en multisite, vous n’avez rien à lister.

À défaut, restez prudent et utilisez:

Pwd Ls

Puis lancez:

Wp option get home --skip-plugins --skip-themes

L’important est moins la commande exacte que la validation: vous devez être sûr de viser la bonne instance.

Comprendre le rôle de “skip-plugins” et “skip-themes”

Quand un site est infecté, c’est parfois parce que des plugins ou des thèmes sont devenus des vecteurs. Or WP-CLI, par défaut, charge WordPress et donc peut charger des fichiers qui exécutent du code malveillant.

C’est là que ces options deviennent précieuses. Beaucoup d’actions d’assainissement peuvent se faire en limitant le chargement de code applicatif.

Essayez d’utiliser --skip-plugins et --skip-themes quand votre opération ne dépend pas de ces composants. Une règle simple que j’applique souvent: si je veux inspecter ou supprimer des données, je cherche d’abord à limiter les exécutions inutiles.

Étape 1: vérifier l’état et repérer les anomalies via WP-CLI

Une infection se laisse parfois deviner par des incohérences: utilisateurs inattendus, thèmes ou plugins “hors norme”, révisions anormalement nombreuses, options modifiées.

Commencez par une vue d’ensemble, sans corriger. L’objectif est de collecter des indices que vous pourrez exploiter ensuite.

Utilisateurs: nouveaux comptes, rôles élevés, “admin” inattendus

Les comptes créés récemment sont une piste fréquente. Avec WP-CLI, vous pouvez lister les utilisateurs et filtrer selon ce que WordPress a en base.

Par exemple, inspectez les rôles et passez https://gardewp.fr/ en revue les comptes qui n’ont pas de raison d’exister. Si vous avez une politique de gestion des utilisateurs, comparez avec votre liste interne.

Vous pouvez aussi chercher les emails, les noms d’utilisateur suspects, ou les comptes créés autour de la date de l’incident.

Plugins et thèmes: versions, chemins, état

Regardez quels plugins et thèmes sont actifs. Sur beaucoup d’incidents, on retrouve:

un plugin récemment ajouté, un thème modifié, ou un plugin inactif qui a pourtant introduit du code via un hook.

WP-CLI permet de lister proprement sans dépendre d’une interface web.

Options: modifications ciblées

Certaines infections modifient des options spécifiques (par exemple des réglages de redirection, des fragments injectés, des paramètres de cache ou de traduction). Le piège est de supposer. À la place, cherchez d’abord les options “anormalement” modifiées et comparez avec un état attendu.

Si vous avez un export ou une référence sur un site sain, c’est encore mieux. Sinon, vous pouvez encore avancer de façon rationnelle en inspectant les options qui contiennent du HTML ou des chaînes inhabituelles.

Étape 2: sécuriser et limiter le risque pendant la désinfection

Quand je nettoie un site infecté, je pense “réduction de surface”. Si votre site est toujours exposé, l’infection peut continuer à s’exécuter, créer d’autres comptes, réinjecter du contenu, ou écrire des fichiers.

Deux leviers courants existent avant d’entamer un nettoyage plus agressif:

mettre le site en pause ou restreindre l’accès (au moins pendant la fenêtre d’assainissement), désactiver temporairement les plugins et thèmes potentiellement compromis.

Avec WP-CLI, la désactivation se fait de façon scriptable. Le trade-off est important: désactiver trop ne permet plus d’exécuter certaines tâches utiles, mais garder tout actif augmente le risque d’exécution pendant les commandes.

Si vous avez des indices forts (un plugin a été ajouté juste avant l’incident, ou un thème contient du code modifié), désactivez d’abord ces composants, puis inspectez et nettoyez.

Étape 3: assainir la base WordPress avec des suppressions maîtrisées

Le contenu malveillant dans WordPress peut se trouver dans plusieurs endroits: publications, pages, options, métadonnées, tables de cache internes, ou même dans des révisions.

Le point clé, c’est de ne pas effacer aveuglément tout ce qui semble “bizarre”. D’un côté, garder des traces peut laisser la porte ouverte. De l’autre, supprimer trop agressivement peut casser votre site légitime, ou perdre des contenus utiles.

Voici comment je procède en pratique: je cible ce qui est très probablement malveillant, en gardant un filet de sécurité.

Identifier les éléments suspects

Avant de supprimer, cherchez les éléments qui trahissent une injection. Sur WordPress, l’injection se voit souvent par:

des pages ou publications contenant des patterns (liens externes, scripts inline, iframes inattendues), des contenus créés massivement sur une période courte, des shortcodes inconnus ou des bundles de HTML répétitifs.

WP-CLI vous permet d’inspecter des contenus rapidement. Par exemple, recherchez dans les titres et contenus des indices. Le niveau de précision dépend des données présentes.

Supprimer le contenu malveillant sans détruire le reste

Quand vous avez identifié des publications ou pages à effacer, WP-CLI peut supprimer via des commandes de type suppression de post.

Attention à un piège courant: la suppression ne retire pas forcément l’entièreté des artefacts liés, comme des meta. Souvent, WordPress nettoie au moment de la suppression, mais pas toujours ce que vous attendez selon les structures et les tables concernées. Pour éviter les mauvaises surprises, je préfère:

supprimer les items identifiés, puis vérifier le nombre d’éléments restants, puis nettoyer les caches si nécessaire.

Étape 4: neutraliser les vecteurs dans les fichiers (sans tomber dans le “tout effacer”)

Beaucoup d’infections ne vivent pas seulement dans la base. Un fichier modifié dans un thème ou un plugin peut contenir un mécanisme d’injection, un code de redirection, ou une logique qui se relance via des hooks.

WP-CLI est utile, mais il n’est pas un antivirus. Pour les fichiers, je recommande une démarche en deux temps:

Repérer les fichiers suspects, Corriger par comparaison et restauration, pas juste par suppression.

Si votre hébergement a un historique de déploiement, comparez avec le dernier état sain. Si vous n’avez pas d’historique, reconstruire un thème ou un plugin à partir de sa source officielle (ou via le dépôt interne) est souvent plus fiable que “retoucher à la main”.

Et oui, parfois la meilleure stratégie est de remplacer les thèmes et plugins par des versions propres, puis de réactiver un à un, en observant.

Étape 5: réinitialiser thèmes et plugins, puis restaurer la confiance

Sur un incident réel, je rencontre souvent un scénario: un ou deux plugins ajoutent du contenu, mais on ne sait pas lesquels parce que plusieurs modifications ont eu lieu. Dans ce cas, la méthode “remplacement propre” est celle qui réduit le plus l’incertitude.

WP-CLI permet d’installer, d’activer, de désactiver, et de mettre à jour. Mais le risque, c’est de mettre à jour en laissant un code malveillant actif. D’où l’importance de l’ordre.

Je raisonne comme ceci:

désactiver en premier les composants potentiellement compromis, remettre en état ceux qui sont connus (thèmes et plugins tiers), réactiver petit à petit, surveiller.

Une checklist simple à appliquer avant la première réactivation

Avant de réactiver quoi que ce soit, je fais une vérification rapide, dans un ordre similaire à celui-ci:

confirmer que le site n’exécute pas de code suspect via --skip-plugins et --skip-themes quand c’est possible vérifier la liste actuelle des plugins et thèmes actifs vérifier les comptes utilisateurs qui ont été ajoutés récemment supprimer ou mettre en quarantaine les contenus clairement injectés

Cette étape prend dix minutes et évite des retours en incident.

Deux commandes WP-CLI qui aident vraiment, mais pas comme on croit

Beaucoup de gens découvrent WP-CLI et pensent qu’il va “résoudre l’infection”. En pratique, WP-CLI est excellent pour manipuler WordPress, pas pour investiguer des binaires système ou pour nettoyer des backdoors dans le système de fichiers sans intervention en dehors de WP-CLI.

Cela dit, deux familles de commandes rendent service.

D’abord, les commandes d’état WordPress. Ensuite, les commandes de gestion des utilisateurs, des options et des contenus. Cela dit, j’insiste: utilisez des options de limitation de chargement quand vous suspectez un vecteur dans le code PHP.

Exemple de séquence réaliste pour un assainissement guidé par WP-CLI

Je vous propose une séquence logique qui se déroule souvent bien sur les incidents “classiques” (contenu injecté, comptes ajoutés, plugins modifiés), en supposant que vous avez déjà une idée de ce qui a changé.

1) Mettre à l’arrêt la partie exposée si possible, ou passer le site en maintenance.

2) Désactiver ce qui est suspect pour réduire l’exécution pendant le nettoyage.

3) Inspecter rapidement les utilisateurs et les éléments de contenu.

4) Supprimer ce qui est clairement identifié comme injecté.

5) Réinstaller ou remplacer les thèmes/plugins compromis.

6) Remettre en service, puis surveiller.

Dans la pratique, la partie “inspecter” et “identifier” est la plus importante. Supprimer sans preuve produit parfois un site cassé, et vous perdez la capacité à distinguer ce qui était légitime de ce qui était malveillant.

Quelques commandes typiques (à adapter à votre contexte)

Selon votre configuration, les commandes exactes changent. Voici un petit lot utile, à utiliser comme point de départ:

Wp plugin list Wp theme list Wp user list --role=administrator Wp option list --autoload=1 Wp db size

Elles vous donnent une base rationnelle: actifs, admin présents, options chargées automatiquement, et taille de base pour détecter des volumes anormaux (parfois, l’injection gonfle rapidement).

Nettoyer après suppression: révisions, caches et cohérence

Une fois la suppression et la neutralisation faites, vous pensez parfois que “c’est bon”. Sur WordPress, il reste des résidus:

révisions d’articles, caches persistants si un plugin de cache tourne, transients et données temporaires, variations de contenu déjà rendues dans des systèmes externes.

WP-CLI permet souvent de nettoyer les transients et parfois de forcer un purge selon votre architecture. Mais là aussi, je préfère éviter la suppression totale indiscriminée. Si un plugin de cache gère ses données dans des tables ou fichiers spécifiques, il peut y avoir des conventions.

Le bon réflexe est de suivre le symptôme: si le site renvoie encore des liens injectés, cherchez d’abord où se trouve la source (fichier, hook, base). Si les pages sont correctes mais que la navigation affiche encore l’ancien contenu, c’est peut-être un cache.

Le point qui fait gagner du temps: comparer avec un “état connu sain”

Si vous avez déjà:

une archive des fichiers du dernier déploiement, un export base avant incident, un inventaire de plugins et thèmes en place,

Vous gagnez beaucoup. Les infections laissent des différences. Même quand vous n’avez pas de “preuve”, vous pouvez réduire l’espace de recherche en identifiant:

ce qui a été ajouté entre deux dates, ce qui a été modifié, ce qui n’existait pas avant.

WP-CLI ne fait pas la comparaison de fichiers pour vous, mais il vous aide à confirmer côté WordPress: liste des thèmes, plugins, utilisateurs, types de contenus, options.

Vérifier la persistance: s’assurer que ça ne revient pas

Un incident propre n’est pas seulement “nettoyé”, c’est “stabilisé”. Le risque principal n’est pas la première injection, c’est la persistance:

un plugin malveillant qui réécrit la base, un fichier dans le système qui télécharge de nouveau code, un accès distant qui reste actif.

Après la première passe de nettoyage, je recommande de tester:

chargement d’une page critique et inspection HTML, tentative de création de contenu et observation, vérification rapide des comptes et plugins après quelques minutes.

Si le site rechute rapidement, vous n’êtes pas au bout. Et si vous avez des journaux serveur, recherchez des connexions suspectes, des requêtes anormales, des tentatives répétées. Sans journaux, vous travaillez “au doigt mouillé”.

Pièges fréquents quand on utilise WP-CLI

Voici les erreurs que je vois le plus, parce qu’elles arrivent même chez des gens compétents sous pression.

D’abord, lancer des commandes sans s’assurer que WP-CLI vise la bonne installation. Cela semble trivial, mais sur des serveurs avec plusieurs répertoires, c’est une cause classique d’erreur.

Ensuite, supprimer des données sans analyser la source. Si un fichier injecteur reste présent, vous gagnerez une heure, puis vous perdrez une journée.

Autre piège: réactiver un plugin juste “parce qu’il était là avant”. Si c’était précisément le vecteur, vous relancez l’infection. La restauration doit être “propre”, et idéalement vous devez valider chaque élément réactivé.

Enfin, ignorer l’après. Si les mots de passe compromis restent en place, l’incident reviendra. Et si vous n’avez pas corrigé la faille d’origine (plugin vulnérable, permissions trop larges, accès FTP exposé), vous êtes en train de faire un pansement.

Après le nettoyage: durcissement et prévention (sans transformer le site en bunker)

Une fois le site stabilisé, l’étape “prévention” est celle qui empêche la récidive. Elle ne doit pas être spectaculaire, elle doit être durable.

Je recommande de:

changer tous les mots de passe des comptes administrateurs, y compris ceux utilisés par vos équipes ou intégrations, vérifier le modèle d’accès au serveur (clés SSH, limitation des IP, désactivation des méthodes inutiles), mettre à jour core WordPress, thèmes et plugins de manière contrôlée, supprimer les plugins inutiles, revoir les permissions de fichiers et la configuration d’écriture dans les répertoires sensibles, et éventuellement activer une supervision simple (alertes sur création d’utilisateurs, sur modifications de fichiers, ou sur pics de requêtes).

WP-CLI peut servir ici aussi, pour l’inventaire et la mise à jour, mais la prévention est autant une question d’hygiène système que de WordPress.

Conclusion pratique: quand WP-CLI est le bon outil, et quand il ne suffit pas

WP-CLI est particulièrement efficace pour nettoyer un site WordPress infecté, parce qu’il permet de manipuler l’état WordPress vite et de manière scriptable. Il brille dans l’inventaire (plugins, thèmes, utilisateurs), dans l’assainissement de la base, et dans le contrôle du chargement via des options comme --skip-plugins et --skip-themes.

Mais il ne remplace pas une analyse fichier et une restauration propre quand l’infection est dans le code. L’approche la plus robuste reste l’enchaînement: sécuriser, inspecter, neutraliser, nettoyer, restaurer, puis vérifier la persistance.

Si vous faites une seule chose avant https://gardewp.fr/nettoyage-malware-wordpress/ de commencer, faites ceci: assurez-vous d’avoir une sauvegarde, et travaillez par étapes avec un “retour possible”. En incident, la vitesse compte, mais la capacité à revenir en arrière vous rend beaucoup plus rapide sur le long terme.

Si vous voulez, décrivez votre cas (symptômes, types de fichiers modifiés ou erreurs observées, présence de nouveaux comptes, et si vous êtes en multisite). Je peux alors proposer une séquence WP-CLI plus ciblée, adaptée à ce que vous avez sous les yeux.