WordPress a publié le 22 septembre 2026 la version 7.1.2, une mise à jour de sécurité exclusive qui corrige une vulnérabilité critique référencée CVE-2026-87902. Le défaut touche la résolution des templates de page et peut, sous certaines conditions, permettre l’exécution de code à distance sans authentification. Un correctif a été rétroporté jusqu’à la branche 4.7, et un code de démonstration est déjà public : la mise à jour ne se discute pas.
Ce que corrige la version 7.1.2
La faille réside dans la fonction get_page_template(), chargée de résoudre le fichier de template à charger pour une page donnée. Un attaquant non authentifié peut, en manipulant les paramètres de résolution, amener WordPress à inclure un fichier PHP lisible situé en dehors du répertoire du thème actif. Selon la configuration du serveur et le thème actif, cette inclusion locale de fichier peut déboucher sur une exécution de code à distance.
La vulnérabilité a été signalée par le chercheur Robert Ressl et documentée sous l’identifiant GHSA-7hp8-65ch-5whp. Elle est notée 8,1 en CVSS v3.1 et 9,2 (critique) en CVSS v4.0, l’écart s’expliquant par la prise en compte, dans la version 4, de la facilité d’exploitation sans interaction utilisateur.
| Branche | Version corrigée | Statut avant correctif |
|---|---|---|
| 7.1.x | 7.1.2 | Vulnérable de 7.1.0 à 7.1.1 |
| 7.0.x | 7.0.6 | Vulnérable de 7.0.0 à 7.0.5 |
| 6.9.x | 6.9.9 | Vulnérable sur les versions antérieures |
| 4.7.x et branches historiques | 4.7.37 et équivalents | Correctif rétroporté sur toutes les branches maintenues |
Un exploit déjà documenté publiquement
Point de vigilance supplémentaire : un dépôt de démonstration a été publié quasiment en même temps que le correctif, ce qui raccourcit la fenêtre entre divulgation et exploitation réelle. Mail Studio ne relaie ici aucun code ni aucune étape d’exploitation ; l’enjeu est la rapidité de mise à jour, pas la compréhension technique de l’attaque.
Sous certaines conditions de serveur et de thème actif, l’inclusion locale de fichier documentée par CVE-2026-87902 peut déboucher sur une exécution de code à distance sans authentification.
Comment vérifier et forcer la mise à jour
La plupart des installations avec mises à jour automatiques activées ont déjà basculé en arrière-plan. Pour les sites gérés manuellement ou dont l’hébergeur désactive les mises à jour mineures automatiques, un contrôle explicite s’impose.
# Vérifier la version installée
wp core version
# Forcer la mise à jour vers la dernière version mineure
wp core update
# Confirmer après coup
wp core versionSans accès WP-CLI, le tableau de bord (Mises à jour) affiche la même invite et applique le correctif en un clic. Un redémarrage du cache objet ou du proxy front (Varnish, Cloudflare) après la mise à jour évite de resservir une réponse générée par le code vulnérable.
Un correctif backporté jusqu’à la branche 4.7 signale un défaut présent dans le cœur depuis longtemps. Les sites sous des versions très anciennes, parfois maintenus sans surveillance active, sont les plus exposés : c’est l’occasion de vérifier qu’aucune installation oubliée ne tourne encore sans mise à jour automatique.
Les sites qui exposent des thèmes tiers peu maintenus, ou qui autorisent la lecture de fichiers PHP en dehors du répertoire actif via une configuration serveur permissive, méritent une vérification manuelle même après la mise à jour : le correctif traite la cause côté cœur, mais un socle de durcissement minimal réduit la surface d’attaque en profondeur, notamment sur les permissions de fichiers et les restrictions d’exécution PHP par répertoire.
Pour les sites auto-hébergés
Les installations pilotées via un panneau comme CloudPanel n’appliquent pas toujours les mises à jour mineures WordPress par défaut, à la différence d’un hébergement mutualisé géré. Sur ce type d’infrastructure, décrite dans le guide sur l’auto-hébergement WordPress avec CloudPanel, la vérification manuelle décrite plus haut est la seule garantie de couverture rapide.
Ce qu’il faut retenir
WordPress 7.1.2 corrige une faille critique d’inclusion de fichier local, exploitable sans authentification sous certaines conditions, avec un code de démonstration déjà public. Le correctif remonte jusqu’à la branche 4.7. La priorité immédiate est la mise à jour ; le durcissement du socle serveur reste la défense en profondeur qui limite l’impact d’une prochaine faille de la même famille.
Une divulgation accompagnée d’un dépôt de preuve de concept quasiment simultané n’est plus une exception, c’est devenu la norme sur les failles WordPress à fort potentiel. J’ai vu trop de sites clients rester vulnérables plusieurs semaines parce que la mise à jour automatique avait été désactivée « temporairement » pour un test, puis oubliée. Un cron de vérification hebdomadaire de wp core version face au flux RSS des releases de sécurité coûte dix minutes à mettre en place et évite ce genre de sueurs froides — Simon Janvier.
Pour aller plus loin : l’avis de sécurité complet est disponible sur GitHub Security Advisories (GHSA-7hp8-65ch-5whp) et l’annonce officielle sur wordpress.org/news.
