wp2shell : des comptes w2s_ et wp2_ dans votre WordPress, et pourquoi ils reviennent

wp2shell n'est pas un pirate, c'est un outil. Il passe d'un site à l'autre, tente d'entrer, et laisse derrière lui des comptes et des portes que d'autres groupes viennent ensuite utiliser. Sur les sites que j'ai traités cet été, j'ai compté jusqu'à cinq groupes différents passés sur le même site après la première entrée.

Vérifier en 2 minutes

• La version. Dans « Tableau de bord », puis « Mises à jour ». Les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 sont vulnérables. La correction est sortie en 7.0.2, le 17 juillet 2026, sous forme de mise à jour forcée. Si votre site était encore dans ces versions après cette date, il faut savoir pourquoi.
• Les administrateurs. Dans « Comptes », filtrez sur « Administrateur ». Méfiez-vous des noms en mot_ suivis de lettres et de chiffres sans sens, des adresses qui finissent en « .invalid », « .local » ou « .test », des adresses qui imitent la vôtre et des dates d'inscription anciennes. Elles peuvent être fausses. J'ai vu 24, 61 et jusqu'à 120 administrateurs sur un seul site.
• Les extensions et les thèmes. Un nom suivi d'une suite aléatoire de lettres et de chiffres, ou une extension au nom rassurant comme « System Health » ou « Security Patch » que vous n'avez pas installée. Certaines se retirent elles-mêmes de la liste des extensions : une liste propre ne prouve rien.
• Les articles. Cherchez « hacked by » dans les articles et les pages. Ces messages sont publiés directement dans la base.

Ce que ça fait

La porte d'entrée est une fonction de WordPress qui permet d'envoyer plusieurs demandes en une seule. Elle sert à l'éditeur de blocs pour enregistrer plusieurs éléments d'un coup. Une faille dans cette fonction, référencée CVE-2026-63030, permettait d'interroger la base de données sans être connecté, puis d'exécuter du code sur le serveur.

La même fonction sert aussi à deviner les mots de passe. Les extensions de sécurité limitent le nombre de requêtes envoyées au site. Une requête qui contient cent tentatives ne compte que pour une. Le compteur ne voit presque rien. Sur quatre sites, j'ai relevé 5 248 requêtes de ce type en deux semaines : 2 239 ont été traitées par le site, 231 seulement ont été bloquées. Le jour où j'ai fermé cette porte, six semaines après la première intrusion, elle recevait encore 399 requêtes.

Une fois dedans, l'outil crée un administrateur. Le journal de sécurité du site attribue alors cette création au premier compte du site, souvent celui du propriétaire ou de son prestataire. Ce n'est pas un vol de mot de passe. C'est un contournement de l'identification, et le journal se trompe de coupable. J'ai vu la force brute continuer à échouer sur le compte du propriétaire après la création du compte pirate : qui a le mot de passe cesse de le chercher.

Ensuite viennent les dépôts : de fausses extensions, des gestionnaires de fichiers, une ligne ajoutée dans une quinzaine de fichiers du cœur de WordPress, des pages de spam montrées aux seuls robots, et des articles « hacked by » publiés comme n'importe quel article. Sur un site, deux de ces articles sont restés en ligne et indexables pendant treize jours.

Pourquoi le nettoyage habituel échoue

• Les mots de passe ne ferment rien. L'attaquant ne les connaît pas et n'en a pas besoin. Ce qui ferme ses sessions, c'est le renouvellement des clés secrètes du fichier de configuration. Si ces clés étaient restées à leur valeur d'exemple, WordPress les a rangées dans la base, où la faille permettait de les lire et de fabriquer des sessions d'administrateur.
• Le défacement vit en base. Un article publié ne laisse aucun fichier. Le nettoyage de fichiers le plus minutieux passe à côté. Sur un des cas, c'est le cache des pages qui en gardait la trace et m'a mis sur la piste.
• Les portes ressemblent au cœur. Un gestionnaire de fichiers sans mot de passe, rangé dans un dossier de bibliothèque du cœur, répondait normalement. Ailleurs, le code était caché dans des fichiers de style et des images du cœur. Seule la comparaison de chaque fichier avec les empreintes officielles de la version les fait sortir.
• Les dates mentent. Les fichiers déposés sont mis en lecture seule et leurs dates sont reculées. Un chargeur se cachait dans un fichier de traduction pour une langue qui n'existe pas. Un contrôle qui ne regarde que les fichiers récents ne trouve rien.
• La mise à jour forcée n'arrive pas toujours. Un dossier de gestion de versions à la racine du site suffit à bloquer toutes les mises à jour automatiques. Sur un autre site, WordPress était resté figé depuis des mois malgré des mises à jour automatiques activées.
• La porte reste ouverte. Sur un parc nettoyé le 16 août, une seconde vague a déposé de nouveaux fichiers dès le 18. Tant que la faille est accessible, le nettoyage ne fait que libérer de la place.

La base garde aussi des traces techniques de l'exploitation : des centaines d'entrées de brouillons de personnalisation, de cache d'intégration et d'éléments de menu orphelins, à des identifiants qui se suivent, au-dessus du dernier contenu légitime. Leur présence sur un site qui tournait dans une version vulnérable est un signe fiable de passage.

Que faire

• Mettre à jour tout de suite, puis vérifier dans « Santé du site » que les mises à jour automatiques fonctionnent vraiment.
• Exporter la liste des comptes, pour garder la preuve, puis supprimer les administrateurs inconnus et réattribuer leurs contenus.
• Renouveler les clés secrètes, ce qui ferme toutes les sessions ouvertes, et retirer de la base celles qui y ont été rangées.
• Comparer le cœur aux empreintes officielles, puis lire les thèmes, les extensions, les dossiers de traductions et les fichiers de configuration.
• Fouiller la base : articles et pages « hacked by », entrées techniques en série, comptes à fausse date d'inscription.
• Reprendre la Search Console : sur plusieurs de ces sites, un compte inconnu s'était ajouté comme propriétaire.
• Donner une adresse lue à l'extension de sécurité. Sur un des sites, elle avait tout vu pendant deux mois et n'avait prévenu personne.

Sur un site vitrine, je ferme aussi la fonction d'envoi groupé, qui ne lui sert à rien. C'est une ligne de plus, et c'est ce que l'attaquant tentera de rouvrir en premier s'il revient. Si l'hébergeur a déjà coupé le site, commencez par la page sur les sites suspendus. Si Google l'a signalé, voyez site signalé par Google. Le détail de chaque étape est dans la méthode de nettoyage d'un WordPress piraté, et le forfait sur la page intervention sur un WordPress piraté.