WordPress vient de corriger une importante vulnérabilité touchant toutes les versions du CMS. Référencée CVE-2026-64638 et notée 8,9/10, elle permet de déclencher une attaque XSS depuis la page de connexion sans disposer au préalable d’un compte sur le site.
Des chercheurs de pwn.ai ont surtout démontré qu’il était possible d’enchaîner cette faille jusqu’à obtenir une exécution de code PHP sur le serveur WordPress. Cette seconde étape nécessite toutefois qu’un administrateur déjà connecté interagisse avec une page contrôlée par l’attaquant.
Une faille directement dans la page wp-login.php
La vulnérabilité prend naissance dans la manière dont WordPress traite le nom d’utilisateur fourni lors d’une tentative de connexion échouée. Une valeur spécialement construite peut traverser plusieurs mécanismes de nettoyage qui ne l’interprètent pas de la même manière.
Le résultat est une XSS réfléchie pré-authentification : du contenu contrôlé par l’attaquant peut se transformer en éléments HTML actifs dans la page de connexion et conduire à l’exécution de JavaScript dans le navigateur de la victime, sous l’origine du site WordPress.
Selon les chercheurs, l’attaque fonctionne sur une installation WordPress standard et ne nécessite pas de configuration d’hébergement particulière.
De la XSS jusqu’à l’exécution de PHP sur le serveur
La XSS seule s’exécute dans le navigateur. Mais pwn.ai a développé une chaîne d’exploitation baptisée XSS2Shell permettant, dans certaines conditions, d’aller beaucoup plus loin.
Dans la démonstration complète, la victime doit être déjà connectée avec un compte Administrateur WordPress et effectuer une interaction avec une page contrôlée par l’attaquant. Les chercheurs indiquent qu’un simple clic suffit dans le scénario présenté.
La chaîne exploite ensuite différentes fonctionnalités légitimes de WordPress pour obtenir des droits permettant finalement de déposer du code PHP sur le serveur. Les chercheurs ont notamment démontré des variantes passant par la création d’un Application Password ou le téléversement d’une archive de plugin.
WordPress tempère le scénario d’attaque
WordPress considère néanmoins que le passage de la XSS à une compromission complète du serveur dépend de plusieurs conditions qui ne sont pas directement contrôlées par l’attaquant. L’administrateur doit notamment disposer d’une session active et être victime d’une opération de social engineering.
Il est donc important de distinguer les deux niveaux : la XSS de la page de connexion ne nécessite aucune authentification, tandis que la chaîne menant jusqu’à l’exécution de code PHP nécessite des conditions supplémentaires et l’intervention d’un administrateur.
Une CSP stricte ne suffit pas forcément
Autre point particulièrement intéressant : les chercheurs indiquent avoir testé leur scénario sur une configuration utilisant une Content Security Policy basée sur des nonces et strict-dynamic. Cette protection n’aurait pas bloqué la chaîne démontrée.
Une CSP reste une importante couche de défense contre de nombreuses attaques XSS, mais elle ne doit donc pas être considérée comme un correctif à CVE-2026-64638. La mise à jour de WordPress reste nécessaire.
Que peut faire un attaquant après une exécution de code PHP ?
Une exécution de PHP transforme une vulnérabilité côté navigateur en compromission potentielle du serveur. Selon les privilèges du processus PHP, un attaquant pourrait notamment :
- accéder aux identifiants de base de données présents dans wp-config.php ;
- créer des comptes administrateurs persistants ;
- modifier le contenu du site ;
- consulter des fichiers et secrets accessibles au processus PHP ;
- exécuter des commandes avec les privilèges accordés au serveur web.
La faille corrigée dans WordPress 7.0.3
WordPress a publié le correctif le 6 août 2026 avec WordPress 7.0.3. La correction a également été rétroportée vers les branches maintenues jusqu’à WordPress 4.7.
Les installations dont les mises à jour de sécurité automatiques sont actives devraient recevoir le correctif automatiquement. Les sites utilisant une version antérieure à WordPress 4.7 restent en revanche vulnérables et se trouvent hors du périmètre actuel des correctifs rétroportés.
Une vulnérabilité découverte avec des agents IA
L’histoire de la découverte est elle-même inhabituelle. L’équipe de pwn.ai explique avoir utilisé un système multi-agents basé sur des modèles d’intelligence artificielle open source pour rechercher et reproduire la chaîne d’exploitation.
Les chercheurs indiquent avoir obtenu la chaîne complète après environ quatre jours de travail, l’avoir reproduite le 26 juillet puis signalée à WordPress le lendemain. Leur travail s’appuyait notamment sur des recherches publiées en 2022 autour de la technique Same Origin Method Execution.
Aucune exploitation massive observée pour le moment
Au 7 août 2026, aucune exploitation active de CVE-2026-64638 n’est annoncée par WordPress. Les chercheurs ont confirmé la XSS sur des installations WordPress 7.0.2 accessibles sur Internet, mais précisent ne pas avoir tenté d’y réaliser les étapes conduisant à l’exécution de PHP.
La chaîne complète a été reproduite séparément sur une installation de test. Avec des millions de sites reposant sur WordPress et des détails techniques désormais publics, la mise à jour vers une version corrigée doit être appliquée sans attendre.