CVE-2026-64638 : XSS2Shell, faille du login WordPress

Imaginez que vous êtes connecté à votre compte en banque dans un onglet de votre navigateur, sans l'avoir fermé. Si vous cliquez sur un lien piégé reçu par mail pendant que cet onglet reste ouvert, ce lien peut déclencher une action sur votre compte en utilisant votre session déjà active, sans jamais vous redemander votre mot de passe.

C'est exactement le principe de CVE-2026-64638 : la faille ne cause de dégâts que si un administrateur, déjà connecté à son site, clique sur un lien piégé pendant que cette session reste ouverte. Cette injection de code pré-authentifiée a été découverte sur la page de connexion WordPress (/wp-login.php), et corrigée le 6 août dans les versions 7.0.3, 6.9.6 et 6.8.7 selon la branche, avec un CVSS de 8.9.

Ce score paraît élevé, mais il ne dit pas grand-chose de la probabilité réelle d'exploitation. Chez la quasi-totalité de nos clients, seul un phishing ciblé contre un compte Administrateur déjà connecté permet de la déclencher, ce qui exclut toute exploitation de masse et explique pourquoi aucune compromission avérée n'a été rapportée à ce jour.

Vérifiez vos versions maintenant

Commencez par vérifier la version installée sur chaque instance WordPress du parc, sans vous fier à un échantillon, car une instance n'est réellement à jour qu'à partir de 7.0.3, 6.9.6 ou 6.8.7 selon la branche. Les mises à jour mineures automatiques ont sans doute déjà couvert une partie du parc, mais elles couvrent rarement sa totalité, d'où l'intérêt de vérifier chaque instance plutôt que de présumer qu'elle est protégée.

XSS2Shell est une faille de reflected cross-site scripting sur la page de connexion WordPress, et elle touche toutes les versions depuis la 4.7.

Ce qu'il faut surtout retenir, c'est que cette faille ne s'exploite jamais seule : elle demande que trois conditions soient réunies en même temps.

Condition 1 : la page de connexion doit être accessible depuis Internet

Tant que /wp-login.php n'est pas exposée publiquement, il n'existe tout simplement pas de vecteur d'attaque, quelle que soit la version installée.

Condition 2 : un administrateur doit ouvrir une page piégée en étant déjà connecté

Comme le paramètre concerné passe en POST, un simple lien ne suffit pas : il faut que l'attaquant conçoive une page qui déclenche la requête forgée au moment précis où la session admin reste active.

Condition 3 : le compte visé doit être Administrateur

Un rôle inférieur reste exploitable : l'attaquant peut compromettre ce compte-là aussi. Mais l'impact est nettement moindre, puisque ça ne permet pas de prendre le contrôle complet du site, contrairement à un compte Administrateur.

Une fois ces trois conditions posées, on comprend pourquoi il s'agit avant tout de phishing ciblé et non d'une exploitation automatisée de masse, d'autant qu'aucune exploitation in-the-wild n'a été rapportée à ce jour. C'est l'argument à tenir quand un client s'inquiète en découvrant le score CVSS.

Des chercheurs en sécurité ont par ailleurs publié une chaîne technique qui fait évoluer, sous conditions, ce XSS réfléchi vers une exécution de code PHP complète côté serveur. Tout part d'un nom d'utilisateur malformé, réfléchi dans le message d'erreur de la page de connexion, ce qui permet d'injecter des éléments DOM grâce à une technique de DOM clobbering détournant le script user-profile.js. À partir de là, l'attaquant sollicite la REST API par un callback JSONP pour dérober un Application Password appartenant à l'administrateur connecté, avant de déposer une extension malveillante et d'exécuter du code sur le serveur.

C'est un peu comme si un visiteur glissait un faux badge à l'accueil pour emprunter celui d'un employé resté sur son bureau, puis s'en servait pour entrer directement dans la salle des serveurs.

Rappelez-vous la première condition : la page de connexion doit être exposée sur Internet pour que la faille soit atteignable. C'est précisément ce que notre test vient confirmer, sans pouvoir garantir qu'un administrateur tombera dans le piège du phishing, ni vérifier à distance le rôle exact d'un compte : ces deux autres conditions restent contextuelles, propres à chaque organisation.

Chez Patrowl, on ne se contente jamais du seul numéro de version pour juger une faille, alors on envoie une requête de test avec une charge inoffensive, un simple marqueur dépourvu de tout code exécutable, et on observe ce que la réponse du serveur en fait. Si le marqueur revient interprété comme du HTML, la faille est confirmée et le site est réellement atteignable ; s'il revient sous forme échappée, c'est qu'il est protégé.

C'est un peu comme glisser un mot sous une porte pour voir s'il ressort intact ou froissé de l'autre côté : on ne force rien, on constate simplement ce que le site fait de ce qu'on lui transmet. C'est précisément ce qui nous permet d'affirmer à un client que la faille est réellement exploitable chez lui, et non simplement qu'il fait tourner une version vulnérable. Nous appliquons ce même contrôle sur les actifs EASM et sur le périmètre Pentest.

Chaque asset WordPress de votre parc reçoit l'un des deux statuts suivants dans votre dashboard Patrowl, et il est utile de comprendre ce qui les distingue.

Un asset passe en Qualified vulnerability dès lors que trois éléments coïncident : la version est vulnérable, la page de connexion exposée, et notre test confirme que l'injection fonctionne réellement. Dans ce cas, l'exploitabilité cesse d'être une hypothèse, elle est vérifiée, et l'asset doit être patché en priorité.

Un asset reste en revanche en Warning quand la version est vulnérable mais que l'exploitation ne peut pas être démontrée sur le terrain, souvent parce que Cloudflare ou Wordfence neutralisent cette attaque par défaut. La mise à jour reste nécessaire dans tous les cas, puisque la faille subsiste, mais l'urgence est moindre puisqu'une protection périphérique bloque son accès immédiat.

En cas de doute sur un asset donné, fiez-vous toujours au menu Qualified vulnerability pour établir la liste des assets réellement affectés.

Commencez par mettre à jour vers 7.0.3, 6.9.6 ou 6.8.7 selon votre branche, en vérifiant chaque instance individuellement plutôt qu'en vous fiant à une mise à jour globale. Sensibilisez ensuite vos administrateurs au phishing, puisque c'est le seul vecteur d'entrée réellement exploitable : rappelez-leur de ne jamais cliquer sur un lien vers l'interface d'admin reçu par mail, de privilégier la saisie directe de l'URL, et de fermer les sessions inutilisées. Si c'est faisable de votre côté, restreignez aussi l'accès à /wp-login.php aux réseaux de confiance, et envisagez de désactiver les Application Passwords qui ne sont pas utilisés.

La fiche de vulnérabilité complète reste disponible pour les clients qui souhaitent approfondir le détail technique.

Un numéro de version seul ne suffit jamais à évaluer un risque avec précision, c'est pourquoi Patrowl combine EASM et Pentest continu afin de confirmer, actif par actif, ce qui est réellement exploitable chez vous. Si vous voulez vérifier par vous-même dès maintenant, la fiche CVE-2026-64638 sur Patrowl Intel vous permet de le faire directement.