XSS2Shell (CVE-2026-64638) : de la page de connexion WordPress à l'exécution de code, en un seul clic administrateur
CVSS 8.9 · Pré-authentification · Patché en urgence dans WordPress 7.0.3
Résumé
Le 7 août 2026, l'équipe de recherche pwn.ai a rendu public XSS2Shell, une chaîne de vulnérabilités logée dans le cœur même de WordPress. Elle permet à un attaquant non authentifié d'injecter du JavaScript dans l'origine du site via la page de connexion (wp-login.php), puis, si un administrateur clique sur un lien piégé, de faire escalader cette exécution JavaScript jusqu'à l'exécution de code PHP arbitraire côté serveur.
WordPress équipe plus de 43 % des sites web dans le monde. La faille était présente depuis les toutes premières versions du CMS et touchait, avant correctif, l'ensemble des branches encore maintenues (rétroportage jusqu'à la 4.7). WordPress a publié un correctif d'urgence, la version 7.0.3, le 6 août 2026.
Si vous exploitez un site WordPress, nous vous prions de vérifier que vous êtes en 7.0.3.
Explications de la chaîne de vulnérabilités
Plusieurs équipes de sécurité, dont pwn.ai elle-même dans un premier temps, ont choisi de ne pas diffuser la chaîne d'exploitation intégrale tant qu'une part significative du parc WordPress. Voici la mécanique générale telle qu'elle a été documentée publiquement :
Un contournement au niveau des deux assainisseurs HTML. Le nom d'utilisateur soumis sur l'écran de connexion passe par une première fonction de nettoyage avant d'être réinjecté dans le message d'erreur, puis par une seconde, plus permissive, au moment de l'affichage. Les deux fonctions ne s'accordent pas sur ce qui constitue une "balise" : une chaîne que la première juge inoffensive peut être réinterprétée par la seconde comme du HTML valide. C'est un cas d'école de différentiel de parseur, une classe de bug bien connue en sécurité web mais rarement démontrée avec un tel impact.
Du DOM détourné plutôt qu'injecté frontalement. Les éléments HTML ainsi glissés dans la page ne déclenchent pas un <script> classique. Ils exploitent le fait qu'un script legitime de WordPress, chargé sur la page de connexion pour d'autres besoins, va automatiquement chercher et manipuler certains éléments du DOM par leur identifiant, connu sous le nom de DOM clobbering.
Une escalade vers l'API REST puis, via cliquage forcé cross-fenêtre, vers les Application Passwords. La chaîne complète s'appuie sur une technique de Same Origin Method Execution (SOME), déjà documentée par le passé sur ce même CMS, pour faire cliquer à distance un bouton d'autorisation dans la session authentifiée d'un administrateur, récupérer un jeton d'API légitime, puis l'utiliser pour publier du contenu et téléverser une extension menant à l'exécution PHP.
L’étape critique nécessite qu'un administrateur clique sur un lien contrôlé par l'attaquant pendant qu'il est connecté. Ce n'est donc pas un ver auto-propageable, mais une attaque ciblée à fort impact.
Chronologie
Date | Événement |
26 juillet 2026 | Chaîne complète découverte et reproduite par pwn.ai |
27 juillet 2026 | Signalement à WordPress avec preuve d'exécution de code |
6 août 2026 | Publication de WordPress 7.0.3, CVE-2026-64638 attribué |
7 août 2026 | Divulgation publique coordonnée |
Versions affectées
Toute installation WordPress en version 6.4 à 7.0.2 est exposée à la partie pré-auth de la chaîne (le chemin de rendu de l'erreur de connexion, introduit en 6.4, est une condition nécessaire à l'exploitation).
Le correctif a néanmoins été rétroporté jusqu'à la branche 4.7 par précaution. Les instances sous une version antérieure à 4.7, elle, hors du champ de maintenance depuis longtemps, devraient de toute façon être migrées.
Recommandations
Mettre à jour vers WordPress 7.0.3 sans délai. Les sites avec mise à jour automatique en arrière-plan l'ont probablement déjà reçue
Ne pas se reposer sur un WAF comme seule protection. Des variantes de contournement des règles périmétriques classiques ont déjà circulé ; le correctif applicatif reste la seule remédiation fiable.
Auditer les comptes administrateurs et les Application Passwords existants : révoquer tout jeton d'application non reconnu, et sensibiliser les administrateurs à ne pas cliquer sur des liens non sollicités menant à des pages d'autorisation WordPress, le temps que le parc soit à jour.
Vérifier les journaux d'authentification pour des tentatives de connexion avec des noms d'utilisateur contenant des séquences < suivies d'un espace. POST /wp-login.php où le champ log contient %3C (un < encodé)
Conclusion
Deux fonctions de sanitisation, chacune correcte prise isolément, chacune testée, chacune en production depuis des années.
Pourtant leur composition ouvre une chaîne jusqu'à l'exécution de code. C'est une bonne illustration de pourquoi l'audit de sécurité applicatif ne peut pas se limiter à vérifier que chaque brique est "sûre" individuellement : c'est l'interaction entre les briques qui crée la surface d'attaque réelle.
Chez Safercy, c'est précisément ce type d’enchaînement que nos tests d'intrusion et nos audits cherchent à mettre en évidence avant qu'un tiers malveillant ne le fasse.
Sources
pwn.ai, XSS2Shell: WordPress Preauth XSS to RCE Chain (CVE-2026-64638), 7 août 2026
WordPress.org, WordPress 7.0.3 Security Release, 6 août 2026
