Faille de plugin WordPress : mettre à jour, nettoyer ou restaurer

Cet article s’adresse aux agences et aux responsables de sites WordPress qui viennent d’appliquer une mise à jour de sécurité après une faille de plugin WordPress, et qui se demandent si le travail est terminé. La mise à jour empêche une nouvelle exploitation par cette faille, mais elle ne retire rien de ce qu’une attaque réussie a pu installer avant. Vous verrez comment choisir entre trois réponses (la mise à jour seule, un nettoyage ciblé ou une restauration depuis une sauvegarde) et quelles vérifications permettent de trancher. L’exemple suivi est une campagne documentée en octobre 2026, qui installe un administrateur invisible dans wp-admin.

Ce que corrige une mise à jour de plugin WordPress, et ce qu’elle laisse en place

Une mise à jour remplace les fichiers du plugin vulnérable. Le code corrigé bloque donc une nouvelle injection par ce chemin. En revanche, elle ne touche ni aux comptes utilisateurs créés entre-temps, ni aux fichiers déposés dans d’autres dossiers, ni aux réglages écrits en base de données. Si l’attaque a réussi avant la mise à jour, ces éléments restent en place, et l’écran d’administration n’en montre pas forcément la trace.

La décision dépend donc de deux faits : l’attaque a-t-elle réussi sur votre site avant la mise à jour, et les accès qu’elle a installés ont-ils servi ? Pour y répondre, il faut savoir ce que l’attaque installe, puis le chercher.

L’exemple d’octobre 2026 : un administrateur caché après une faille XSS

Le 6 octobre 2026, Patchstack a documenté une campagne active qui exploite deux failles XSS stockées, c’est-à-dire du script enregistré dans une donnée puis exécuté quand quelqu’un l’affiche. La première touche WPC Product Bundles for WooCommerce jusqu’à la version 8.6.6 (corrigée en 8.6.7), exploitée dès le 4 octobre. La seconde touche Ninja Forms jusqu’à la 3.15.3 (corrigée en 3.15.4), exploitée le lendemain. L’injection ne demande aucun compte : un formulaire public ou une commande suffit, et la donnée attend en base qu’un administrateur l’ouvre dans wp-admin.

À ce moment, le script s’exécute dans la session de l’administrateur. Sans voler le cookie, il envoie ses requêtes depuis le site lui-même, avec la session ouverte, et rejoue les actions normales de WordPress. D’après l’analyse de Patchstack, il :

1. installe un faux plugin, « WP Smart Thumbnails » 1.2.4, qui contient un gestionnaire de fichiers accessible sans authentification ;
2. crée un administrateur visible ;
3. crée un second administrateur au nom anodin (support, updater, backup…), avec une adresse en @wordpress.org, puis le masque grâce à un must-use plugin déposé dans wp-content/mu-plugins/ ;
4. installe une URL de connexion secrète, /wp-login.php?_wplogin= suivie d’un jeton, qui ouvre une session au nom du plus ancien administrateur du site.

Le compte masqué n’apparaît ni dans « Tous les utilisateurs », ni dans le filtre Administrateur, ni dans les totaux. Les must-use plugins sont chargés à chaque requête et n’apparaissent pas dans l’écran Extensions ; supprimer le faux plugin ne les retire donc pas. Le script antidate aussi ses fichiers à la date du plus vieux fichier de l’installation, si bien qu’un tri par date ne les fait pas remonter.

Le critère décisif : savoir si la faille a servi sur votre site

Un administrateur inconnu peut avoir une explication banale : accès d’un ancien prestataire, compte de support de l’hébergeur, compte technique d’un plugin de sauvegarde. Les vérifications suivantes portent sur la base, les fichiers et les journaux, puisque l’interface est justement filtrée.

Les traces laissées par l’attaque :

• Administrateurs en base. Lister les administrateurs en SQL, en joignant wp_users et wp_usermeta sur la clé wp_capabilities contenant administrator (adapter le préfixe), puis comparer avec wp-admin. Un compte présent en base et absent de l’écran signale une compromission, car un compte légitime oublié reste visible. La colonne user_registered donne la date de création de chaque compte. WP-CLI charge les must-use plugins et peut subir le même filtre ; la requête SQL directe y échappe.
• Must-use plugins. Lister wp-content/mu-plugins/ et chercher class-wp-token-validate.php ou class-wp-query- suivi de huit caractères hexadécimaux. Les fichiers se jugent sur leur contenu, pas sur leur date.
• Options et faux plugin. Chercher les options fz_emer_login_tokens et fz_emer_done_v1 dans wp_options : si la première existe, au moins un jeton de connexion secrète est valide. Chercher aussi le dossier wp-smart-thumbnails, et le domaine imgcdn1.com dans les journaux.

Les signes que ces accès ont servi :

• URL secrète utilisée. Des requêtes vers wp-login.php avec le paramètre _wplogin dans les journaux du serveur web.
• Comptes créés utilisés. Des connexions du compte caché ou du compte visible créé par l’attaque. Cette vérification suppose un journal qui enregistre les connexions par compte. Sans lui, on ne peut pas prouver que ces comptes n’ont pas servi, et la décision penche alors vers la restauration.
• Gestionnaire de fichiers appelé. Des requêtes directes vers wp-smart-thumbnails.php, en dehors des écrans d’administration.

