XSS Vulnérabilité sur WordPress qui peut grimper à PHP et l'urgence de patch maintenant

WordPress a publié le 6 août un patch qui corrige une vulnérabilité de le script de site croisé (XSS) réfléchi sur l'écran d'accès qui, selon la découverte publique, peut être enchaîné à l'exécution de code PHP sous certaines conditions. L'échec a été signalé par la compagnie pwn.ai et enregistré comme CVE-2026-64638 (cote CVSS 8.9). WordPress a inclus la correction dans la version 7.0.3 et l'a appliquée rétroactivement à la branche 4.7; les installations avec mises à jour automatiques activées devraient recevoir le patch sans intervention de l'administrateur. La référence CVE est disponible dans la base de données NVD: https: / / nvd.nist.gov / vuln / detail / CVE-2026-64638, et l'annonce officielle de sécurité WordPress dans votre catégorie de nouvelles: https: / / wordpress.org / actualités / catégorie / sécurité /.

Ce qui est confirmé par pwn. est que le XSS est d'un type réfléchi et accessible depuis la page de connexion sans authentification: un nom d'utilisateur spécialement formé envoyé dans une tentative d'accès raté peut atteindre l'utilisateur final dans la page d'erreur et exécuter JavaScript dans le navigateur. Que JavaScript, selon l'entreprise, peut être enchaîné avec d'autres comportements WordPress pour causer des requêtes d'origine identique qui permettent un contrôle supplémentaire au sein de la session du site. Mots Press, dans son avis public, décrit une évaluation plus prudente: passer de ce XSS à l'exécution du code sur le serveur (ERC) nécessite des conditions hors du contrôle de l'agresseur - en particulier, l'interaction et l'approbation explicite d'un administrateur - et nécessite donc un succès en ingénierie sociale en plus de la vulnérabilité initiale.

Techniquement, l'échec résulte d'un conflit entre différents filtres que WordPress applique à la valeur du nom d'utilisateur après une tentative d'accès ratée. D'une manière simplifiée et vérifiée par les chercheurs, les données passent par sanitize _ user () et wp _ strip _ all _ tags () (en utilisant la fonction PHP strip _ tags ()). Les chaînes qui ressemblent à des balises HTML mais contiennent des espaces immédiatement après le signe "<" peut survivre que le premier traité comme texte. Ci-dessous, Parole Presse applique wp _ kses _ post (), dont l'analyseur interprète la même entrée que HTML autorisée, ce qui entraîne l'insertion d'éléments DOM contrôlés par l'attaquant dans la page d'erreur de connexion. Ces éléments finissent par interagir avec user-profile.js, un script de gestion de profil qui est chargé sur la page de connexion par la gestion de la restauration de mot de passe ; l'absence de certains champs attendus dans ce contexte laisse les variables dans un état non défini et permet un élément d'écrasement injecté, par exemple ajaxurl, rediriger la logique JavaScript vers une requête sélectionnée par l'attaquant. pwn.ai a également montré comment profiter de la compatibilité JSONP dans l'API WordPress REST pour convertir la réponse au code JavaScript exécuté avec l'origine du site. Dans les environnements où l'API répond 401 pour les requêtes anonymes, le paramètre _ enveloppe = 1 peut envelopper ce déni avec un 200 externe et faire de jQuery traiter la réponse comme un script.

Les chercheurs ont appelé leur chaîne XSS2Shell et décrivent plusieurs routes vers l'exécution PHP. Une des démonstrations jouées par pwn.ai utilise le XSS pour invoquer l'interface d'approbation des mots de passe de l'application native dans une session déjà authentifiée avec le rôle d'administrateur. Cette interface crée un titre API et redirige vers une URL réussie contrôlée par l'attaquant; avec le titre créé, l'attaquant peut publier une page contenant JavaScript même origine et, lorsqu'un administrateur authentifié l'ouvre, ce script obtient le nonce pour télécharger des plugins et fait le téléchargement d'un fichier ZIP contenant du code PHP. Dans le test de concept pwn.ai, le code PHP pourrait être demandé directement depuis le plugin extrait sans avoir à activer le plugin. Important : pwn.ai a séparé les étapes en différents tests : la reproduction XSS sur des serveurs distants a été effectuée dans des installations WordPress 7.0.2 sans cookies de session, tandis que la démonstration complète qui vient à l'exécution PHP a été faite dans un environnement local propre.

