Un compte administrateur inconnu est apparu sur votre WordPress : ce que ça signifie vraiment

Vous ouvrez la liste des utilisateurs de votre WordPress et vous tombez sur un administrateur que vous n'avez jamais créé. Nom générique, email inconnu, date d'inscription récente. Première question qui vient : « est-ce qu'un plugin a pu créer ça tout seul ? »

Réponse : non. Aucun plugin légitime ne crée de compte administrateur à votre insu. Un admin inconnu est la preuve d'une compromission, pas un dysfonctionnement. Et en juillet 2026, ce symptôme explose pour une raison précise : l'exploitation de masse de la faille WP2Shell.

D'où sort ce compte

Pour créer un administrateur, il faut soit exécuter du code sur votre serveur, soit exploiter une faille d'élévation de privilèges. Les voies d'entrée observées en ce moment :

• WP2Shell (CVE-2026-63030 + CVE-2026-60137) : la chaîne de failles du cœur WordPress patchée le 17 juillet 2026 et exploitée en masse dans les heures qui ont suivi. L'outillage public utilisé par les attaquants crée des comptes admin en série : les honeypots de watchTowr en ont enregistré plus de 100, créés par des acteurs différents utilisant des variantes des mêmes outils. Le contexte complet est dans notre article sur WP2Shell.
• Les CVE critiques de plugins : la vague de failles notées 9.8/10 du printemps 2026 (Everest Forms Pro avec CVE-2026-3300, Kirki, Breeze) permettait la même chose sur les sites non patchés.
• Un webshell déjà en place : si votre site a été backdooré plus tôt (par exemple par l'opération WP-SHELLSTORM et ses fichiers down.php), l'acheteur de l'accès crée son compte au moment de passer à l'action.
• Des identifiants volés : mot de passe réutilisé et fuité ailleurs, ou volé par un infostealer sur le poste d'un des admins légitimes.

Pourquoi supprimer le compte ne suffit pas

Le compte admin est la partie émergée de l'iceberg, et souvent volontairement : c'est la persistance la plus facile à repérer, celle qui peut « griller » sans conséquence pour l'attaquant. Ce qui l'accompagne presque toujours :

• Un webshell dans un répertoire d'upload ou de cache, qui fonctionne sans aucun compte WordPress.
• Un plugin ou mu-plugin malveillant, capable de recréer le compte à chaque suppression.
• Une tâche cron qui retélécharge la charge utile.
• Vos identifiants hachés dans la nature : l'exploitation de WP2Shell inclut l'exfiltration de la table des utilisateurs. Tant que les mots de passe et les salts n'ont pas été régénérés, l'attaquant peut revenir par la grande porte.

Supprimer le compte et s'arrêter là, c'est retirer le drapeau que l'attaquant a planté en laissant toutes ses clés en place. Si le compte réapparaît quelques jours après suppression, vous avez la démonstration en direct.

La procédure complète, dans l'ordre

L'ordre compte : réinitialiser les mots de passe avant d'avoir fermé les portes dérobées ne sert à rien.

1. Documentez : capture d'écran du compte (login, email, date d'inscription), export des logs d'accès de la période. Utile pour comprendre la voie d'entrée, et comme preuve.
2. Fermez la porte d'entrée : cœur WordPress en 6.9.5 / 7.0.2 minimum, tous les plugins et thèmes à jour. Un compte supprimé ne sert à rien si la faille qui a permis de le créer est toujours ouverte.
3. Inventoriez toutes les persistances avant de supprimer quoi que ce soit :

wp user list --fields=ID,user_login,user_email,user_registered,roles
find wp-content/uploads wp-content/cache -name "*.php"
find . -type f -name ".*.php"
wp plugin list && ls -la wp-content/mu-plugins/
wp cron event list

4. Supprimez tout en une seule session : le compte pirate, les webshells, les plugins malveillants, les tâches cron suspectes. Un nettoyage étalé sur plusieurs jours laisse à l'attaquant le temps de reconstruire.
5. Réinitialisez ensuite les secrets : mots de passe de tous les comptes WordPress, mots de passe d'application, accès FTP/SSH et base de données, puis régénération des salts (wp config shuffle-salts) pour invalider toutes les sessions et cookies.
6. Surveillez 30 jours : la réapparition d'un compte ou d'un fichier PHP signifie qu'une persistance a été manquée.

La checklist détaillée des vérifications post-compromission (logs de l'endpoint REST, fichiers antidatés, mu-plugins) est dans notre article sur le nettoyage après WP2Shell. Si vos visiteurs subissent déjà des redirections ou de fausses pages de connexion, commencez par l'article dédié à ces symptômes.

FAQ

Le compte a un nom crédible, presque comme un vrai utilisateur. C'est grave quand même ?

Oui, et c'est même un signe de sophistication : les attaquants choisissent des logins qui se fondent dans la masse (prénom, variante d'un admin existant, « support », « backup »). Le critère n'est pas le nom mais la traçabilité : tout compte admin que personne dans votre équipe ne revendique est hostile jusqu'à preuve du contraire.

Je ne vois pas de compte suspect mais mon site a été vulnérable à WP2Shell. Je suis tranquille ?

Non : le compte admin n'est qu'une persistance parmi d'autres, et certains attaquants s'en passent complètement au profit d'un webshell. Si votre site est resté en version vulnérable après le 17 juillet, faites les 6 vérifications de notre checklist post-WP2Shell.

Le compte revient après chaque suppression.

C'est la preuve qu'une persistance active le recrée : mu-plugin malveillant, tâche cron ou webshell. Cherchez le mécanisme de recréation avant de supprimer le compte une énième fois, sinon vous jouez à un jeu perdu d'avance.

Dois-je prévenir mes utilisateurs ?

Si votre site stocke des comptes clients et que la compromission a permis d'accéder à la base (c'est le cas avec WP2Shell), leurs données personnelles sont potentiellement concernées : le RGPD impose d'évaluer le risque et, le cas échéant, de notifier la CNIL sous 72 heures. Documentez ce que vous trouvez, cela servira à cette évaluation.

Sources primaires

• TechCrunch, « Hackers are exploiting recently patched WordPress bugs, putting millions of websites at risk ».
• Field Effect, « WordPress wp2shell attacks escalate following public PoC release ».
• Cybersecurity News, « Hackers Actively Exploiting WordPress Plugin Vulnerability to Inject Malicious PHP Code ».