WordPress 7.0.3 corrige une faille critique dans l'écran de connexion

WordPress a publié le 6 août la version 7.0.3, qui corrige une faille identifiée CVE-2026-64638, notée 8,9 sur 10 en CVSS. Elle se situe dans l'écran de connexion du cœur de WordPress lui-même, ce qui la distingue des failles habituelles logées dans un thème ou une extension tierce : elle touche par défaut toute installation qui n'a pas encore appliqué le correctif, quel que soit le thème ou les extensions en place.

Le cabinet pwn.ai, qui a découvert la faille et lui a donné le nom « XSS2Shell », a signalé le problème à l'équipe de sécurité de WordPress le 27 juillet. WordPress l'a reconnu le jour même. Le correctif est sorti le 6 août dans la version 7.0.3, avec une divulgation publique coordonnée le lendemain. Rien dans cette chronologie n'indique d'exploitation avant la sortie du correctif : pwn.ai précise avoir protégé ses propres clients en amont de la divulgation, sans mentionner de cas observé ailleurs. C'est le scénario inverse de wp2shell (CVE-2026-63030), la faille WordPress couverte ici le 27 juillet, qui était déjà exploitée activement au moment de sa divulgation.

Comment la faille fonctionne

L'attaque de base est un cross-site scripting (XSS) réfléchi : une page piégée renvoie du code JavaScript que le navigateur de la victime exécute comme s'il venait légitimement du site WordPress visé. Ce qui rend celle-ci particulière, c'est qu'elle ne demande aucune authentification préalable. Un simple envoi de formulaire vers la page de connexion, avec une charge spécialement construite dans les paramètres, suffit à déclencher l'exécution du script — sans compte, sans cookie de session, sans connaissance préalable de la configuration du site.

Ce premier niveau reste limité à ce que permet un XSS classique : détourner une session, afficher un contenu falsifié, rediriger un visiteur. pwn.ai a démontré une seconde étape, plus grave : en incitant un administrateur déjà connecté à interagir avec une page contrôlée par l'attaquant, la chaîne peut aboutir à l'exécution de code PHP sur le serveur. Cette étape-là dépend d'une condition supplémentaire — l'administrateur doit cliquer ou charger la page piégée pendant qu'il est authentifié — ce qui la rapproche d'un scénario d'hameçonnage ciblé plutôt que d'une prise de contrôle automatique.

Le correctif a été rétroporté à chaque branche de WordPress activement maintenue, jusqu'à la 4.7. Concrètement, la faille dormait dans le code depuis près de dix ans avant d'être trouvée.

Onze autres failles corrigées dans le même lot

La version 7.0.3 ne se limite pas à XSS2Shell. Selon le décompte de Patchstack, elle referme douze vulnérabilités au total : la chaîne XSS vers exécution de code déjà décrite, quatre failles XSS stockées qui demandent un accès de niveau Contributeur (donc pertinentes pour les sites qui ouvrent la rédaction à des auteurs invités ou une agence externe), une élévation de privilèges sur les installations multisites, plusieurs fuites d'information, une injection CSS, un contournement de vérification d'adresse e-mail, et une falsification de requête côté serveur (SSRF).

Ce dernier point mérite qu'on s'y arrête même s'il attire moins l'attention que le XSS : une SSRF permet à un attaquant de faire émettre des requêtes réseau depuis le serveur WordPress lui-même, ce qui peut servir de première étape pour sonder un réseau interne auquel le serveur a accès. Le CERT-FR, dans son avis CERTFR-2026-AVI-0979, confirme que ce lot de correctifs couvre à la fois une élévation de privilèges, une atteinte à la confidentialité des données et une SSRF, sans détailler CVE par CVE.

Ce qu'il faut vérifier aujourd'hui

La version du site s'affiche en bas de la colonne de droite du tableau de bord WordPress. En ligne de commande, sur le serveur :

wp core version

Si le résultat est antérieur à 7.0.3, la mise à jour s'impose. La majorité des sites vitrines de PME tournent sur un hébergement mutualisé où la mise à jour du cœur WordPress est automatique par défaut — encore faut-il vérifier qu'elle s'est bien exécutée. Un thème incompatible, une extension qui bloque le processus, ou une automatisation désactivée après un incident passé, et le site reste exposé sans qu'aucun symptôme ne le signale, puisqu'aucune activité d'attaque anormale n'est à chercher ici : il n'y a pas de compromission connue à détecter, seulement un correctif à appliquer avant qu'il y en ait une.

Si le site est confié à un prestataire ou une agence, une question simple suffit : la version 7.0.3 est-elle installée, et sinon, quand le sera-t-elle.