Contexte de la faille
Le 22 septembre 2026, le projet WordPress/wordpress-develop a publié l’avis de sécurité GHSA-7hp8-65ch-5whp. Il décrit une traversée de répertoire non authentifiée dans la fonction get_page_template(), qui permet à un attaquant d’inclure un fichier .php situé en dehors du répertoire du thème actif. La vulnérabilité touche toutes les versions de WordPress de la branche 4.7 jusqu’à 7.1.1, soit plus de 200 versions, comme le montre la liste exhaustive des versions affectées (4.7.0‑4.7.36, 4.8.0‑4.8.31, …, 7.1.0‑7.1.1).
Mécanisme d’exploitation
L’exploitation repose sur le fait que get_page_template() construit le chemin du fichier de modèle à partir d’un paramètre fourni via l’URL. Si le thème actif possède un répertoire de premier niveau dont le nom commence par page‑ (par exemple page-templates), le résolveur accepte des chemins contenant ../ et inclut le fichier ciblé. Les pré‑conditions requises sont :
• Le thème (parent ou enfant) comporte un répertoire page‑* ; cela concerne les thèmes legacy Twenty Twelve et Twenty Fourteen ainsi que des thèmes tiers populaires comme Neve, Hestia et Sydney.
• Un fichier .php lisible par le compte du serveur web existe sur le système (ex. pearcmd.php utilisé dans la chaîne PEAR→RCE).
• L’option PHP register_argc_argv est activée, condition nécessaire pour que le fichier inclus puisse être exécuté avec les arguments de la ligne de commande.
• L’image officielle Docker php et les configurations cPanel avec PHP antérieur à 8.5 sont concernées, car elles conservent les réglages par défaut.
En combinant ces éléments, un attaquant distant, sans aucune authentification ni interaction utilisateur, peut forcer WordPress à exécuter du code arbitraire, aboutissant à une compromission totale du serveur.
Impact et gravité
Le score CVSS v4 attribué est de 9.2/10, classé « Critical ». Les métriques d’impact indiquent une perte totale de confidentialité, d’intégrité et de disponibilité (confidentialité : High, intégrité : High, disponibilité : High). L’attaque se réalise via le vecteur réseau, avec une complexité faible et aucune exigence de privilèges ou d’interaction utilisateur. Ainsi, un exploit fonctionnel peut être déployé à grande échelle, compromettant potentiellement des millions de sites WordPress.
Mitigation et correctifs
WordPress 7.1.2 introduit le correctif officiel, et le même correctif a été rétro‑porté jusqu’à la branche 4.7, couvrant toutes les versions listées comme vulnérables. Les versions corrigées sont : 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32, 4.7.37. Les administrateurs doivent donc mettre à jour immédiatement vers l’une de ces versions. En complément, il est recommandé :
• D’éviter les répertoires page‑* dans les thèmes personnalisés ou d’utiliser des noms neutres.
• De désactiver register_argc_argv dans php.ini.
• De restreindre les permissions de lecture des fichiers système afin que le compte web ne puisse accéder qu’aux répertoires du thème.
• De sécuriser les images Docker en désactivant les modules inutiles et en appliquant les dernières mises à jour de sécurité.
• De vérifier les configurations cPanel et de mettre à jour PHP au moins à la version 8.5.
En l’absence de correctif, la combinaison d’un thème compatible et d’un fichier PHP accessible constitue une porte d’entrée directe vers l’exécution de code à distance, justifiant la classification critique de la faille.