WordPress a publié le 22 septembre la version 7.1.2 de son CMS afin de corriger une vulnérabilité critique référencée CVE-2026-87902. Notée 9,2 sur 10 selon CVSS 4.0, elle concerne la résolution des modèles de pages et peut permettre à un attaquant non authentifié de provoquer l'inclusion d'un fichier PHP local lisible par le serveur. Dans certaines configurations, cette chaîne peut aboutir à une exécution de code à distance (RCE).

La faille a été découverte par le chercheur en sécurité Robert Ressl, qui indique l'avoir signalée à WordPress via HackerOne. Son analyse publiée après la mise à disposition du correctif détaille les conditions nécessaires à l'exploitation ainsi qu'une preuve de concept réalisée en laboratoire. Ressl précise ne pas avoir testé la chaîne d'exploitation sur des sites WordPress de production.

Une inclusion de fichier PHP sans authentification

Le problème se situe dans la fonction get_page_template(), utilisée par WordPress pour déterminer le modèle PHP servant à afficher une page. Selon le chercheur, certaines données issues de la requête peuvent, après plusieurs étapes de traitement et de décodage, être utilisées pour construire un chemin de fichier échappant au répertoire normalement prévu pour les modèles du thème. Un attaquant n'a pas besoin de disposer d'un compte WordPress, d'une session ou d'un jeton d'authentification pour atteindre cette fonctionnalité. La vulnérabilité ne signifie toutefois pas que toute installation de WordPress est directement exploitable. Plusieurs conditions doivent être réunies côté thème et environnement serveur. L'analyse de Robert Ressl montre notamment qu'un thème actif doit présenter une arborescence permettant d'emprunter cette voie de résolution des modèles. Un fichier PHP lisible par le compte utilisé par le serveur web doit également être disponible pour transformer l'inclusion locale en exécution de code.

La possibilité d'exécuter du code ne découle donc pas directement de la seule faille WordPress. Dans son laboratoire, Robert Ressl a notamment utilisé pearcmd.php, un composant de PEAR présent dans certains environnements PHP. Cette chaîne dépend de paramètres et de composants qui ne sont pas systématiquement présents sur les serveurs WordPress. Le chercheur a testé la vulnérabilité sur WordPress 7.0.2 dans des environnements isolés. L'exécution obtenue s'effectuait avec les droits du compte du serveur web, et non avec des privilèges administrateur du système. Il souligne également que ses travaux ne permettent pas d'estimer la proportion de sites WordPress effectivement exposés aux conditions nécessaires à l'exploitation.

Un correctif rétroporté jusqu'à WordPress 4.7

WordPress a intégré le correctif dans la version 7.1.2 et l'a également rétroporté sur les branches anciennes encore concernées par les mises à jour de sécurité. Les versions corrigées s'étendent de 4.7.37 jusqu'à 7.1.2. WordPress 4.6 et les versions antérieures ne reçoivent plus de correctifs de sécurité. Le correctif ne se limite pas à traiter le chemin d'exploitation identifié. WordPress a également ajouté un contrôle destiné à s'assurer que les modèles résolus restent dans les répertoires autorisés. Le changement porte notamment sur le fichier wp-includes/template.php. Le CERT-FR a publié le 23 septembre un avis consacré à cette vulnérabilité et classe le risque comme une exécution de code arbitraire à distance. L'agence recommande d'appliquer les correctifs fournis par WordPress.

La diffusion du correctif a été suivie rapidement par des activités d'exploitation. Selon Patchstack, cité par plusieurs chercheurs et médias spécialisés, les premières tentatives ont été observées quelques heures après la publication de la mise à jour. Des séquences d'attaque ont notamment cherché à déterminer si les conditions nécessaires à l'exploitation étaient réunies avant de tenter d'écrire des fichiers PHP sur les serveurs vulnérables. Pour les administrateurs, WordPress recommande donc d'installer immédiatement la version 7.1.2 ou le correctif correspondant à la branche utilisée. Les mises à jour automatiques peuvent être appliquées sur les installations qui disposent de ce mécanisme. Robert Ressl suggère de vérifier les paramètres PHP et les fichiers accessibles par le compte du serveur web. Ces mesures peuvent réduire certaines voies d'exploitation, mais elles ne remplacent pas l'installation du correctif WordPress.