WordPress a déployé un correctif urgent pour une XSS avant authentification (Cross-Site Scripting) sur son écran de connexion. Cette faille concerne toutes les versions du CMS et a été identifiée comme pouvant être chaînée jusqu’à l’exécution de code côté serveur, dans un scénario précis impliquant un administrateur connecté.
Le problème a reçu l’identifiant CVE-2026-64638 et obtient une note de gravité élevée (CVSS 8,9). Si l’attaque détaillée par les chercheurs n’est pas “plug-and-play” dans tous les cas, le risque global reste suffisamment important pour justifier une mise à jour immédiate.
De quoi parle l’erreur : XSS sur la page de connexion
La vulnérabilité se manifeste sur la page de connexion, avant toute authentification. Concrètement, un nom d’utilisateur spécialement forgé passe par l’affichage de la page en cas d’échec de connexion, puis se transforme en éléments DOM contrôlés par l’attaquant.
Les chercheurs indiquent qu’il n’est pas nécessaire de “faire” autre chose sur la page d’erreur : une fois le code JavaScript déclenché dans le navigateur de la victime, le mécanisme peut démarrer sans action supplémentaire sur cette page précise.
Pourquoi c’est critique : de la XSS au code PHP
Le passage de la XSS à l’exécution de code PHP ne dépend pas seulement de la faille elle-même. Les étapes menant au contrôle côté serveur supposent notamment que la victime soit déjà connectée en tant qu’administrateur.
Dans la démonstration décrite, l’interaction attendue se résume à un comportement banal : un clic de l’administrateur sur une page contrôlée par l’attaquant.
Selon le rapport, il existe plusieurs chemins possibles à partir de la chaîne d’exploitation, avec des variantes pouvant notamment installer une extension ou téléverser un fichier ZIP arbitraire. Les détails indiquent que ces options reposent sur la façon dont WordPress gère certains scripts côté profil et certaines routes/API internes.
Fonctionnement de la chaîne : encodage, parsing et DOM contrôlé
Le point de départ se situe dans la manière dont WordPress traite la valeur du champ username en cas d’échec. D’après les chercheurs, la donnée traverse successivement des traitements tels que sanitize_user() puis wp_strip_all_tags(), qui s’appuient sur la fonction strip_tags de PHP.
Dans certains cas, une chaîne ressemblant à une balise peut survivre au “strip” si elle contient un motif particulier (notamment une particularité d’espacement après le caractère “<”). Ensuite, WordPress réinjecte la valeur via un autre filtrage, dont le comportement interprète l’entrée comme du HTML autorisé.
Au final, la page de connexion peut contenir des éléments DOM “vivants” pilotés par l’attaquant. Ces éléments interagissent ensuite avec des scripts JavaScript déjà présents, notamment un fichier de gestion de profil chargé sur la page de connexion parce qu’il gère aussi des fonctions comme les réinitialisations de mot de passe.
Conditions d’exploitabilité : ce que WordPress souligne
WordPress adopte une lecture plus prudente de l’exploitabilité complète. L’éditeur explique que l’escalade jusqu’à la RCE (exécution de code à distance) dépend de conditions en dehors du contrôle direct de l’attaquant.
Cette escalade exige notamment une combinaison de manipulation sociale (social engineering) et une interaction explicite de la victime. Dit autrement : la faille XSS en elle-même est un déclencheur, mais le scénario complet requiert des étapes supplémentaires côté victime.
Ce qui augmente le risque : Application Password et téléversement
Les chercheurs décrivent un chemin où la XSS côté navigateur peut conduire à une interaction avec le contrôle d’approbation des Application Passwords au sein d’une session administrateur déjà authentifiée.
Le principe rapporté est le suivant : WordPress crée une crédential API et redirige ensuite vers une destination HTTPS choisie par l’attaquant (success_url). Ces identifiants peuvent ensuite servir à exécuter des actions authentifiées via l’API, sans que l’attaquant ait besoin de récupérer le mot de passe principal de l’administrateur.
Dans la démonstration, la chaîne aboutit à la capacité de publier une page contenant du JavaScript du même origine, ce qui permet ensuite d’obtenir un nonce lié au téléversement et de charger un ZIP fourni par l’attaquant. Les chercheurs précisent que l’upload suffit pour la suite décrite, sans exiger nécessairement l’activation de l’extension.
Quels correctifs ont été publiés ?
WordPress a publié un correctif le 6 août, et la correction est incluse dans la version 7.0.3. Le correctif a aussi été rétroporté via la branche 4.7.
L’éditeur recommande de procéder à la mise à jour sans délai. Les sites qui supportent les mises à jour automatiques en arrière-plan devraient recevoir la mise à jour de sécurité automatiquement.
Les versions plus anciennes que 4.7 restent vulnérables, mais elles ne font plus partie du périmètre actif des rétroports.
Des hardenings connus ne remplacent pas le correctif
Les chercheurs avertissent que des mesures de durcissement généralement connues ne doivent pas être considérées comme une solution complète au problème à la source. Appliquer la mise à jour corrigée demeure l’action prioritaire.
Ils signalent notamment que leur chemin démontré n’est pas bloqué par certaines configurations de Content Security Policy basées sur un nonce et utilisant strict-dynamic, au moins dans le cadre de leur expérimentation.
État de l’exploitation : pas d’indication de campagne active
Au moment de l’information relayée, WordPress ne signale pas d’exploitation “dans la nature”. Les chercheurs ayant divulgué le problème et fourni des éléments techniques ont travaillé à une reproduction responsable de la chaîne de vulnérabilités.
Malgré l’absence de preuve d’exploitation active au moment du signalement, l’impact potentiel décrit (jusqu’à la compromission de données et la possibilité d’actions persistantes) justifie une réponse urgente côté administrateurs.
Pourquoi mettre à jour tout de suite ?
Si la chaîne aboutit à une exécution de code PHP réussie, elle pourrait ouvrir la porte à des conséquences importantes : exposition de secrets via la configuration, création/altération d’utilisateurs administrateurs, lecture de fichiers accessibles au processus PHP, ou encore exécution de commandes au niveau des privilèges du worker PHP.
En clair : même si l’attaquant doit réunir des conditions précises, la meilleure protection reste un correctif appliqué rapidement. La gestion “au cas par cas” des réglages de sécurité ne remplace pas le fait de supprimer la cause de la XSS avant authentification.
Checklist de remédiation
- Mettez à jour WordPress vers 7.0.3 ou une version incluant le correctif.
- Vérifiez que votre installation fait partie des versions suivies pour les rétroports.
- Assurez-vous que les mises à jour automatiques fonctionnent si vous les utilisez.
- Considérez la page de connexion comme une zone sensible : limitez l’exposition et surveillez les journaux.
Conclusion
WordPress corrige une XSS avant authentification sérieuse sur sa page de connexion, référencée CVE-2026-64638. Les chercheurs montrent qu’elle peut, sous des conditions impliquant un administrateur déjà connecté et une interaction sur une page contrôlée, mener à l’exécution de code PHP.
Le message est clair : appliquez la mise à jour dès maintenant, car les mesures de durcissement ne suffisent pas à éliminer la vulnérabilité à la racine.
Source: https://thehackernews.com/2026/08/new-wordpress-pre-auth-xss-could-lead.html
