À peine le temps de terminer les mises à jour vers WordPress 7.1.1 qu’une nouvelle version de sécurité arrive.
Et cette fois, la recommandation de mise à jour mérite d’être prise au sérieux.
Le 22 septembre 2026, WordPress a publié la version 7.1.2 afin de corriger une vulnérabilité classée critique, référencée CVE-2026-87902. Le bulletin officiel indique qu’un attaquant non authentifié peut, sous certaines conditions, détourner la résolution des templates de pages pour provoquer l’inclusion d’un fichier PHP local. Lorsque plusieurs prérequis sont réunis, cette faille peut aller jusqu’à une exécution de code à distance, ou RCE.
Autrement dit : contrairement à de nombreuses vulnérabilités WordPress nécessitant déjà un compte ou des privilèges particuliers, l’attaque peut ici commencer sans authentification.
Mais cela ne signifie pas pour autant que chaque site WordPress non mis à jour est immédiatement exploitable.
Et c’est précisément là que le sujet devient intéressant.
Sommaire
- Que corrige WordPress 7.1.2 ?
- Pourquoi cette vulnérabilité est-elle classée critique ?
- Tous les sites WordPress sont-ils réellement exploitables ?
- Quels thèmes et environnements augmentent le risque ?
- WordPress 7.1.1 est-il encore vulnérable ?
- Les anciennes versions de WordPress sont-elles corrigées ?
- Que faut-il faire maintenant ?
- Pourquoi une mise à jour récente ne garantit jamais la sécurité
- Que retenir de cet article ?
Que corrige WordPress 7.1.2 ?
La vulnérabilité se situe dans le mécanisme utilisé par WordPress pour déterminer le template PHP à charger pour afficher une page.
Le bulletin de sécurité officiel explique qu’un attaquant non authentifié peut, dans certaines configurations, manipuler cette résolution afin que WordPress tente de charger un fichier PHP local lisible situé en dehors des répertoires du thème actif.
Il s’agit donc d’un problème de path traversal associé au mécanisme d’inclusion des templates.
La vulnérabilité est identifiée sous :
CVE-2026-87902
et
GHSA-7hp8-65ch-5whp.
Le score CVSS v4 publié dans l’advisory atteint 9,2/10, soit un niveau critique.
Le fichier corrigé par WordPress 7.1.2 est notamment wp-includes/template.php.
Pourquoi cette vulnérabilité est-elle classée critique ?
Deux éléments expliquent principalement la sévérité.
Le premier est l’absence d’authentification.
L’attaquant n’a pas nécessairement besoin d’être administrateur, éditeur, abonné… ni même d’avoir un compte.
Le second est la conséquence potentielle de l’exploitation.
Lorsque l’environnement du serveur et le thème actif répondent à certaines conditions, l’inclusion d’un fichier PHP local peut être transformée en exécution de code à distance.
Une RCE représente l’une des situations les plus sérieuses pour une application Web : elle peut permettre à un attaquant d’exécuter du code sur le serveur avec les droits dont dispose le processus PHP.
Le scénario n’est cependant pas universel.
Et cette nuance est essentielle.
Tous les sites WordPress sont-ils réellement exploitables ?
Non.
Le fait qu’une version de WordPress soit vulnérable ne signifie pas que toutes les installations utilisant cette version permettent d’aller jusqu’à l’exécution de code.
L’advisory WordPress identifie plusieurs préconditions.
Le thème parent ou enfant actif doit notamment contenir, à sa racine, un répertoire dont le nom commence par page-, par exemple :
page-templates
Il faut également qu’un fichier PHP exploitable soit présent localement et lisible par le compte utilisé par le serveur Web.
Pour parvenir jusqu’à une RCE, d’autres caractéristiques de l’environnement PHP peuvent ensuite être nécessaires.
Il serait donc excessif d’affirmer :
« Tous les WordPress antérieurs à 7.1.2 peuvent être piratés à distance immédiatement. »
En revanche, toutes les versions concernées contiennent bien la vulnérabilité dans le Core.
Et puisqu’une mise à jour officielle existe, la question de savoir si son propre environnement remplit exactement les conditions d’exploitation devient assez secondaire.
Le correctif doit être appliqué.
Quels thèmes et environnements augmentent le risque ?
Le bulletin officiel fournit plusieurs exemples particulièrement intéressants.
Parmi les thèmes répondant à la condition du répertoire page-*, WordPress mentionne notamment les anciens thèmes officiels Twenty Twelve et Twenty Fourteen, ainsi que des thèmes tiers tels que Neve, Hestia et Sydney.
Cela ne signifie pas que l’installation de l’un de ces thèmes suffit à compromettre un site.
Elle satisfait simplement l’une des conditions nécessaires à l’exploitation décrite.
Concernant l’environnement serveur, l’advisory cite notamment une chaîne possible utilisant pearcmd.php lorsque register_argc_argv est activé.
La configuration est notamment rencontrée dans l’image PHP officielle pour Docker et, selon l’advisory, dans certaines configurations cPanel utilisant des versions de PHP antérieures à 8.5.
C’est un bon exemple de la difficulté à évaluer une vulnérabilité uniquement à partir du numéro de version d’un CMS.
Le Core, le thème et le serveur participent ensemble à la surface d’attaque.
WordPress 7.1.1 est-il encore vulnérable ?
Oui.
Et c’est probablement l’information la plus importante pour les administrateurs ayant effectué leurs mises à jour ces derniers jours.
WordPress 7.1.1 est explicitement répertorié parmi les versions affectées par CVE-2026-87902.
Or cette version n’est pas ancienne.
Elle est sortie le 17 septembre 2026, soit seulement cinq jours avant WordPress 7.1.2.
La 7.1.1 constituait elle-même une importante version de maintenance et de sécurité comprenant 11 correctifs de sécurité, 17 corrections du Core et 19 corrections du Block Editor.
Un site mis à jour consciencieusement la semaine dernière peut donc déjà nécessiter une nouvelle intervention.
Ce n’est pas un dysfonctionnement du processus de sécurité.
C’est précisément son fonctionnement : une vulnérabilité découverte et corrigée entraîne une nouvelle version.
Les anciennes versions de WordPress sont-elles corrigées ?
La faille ne concerne pas uniquement la branche 7.1.
L’advisory officiel répertorie des versions vulnérables remontant jusqu’à WordPress 4.7.
WordPress a donc rétroporté le correctif sur les branches encore éligibles aux mises à jour de sécurité.
Par exemple :
- WordPress 7.1 → 7.1.2
- WordPress 7.0 → 7.0.6
- WordPress 6.9 → 6.9.9
- WordPress 6.8 → 6.8.10
- WordPress 6.7 → 6.7.9
et ainsi de suite jusqu’à WordPress 4.7.37.
Attention toutefois à ne pas interpréter ce rétroportage comme une invitation à conserver éternellement un WordPress 5.x en production.
WordPress rappelle lui-même que seule la version la plus récente est activement supportée, même si certains correctifs de sécurité sont fournis par courtoisie aux anciennes branches.
Que faut-il faire maintenant ?
Pour un site WordPress en production, la priorité est simple :
appliquer la version corrigée correspondant à sa branche.
Pour un site en WordPress 7.1.1, cela signifie passer en 7.1.2.
WordPress recommande officiellement une mise à jour immédiate. Les installations compatibles avec les mises à jour automatiques en arrière-plan peuvent recevoir le correctif automatiquement.
Sur un site professionnel, une procédure raisonnable reste néanmoins :
sauvegarde ;
mise à jour ;
vidage éventuel des caches ;
contrôle du front-office ;
contrôle du back-office ;
test des fonctionnalités critiques ;
vérification des logs et outils de supervision.
Pour un WooCommerce, on ajoutera évidemment au minimum le panier, le checkout et le paiement.
L’advisory suggère également plusieurs mesures de défense en profondeur côté serveur, mais elles ne remplacent pas la mise à jour du Core.
Pourquoi une mise à jour récente ne garantit jamais la sécurité
Le timing de cette vulnérabilité constitue presque une petite leçon de maintenance à lui seul.
17 septembre :
WordPress 7.1.1, avec 11 correctifs de sécurité.
22 septembre :
WordPress 7.1.2, avec un correctif critique supplémentaire.
Un site marqué « à jour » lundi ne l’est donc plus nécessairement mardi.
Même logique avec les extensions, les thèmes, les bibliothèques JavaScript ou les services externes utilisés par un site.
La sécurité Web n’est pas un état que l’on atteint une fois.
C’est un processus de surveillance et de maintenance continue.
Et l’actualité du deuxième article du jour va justement nous en donner une démonstration assez spectaculaire.
Que retenir de cet article ?
- WordPress 7.1.2 a été publié le 22 septembre 2026 pour corriger une vulnérabilité critique.
- La faille est référencée CVE-2026-87902 et obtient un score CVSS v4 de 9,2/10.
- Elle peut être déclenchée par un attaquant non authentifié.
- Elle permet sous certaines conditions l’inclusion d’un fichier PHP local et peut conduire à une exécution de code à distance.
- Toutes les installations vulnérables ne réunissent pas nécessairement les conditions permettant une RCE.
- WordPress 7.1.1 est concerné, malgré sa publication seulement cinq jours auparavant.
- Des correctifs ont été rétroportés jusqu’aux branches WordPress 4.7.
- WordPress recommande une mise à jour immédiate.
Sources
WordPress — WordPress 7.1.2 Release
WordPress / GitHub — CVE-2026-87902 / GHSA-7hp8-65ch-5whp
WordPress — Documentation de la version 7.1.2
WordPress — WordPress 7.1.1 Maintenance and Security Release
0 commentaires