Le 6 août 2026, WordPress a publié 7.0.3, une version de sécurité d’urgence. Parmi les failles qu’elle referme, l’une dormait dans le cœur de WordPress depuis la branche 4.7, sortie en décembre 2016 : près d’une décennie. Cette faille est répertoriée CVE-2026-64638. Le chercheur qui l’a trouvée l’a surnommée XSS2Shell. Prise seule, XSS2Shell est une faille XSS réfléchie pré-authentification sur l’écran wp-login.php : aucun compte n’est nécessaire pour la déclencher. La transformer en prise de contrôle totale du serveur est une étape distincte, plus difficile : elle exige qu’un administrateur connecté clique sur un lien piégé. Ce n’est donc pas le scénario « zero-click » que certains titres ont laissé entendre. Ce n’est pas non plus la première faille du cœur affublée d’un surnom marquant que WordPress a dû corriger en urgence cette année : nous avions déjà couvert wp2shell. Allons voir ensemble ce que XSS2Shell enchaîne réellement, et ce que cela change pour vous.
Ce qui vient d’être corrigé, et pourquoi cela compte même si vous avez déjà mis à jour
D’après l’annonce officielle de WordPress.org, la 7.0.3 regroupe plusieurs correctifs de sécurité, diffusés par le canal habituel de WordPress : les sites dotés des mises à jour automatiques en arrière-plan l’ont déjà reçue, ou la recevront sous peu. Cette même version referme aussi plusieurs failles sans lien avec XSS2Shell, dont des signalements de XSS stockée pour des comptes de niveau contributeur, ainsi que quelques problèmes de divulgation d’information et d’élévation de privilèges. Mais XSS2Shell reste la faille marquante du lot : la seule accessible sans le moindre compte.
Le correctif a été rétroporté sur toutes les branches encore couvertes par les correctifs de sécurité de WordPress, jusqu’à la version 4.7 incluse. LE correctif est sans doute déjà chez vous si votre hébergeur applique les mises à jour automatiques ; sinon, ou si une extension les désactive, appliquer la 7.0.3 à la main aujourd’hui comble l’écart. Savoir que vous êtes en 7.0.3 est la partie facile ; la vérification de deux minutes plus loin dans cet article confirme que vous êtes réellement couvert, pas seulement supposé l’être. Cette plage de rétroportage dit aussi quelque chose qui mérite qu’on s’y arrête : le même angle mort a survécu à des années de revue de code, dans une base aussi auditée que celle de WordPress. C’est justement ce qu’explique la section suivante.
Comment un bug d’analyse sur la page de connexion se transforme en prise de contrôle totale du serveur
Chaque tentative de connexion échouée fait transiter le nom d’utilisateur saisi par une chaîne de fonctions de nettoyage, avant de le réafficher dans le message d’erreur affiché à l’écran. Deux de ces fonctions ne s’accordent pas sur ce qui constitue une balise HTML valide. Ce désaccord est tout le bug. La fonction wp_strip_all_tags(), qui encapsule le strip_tags() natif de PHP, ne reconnaît le début d’une balise que si un chevron ouvrant est immédiatement suivi d’une lettre. Laissez un simple espace entre les deux, et le texte passe intact. En aval, la seconde passe de nettoyage, wp_kses_post(), se montre plus tolérante : elle accepte cette même balise espacée comme du HTML valide, et la reconstruit en un véritable élément sur la page, car ce type de balise figure sur sa propre liste blanche.
Résultat concret : un nom d’utilisateur forgé survit au premier filtre sous forme de texte d’apparence inoffensive, puis se retrouve reconstruit en un véritable élément HTML par le second. L’élément que décrit le write-up de pwn.ai exploite une particularité des navigateurs appelée DOM clobbering. Tout élément HTML doté d’un attribut id devient accessible en JavaScript comme variable globale portant ce même nom, ce qui permet à un attaquant d’écraser une variable qu’un script WordPress utilise déjà sans la vérifier. Ici, cette variable s’appelle ajaxurl, une valeur dont dépend le script user-profile.js de la page de connexion elle-même. Une fois qu’ajaxurl pointe vers une adresse que l’attaquant contrôle, les propres requêtes de ce script sont détournées vers un point d’accès de l’API REST de WordPress, que l’attaquant peut utiliser pour exécuter du JavaScript arbitraire sur une page de connexion WordPress, sans le moindre compte.
Cette exécution de JavaScript, à elle seule, ne livre pas le serveur. Pour y parvenir, il faut qu’un administrateur connecté clique sur un lien. C’est là que XSS2Shell réemploie une technique que son découvreur, Nigusu Kasahun, avait déjà mobilisée dans des recherches antérieures : la Same Origin Method Execution, publiée pour la première fois contre d’autres cibles par Paulos Yibelo en 2022. Si un administrateur ouvre le lien piégé alors qu’il est connecté, le script injecté peut piloter à sa place l’écran d’autorisation des mots de passe d’application de WordPress, en récupérer un valide, puis l’utiliser pour publier une page contenant du script (les administrateurs disposent par défaut de la capacité unfiltered_html), et enfin téléverser un plugin au format ZIP dont les fichiers PHP s’exécutent sans jamais être activés. Pwn.ai précise que toute la découverte, du repérage du désaccord entre les deux parseurs jusqu’à l’assemblage de cette chaîne en cinq étapes, s’est déroulée de façon autonome via sa propre plateforme de recherche, en partant de cette technique de 2022. Un fait qui en dit plus sur leur outillage que sur votre site WordPress.
Que faut-il réellement pour être exposé ?
Une fois la chaîne décomposée, deux niveaux de risque bien distincts s’empilent. Le volet XSS ne demande rien de votre part : ni compte, ni clic, juste une visite normale sur une page de connexion vulnérable, ce qui explique pourquoi WordPress a rétroporté le correctif jusqu’à la 4.7. Le volet prise de contrôle totale, lui, cible une cible bien plus étroite : il ne se déclenche que si un administrateur connecté ouvre un lien contrôlé par l’attaquant, que ce soit via un message d’hameçonnage, une publicité compromise, ou un lien piégé partagé quelque part qu’un administrateur jugerait digne de confiance.
Les sites administrés par une seule personne prudente n’ont jamais été à une visite d’un shell. Les sites avec plusieurs comptes admin, des identifiants partagés, ou des administrateurs qui cliquent avant de vérifier, portaient le vrai risque. Rien de tout cela ne réduit l’urgence du correctif, puisque le volet XSS seul offre déjà une prise à refuser à un attaquant. Cela signifie simplement que les titres qui ont parlé de prise de contrôle « zero-click » ont amplifié le second volet de la chaîne au-delà de ce qu’il est.
Êtes-vous vraiment protégé ? La vérification de deux minutes
Confirmer que vous êtes couvert prend moins de temps que la lecture de cette section. Dans votre tableau de bord WordPress, ouvrez Tableau de bord, puis Mises à jour, ou vérifiez le numéro de version affiché en bas de la plupart des écrans d’administration : tout ce qui est en 7.0.3 ou au-delà porte déjà le correctif. Si vous voyez un numéro plus ancien et aucune bannière de mise à jour en attente, les mises à jour automatiques en arrière-plan sont soit désactivées, soit en échec silencieux, ce qui mérite d’être vérifié directement plutôt que supposé.
Les mises à jour automatiques couvrent par défaut les versions de sécurité du cœur chez la plupart des hébergeurs, mais trois situations vous en excluent discrètement : une extension de sécurité ou un réglage côté hébergeur qui les désactive, un site figé sur une branche non maintenue plus ancienne que la 4.7, et un hébergement WordPress managé où c’est l’hébergeur, pas WordPress lui-même, qui pilote le calendrier des mises à jour. Si l’une de ces situations décrit votre cas, mettre à jour vers la 7.0.3 à la main, depuis Tableau de bord → Mises à jour → Mettre à jour maintenant, prend moins d’une minute. Si vous gérez un site pour un client ou un employeur, c’est le bon moment pour confirmer par écrit que les mises à jour de sécurité automatiques sont réellement activées, car « quelqu’un d’autre s’en occupe » est précisément la façon dont un site prend plusieurs versions correctives de retard. Notre checklist « Faut-il passer à WordPress 7.0 ? » reprend les mêmes vérifications de version et de compatibilité, en plus détaillé, si vous voulez la routine complète.
Notre avis
XSS2Shell n’est pas l’histoire d’une extension négligée ou d’un site resté sans correctif pendant des années. C’est l’histoire de deux fonctions internes de WordPress qui se contredisaient silencieusement sur ce qu’est du HTML valide, depuis près d’une décennie, sans que personne ne le remarque, jusqu’à ce qu’une équipe de recherche cherche précisément ce genre de désaccord. Qu’une base de code aussi auditée puisse encore cacher un désaccord d’analyse aussi ancien est une raison de continuer à corriger rapidement, pas une raison de se méfier davantage du cœur de WordPress. La prime versée à pwn.ai et la divulgation coordonnée la même semaine sont le système qui fonctionne comme prévu, pas un signe qu’il a échoué.
Voici où cela vous laisse, selon votre situation :
- Si votre tableau de bord affiche déjà la 7.0.3 ou une version plus récente, vous êtes couvert ; aucune action nécessaire.
- Si vous voyez une version plus ancienne et aucune mise à jour en attente, mettez à jour à la main aujourd’hui, depuis Tableau de bord → Mises à jour → Mettre à jour maintenant.
- Si vous gérez un site pour un client ou un employeur, confirmez par écrit que les mises à jour de sécurité automatiques sont réellement activées, pas seulement supposées l’être.
- Si plusieurs personnes disposent d’un accès administrateur, rappelez-leur de traiter tout lien inattendu, même d’apparence liée à WordPress, avec la même prudence qu’un courriel d’hameçonnage.
Mettez à jour, vérifiez que vous êtes réellement couvert plutôt que de le supposer, et reprenez la gestion de votre site.