Ce qui est confirmé: Il y a un XSS réfléchi sur la page de connexion sans authentification et WordPress a publié un patch le 6 août. pwn.ai reproduit localement la chaîne complète jusqu'à l'exécution de PHP et a démontré l'exploitation du chemin Application Passwords en laboratoire. Mots La presse a reconnu la découverte, accrédité l'équipe et publié la mise à jour de sécurité; à la clôture des preuves publiques (7 août), il n'y avait pas de rapports vérifiés d'exploitation de nature.

Ce qui est estimé ou encore incertain: la mesure dans laquelle cette chaîne est activement exploitée contre les sites de production n'est pas confirmée; l'escalade vers les CER nécessite l'interaction d'un administrateur authentifié et, selon WordPress, des éléments d'ingénierie sociale qui échappent au contrôle technique de l'attaquant. L'efficacité de l'atténuation partielle (p. ex. politiques complexes du CSP ou certains durcissements) a été testée par les chercheurs dans certains scénarios et a constaté qu'une politique du CSP basée sur Nonce n'empêchait pas la démonstration, mais le comportement peut varier selon les plugins, les paramètres et les versions du serveur.

À qui ça sert ? Pratiquement toute installation WordPress qui n'a pas appliqué la mise à jour: les chercheurs s'assurent que la chaîne fonctionne contre les installations par défaut et ne nécessite pas de configurations d'hébergement inhabituelles. Les installations avant la succursale 4.7 sont à l'extérieur du support de l'arrière-port et restent donc exposées si elles ne sont pas mises à jour ou garées manuellement.

Les conséquences d'une opération complète seraient graves : obtention d'identifications stockées dans wp-config.php, création persistante de comptes administratifs, téléchargement et exécution de code PHP, modification ou suppression de contenu et exposition de fichiers ou de secrets accessibles par le processus PHP. L'étendue réelle des dommages dépend du contexte du serveur (privilèges du travailleur, mesures du système de fichiers, disponibilité des sauvegardes et contrôles d'intégrité).

Mesures pratiques et spécifiques à mettre en œuvre aujourd'hui par les gestionnaires: mise à jour à WordPress 7.0.3 ou une autre version qui inclut la correction; si la mise à jour n'est pas possible immédiatement, minimiser l'exposition au fichier d'accès : protéger wp-login. php avec authentification HTTP supplémentaire ou restreindre votre accès IP, activer un WAF avec des règles qui bloquent les injections dans les paramètres de connexion, désactiver l'édition plugin / thème du tableau de bord, révoquer les Mot de passe d'application récemment créés et vérifier la liste d'identifications. Après la mise à jour, consultez le site à la recherche de nouveaux comptes administratifs ou des modifications de plugin / thèmes et vérifiez l'intégrité des fichiers et la présence de fichiers ZIP ou plugin non légitimes. Si vous soupçonnez des fiançailles, changez le wp-config. php clés de saut, restaurer des sauvegardes propres et envisager un audit médico-légal. Activer 2FA et limiter l'utilisation de comptes avec des privilèges élevés réduit la fenêtre d'exploitation de l'ingénierie sociale.

Enfin, gardez la sauvegarde hors du serveur de production et activez les mises à jour automatiques lorsque c'est possible ; WordPress indique que les sites avec des mises à jour de fond devraient recevoir la version automatiquement. Étant donné que l'opération complète décrite par pwn.ai nécessite une interaction supplémentaire avec un administrateur, la combinaison immédiate de patchs, les contrôles d'accès à la connexion et les bonnes pratiques de sécurité opérationnelle est la défense la plus efficace.

La découverte montre comment présenter des vulnérabilités (XSS sur une page d'erreur) peut devenir des vecteurs critiques lors de l'interaction avec la logique existante et les API du même site. La recommandation technique et pratique est sans équivoque : mettre en œuvre la mise à jour officielle sans délai et examiner les administrateurs et les pouvoirs exposés.