Le résultat de ces vérifications oriente vers l’une des trois réponses ci-dessous.

Quand la mise à jour suffit

Si aucune trace n’est trouvée, le site a probablement été exposé sans être compromis. La mise à jour est alors la bonne réponse, à compléter par deux gestes : supprimer les soumissions ou commandes qui contiennent du script injecté, et noter la date de la vérification.

Quand il faut nettoyer le site

Le nettoyage ciblé convient quand les traces sont présentes (comptes, must-use plugins, options) mais qu’aucun signe ne montre qu’elles ont servi : aucune requête _wplogin dans les journaux, aucune connexion du compte caché ni du compte visible créé par l’attaque, aucun appel au gestionnaire de fichiers. L’attaquant a alors installé ses accès sans les utiliser.

On conserve d’abord une copie des fichiers et de la base dans l’état trouvé. On supprime ensuite les deux comptes illégitimes, le dossier du faux plugin, les deux must-use plugins et les options fz_emer_*. L’ordre compte : supprimer l’option sans retirer les must-use plugins laisse la possibilité d’émettre un nouveau jeton. On change ensuite les mots de passe de tous les administrateurs, à commencer par le plus ancien, puisque l’URL secrète ouvre une session à son nom. On régénère les clés de salage de wp-config.php pour couper les sessions ouvertes. Enfin, on supprime les données piégées et on compare le cœur et les plugins à leurs sommes de contrôle (wp core verify-checksums, wp plugin verify-checksums --all). Ces commandes ne couvrent ni mu-plugins ni les thèmes, qui se relisent à la main.

Quand il vaut mieux restaurer une sauvegarde

Dès que l’un des trois accès a servi, l’attaquant a eu une session administrateur ou un accès direct aux fichiers. Une session administrateur, ouverte par l’URL secrète ou par un compte créé, donne accès à tout wp-admin : installer un plugin, modifier un thème, déposer du code, sans passer par le gestionnaire de fichiers. Avec le gestionnaire de fichiers, il a pu écrire n’importe quel fichier dans un dossier inscriptible. Dans les deux cas, on ne sait plus quoi chercher : un nettoyage ciblé ne garantit plus rien.

La restauration depuis une sauvegarde antérieure à la compromission devient alors l’option la plus sûre. La date de création du premier compte illégitime (user_registered) et la première requête suspecte dans les journaux aident à choisir la bonne sauvegarde. Elle a un coût : les commandes, soumissions et contenus créés depuis doivent être repris à la main. Les mots de passe et les clés de salage se changent quand même, en commençant par le plus ancien administrateur, et les plugins vulnérables se mettent à jour avant la remise en ligne.

Pour l’entreprise, une conséquence passe facilement inaperçue : l’URL secrète se connecte au nom du propriétaire d’origine, donc un journal qui n’enregistre que l’identifiant utilisateur attribuera les actions de l’attaquant à quelqu’un de l’équipe. On retrouve le même écart entre l’écran et les accès réels avec un login temporaire expiré dont l’accès REST restait admin.

Les indicateurs cités ici ne sont pas exhaustifs. Le second étage du script ne dépend pas du plugin : une autre faille XSS stockée peut servir d’entrée, et les noms de fichiers peuvent changer. En cas de doute entre nettoyage et restauration, la restauration est le choix prudent.

Réduire le risque avant la prochaine faille

Le premier levier est le délai de mise à jour : selon Patchstack, les deux failles étaient publiques depuis le 22 septembre, soit une douzaine de jours avant les premières attaques. Le deuxième est la constante DISALLOW_FILE_MODS dans wp-config.php, qui interdit l’installation de plugins depuis l’admin et bloque donc la première étape de cette campagne ; en contrepartie, les mises à jour passent par un déploiement ou par WP-CLI. Le troisième est un contrôle planifié qui compare les administrateurs en base à une liste attendue et signale tout nouveau fichier dans mu-plugins. Limiter le nombre d’administrateurs qui lisent au quotidien des données saisies par des visiteurs réduit aussi les droits dont un script hériterait.

Ce qu’il faut retenir

• Une mise à jour de plugin bloque la faille, mais ne retire ni les comptes, ni les fichiers, ni les réglages installés avant.
• Pour décider, vérifiez la base, mu-plugins, les options et les journaux, pas l’écran Utilisateurs.
• Aucune trace : la mise à jour suffit. Traces présentes mais aucun signe d’utilisation : nettoyage ciblé et changement de tous les accès. URL secrète, compte créé ou gestionnaire de fichiers utilisé, ou connexions impossibles à vérifier : restauration.
• DISALLOW_FILE_MODS et un contrôle planifié des administrateurs limitent la prochaine attaque de ce type.

Si vous avez mis à jour un plugin vulnérable sans vérifier ce qui avait pu s’installer avant, ou si personne ne fait ce contrôle sur vos sites WordPress, c’est le travail décrit sur la page maintenance.