Une faille dans WordPress: le formulaire de connexion livre le serveur
Une faille de WordPress surnommée XSS2Shell transforme une tentative de connexion ratée en code PHP exécuté sur le serveur. Référencée CVE-2026-64638, elle obtient 8,9 sur l'échelle CVSS. Tout commence par un nom d'utilisateur saisi dans le formulaire de connexion public et se termine, dans les bonnes conditions, par une extension fournie par l'attaquant décompressée dans votre installation. WordPress a livré le correctif dans la version 7.0.3 le 6 août 2026, avec des rétroportages jusqu'à la branche 4.7. Du code d'exploitation public est apparu en quelques jours.
Comment fonctionne la chaîne XSS2Shell
Le point d'entrée est le message d'erreur de connexion. Soumettez un nom d'utilisateur inexistant et WordPress vous le renvoie sur la page. Ce reflet est censé être inoffensif, et deux assainisseurs distincts se dressent sur le chemin. Le contournement trouvé par l'équipe de pwn.ai exploite un désaccord entre eux: strip_tags() ne considère pas comme une balise une construction précédée d'une espace, si bien qu'une charge de la forme < area id=ajaxurl> passe intacte, tandis que wp_kses_post() lit ensuite la même chaîne comme du HTML valide et la rend sous forme d'élément réel dans la page.
Ce que fait cet élément est la partie astucieuse. Ce n'est pas un script. C'est un noeud DOM nommé qui entre en collision avec une variable JavaScript que WordPress laisse indéfinie sur cet écran, une technique appelée DOM clobbering. Un script d'administration du coeur va chercher ajaxurl, trouve l'élément de l'attaquant au lieu de rien, et dirige une requête là où l'attaquant l'a pointée. À partir de là, la chaîne passe par le code de confiance du site lui-même: un point d'accès REST prenant en charge JSONP exécute le JavaScript de l'attaquant dans l'origine du site, une astuce d'exécution de méthode entre fenêtres atteint la session d'un administrateur connecté pour approuver un Application Password, et cet identifiant ouvre un accès REST authentifié.
La dernière étape ne demande aucun bogue exotique. L'Application Password volé porte des droits d'administrateur, l'attaquant se contente donc d'utiliser l'API pour téléverser une extension: une archive ZIP contenant du PHP. Sur une installation mono-site, un administrateur dispose en outre par défaut du droit au HTML non filtré, ce qui rend possible l'étape intermédiaire consistant à publier une page remplie de JavaScript. À ce stade, le code n'est plus dans le navigateur. Il s'exécute avec les privilèges du processus PHP, juste à côté des identifiants de la base de données.
Ce dont un attaquant a réellement besoin
C'est ici que le titre et la réalité se séparent. La moitié cross-site scripting ne réclame effectivement ni compte ni mot de passe, et c'est ce qui rend la faille pré-authentification. La moitié exécution de code à distance, elle, ne se déclenche pas toute seule. Un administrateur doit être connecté au site visé et doit ouvrir un lien contrôlé par l'attaquant. Aucune invite n'apparaît, aucune confirmation n'est demandée, la victime ne voit rien d'anormal, mais la visite doit avoir lieu.
En pratique, la barre est basse. Les administrateurs de sites cliquent toute la journée sur des liens dans des tickets de support, des formulaires de contact, des notifications de commentaires et des courriels de prestataires, souvent dans la même session de navigateur que celle où leur tableau de bord est ouvert. Lire "nécessite une interaction utilisateur" comme un réconfort, c'est exactement ainsi qu'une chaîne pareille reste non corrigée pendant un mois.
Quelles versions sont concernées
Toutes les versions de WordPress de 4.7 jusqu'à 7.0.2 incluse sont vulnérables. Cette branche est sortie en décembre 2016, ce qui explique que la plage touchée couvre pratiquement toute installation recevant encore des mises à jour. WordPress a publié le même jour des correctifs sur tout l'arbre supporté, de 7.0.3 en passant par 6.9.6 et 6.8.7 jusqu'à 4.7.34. Tout ce qui tourne en 4.6 ou antérieur ne reçoit plus aucune mise à jour de sécurité et doit être considéré comme exposé en permanence.
XSS2Shell faisait partie des douze problèmes fermés dans cette version. Les autres comprennent du cross-site scripting stocké dans les blocs Post Date et Post Content, dans les réglages d'émojis et dans l'édition rapide, une divulgation d'informations exposant les commentaires d'articles protégés par mot de passe, un contournement de la confirmation d'adresse électronique, une injection CSS via le filtre d'attributs sûrs, une élévation de privilèges sur les réseaux multisites à inscription ouverte, une falsification de requête côté serveur dans la validation d'URL atteignant les plages link-local, et une énumération des identifiants d'articles. Même sans la chaîne principale, cette liste est une raison de mettre à jour aujourd'hui.
Que faire maintenant
- Mettre à jour immédiatement: passer en 7.0.3 ou à la version corrigée de votre branche. Les mises à jour automatiques en arrière-plan installent par défaut les versions de sécurité mineures, mais vérifiez le numéro plutôt que de le supposer.
- Auditer les Application Passwords: ouvrir chaque profil d'administrateur et révoquer tout identifiant que vous ne reconnaissez pas. C'est l'artefact que la chaîne laisse derrière elle, et il survit à une réinitialisation du mot de passe.
- Passer en revue comptes, extensions et fichiers: chercher des comptes administrateurs que vous n'avez pas créés et des extensions apparues sans entrée correspondante dans votre propre historique de modifications.
- Ne pas ouvrir son tableau de bord n'importe où: garder la session d'administration dans un profil de navigateur distinct de celui utilisé pour le courriel et les tickets supprime la condition exacte dont dépend cette attaque.
- Restreindre l'écran de connexion: le reflet se trouve dans wp-login.php. En limiter l'accès, par liste d'adresses IP autorisées, authentification HTTP ou règle de pare-feu, réduit la surface pour le prochain bogue dans le même fichier.
Pourquoi cela dépasse les propriétaires de sites
Une installation WordPress compromise est rarement l'objectif de l'attaquant. C'est un véhicule de diffusion, et le trafic qu'elle sert inspire confiance précisément parce que le domaine est légitime. Nous avons vu le même schéma quand un script publicitaire s'est mis à réécrire des adresses de portefeuilles crypto sur des milliers de sites ordinaires, et la même idée se retrouve derrière les attaques au niveau du navigateur qui chevauchent une session authentifiée déjà ouverte par la victime. Pour un lecteur plutôt qu'un administrateur, la défense pratique se situe au niveau réseau: le filtrage DNS et les listes de blocage empêchent la charge de seconde étape de se charger, même quand le site qui la sert est un site que vous fréquentez depuis des années. C'est un argument direct en faveur des outils de confidentialité qui bloquent dès la résolution, et il faut dire franchement qu'aucun de ces outils ne corrige votre propre serveur. Seule la mise à jour le fait.
