Des attaquants transforment en quelques heures une faille des modèles WordPress en exécution de code à distance

Une faille critique dans la gestion des modèles de pages de WordPress est déjà exploitée contre des sites exposés. La vulnérabilité, identifiée sous le numéro CVE-2026-87902, permet à des attaquants non authentifiés d’inclure des fichiers PHP lisibles situés en dehors des répertoires des thèmes actifs, dans certaines conditions de déploiement.

Cette faiblesse peut être exploitée pour passer d’une inclusion de fichier local à une exécution de code à distance. Les attaques observées utilisent l’utilitaire PEAR pearcmd.php afin d’écrire du contenu PHP contrôlé par l’attaquant sur les serveurs vulnérables.

Patchstack a détecté des tentatives d’exploitation quelques heures après la divulgation publique. Selon les informations disponibles, la campagne est passée de la reconnaissance aux compromissions actives le 23 septembre. Le trafic malveillant a ensuite dépassé de plus de dix fois son volume initial et s’est étendu à un nombre bien plus important de sites.

La résolution des modèles échappe aux répertoires des thèmes actifs

CVE-2026-87902 est une vulnérabilité de traversée de chemins dans la logique utilisée par WordPress pour sélectionner les modèles de pages. Un attaquant externe peut influencer get_page_template() afin qu’il pointe vers un fichier .php local choisi, lisible par le système, situé en dehors des répertoires attendus du thème enfant ou du thème parent.

L’attaque ne fonctionne pas contre toutes les installations WordPress. Plusieurs conditions doivent être réunies :

• Le nom du répertoire de premier niveau du thème parent ou enfant actif doit commencer par page-.
• Un fichier PHP local approprié doit exister et être lisible par le compte utilisé par le serveur web.
• Le chemin vulnérable de résolution des modèles doit être accessible.
• Le serveur et le thème doivent satisfaire à d’autres prérequis de WordPress pour que l’inclusion aboutisse.

L’exigence concernant le nom du répertoire explique pourquoi la structure du thème est déterminante. Les thèmes considérés comme potentiellement concernés comprennent Twenty Twelve, Twenty Fourteen, Neve, Hestia et Sydney. Leur simple présence ne suffit pas à prouver qu’un site est exploitable ; les administrateurs doivent également évaluer la structure active des répertoires, l’environnement PHP, les permissions et les fichiers locaux disponibles.

D’après les données disponibles, deux niveaux de gravité différents ont été attribués à la vulnérabilité. SecurityWeek fait état d’un score CVSS de 9,2, en citant WordPress et Patchstack. Une autre fiche vérifiée lui attribue un score CVSS de 8,1, avec le vecteur CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

Ces deux évaluations reflètent des conséquences potentiellement graves sur la confidentialité, l’intégrité et la disponibilité. Le vecteur 8.1 tient également compte de la complexité élevée de l’attaque : l’exploitation ne nécessite aucune authentification et est accessible via le réseau, mais elle dépend de plusieurs conditions liées à l’environnement.

PEAR fait le lien entre l’inclusion de fichiers et l’exécution de code

Les attaques observées jusqu’à présent ciblent pearcmd.php, un composant en ligne de commande associé au système de gestion de paquets PEAR de PHP. Sa présence peut fournir aux attaquants un moyen de passer d’une inclusion de fichier PHP local à l’exécution de commandes.

Lorsque l’option PHP register_argc_argv est activée, les données fournies dans la requête peuvent être exposées via des variables liées aux arguments. Les attaquants peuvent exploiter ce comportement conjointement avec l’inclusion de pearcmd.php, en détournant l’utilitaire pour écrire du contenu PHP sur le serveur. L’exécution du fichier ainsi créé achève la chaîne menant à l’exécution de code à distance.

L’opération décrite se déroule en trois étapes :

1. Les attaquants vérifient si une installation WordPress est vulnérable à la traversée de chemins dans les modèles.
2. Ils recherchent pearcmd.php ou tentent de l’inclure.
3. Si les conditions requises sont réunies, ils utilisent les fonctionnalités de PEAR pour créer du code PHP et l’exécuter.

Cette distinction est importante lors de la réponse à incident. Une requête testant les chemins des modèles peut indiquer une activité de balayage, tandis que la création réussie d’un fichier ou l’exécution ultérieure de code PHP signale vraisemblablement une compromission.

L’image Docker officielle de PHP serait affectée par les conditions environnementales concernées. Les configurations cPanel par défaut sont également touchées lorsqu’elles utilisent des versions de PHP antérieures à 8.5. Dans les deux cas, l’exposition réelle dépend encore du thème WordPress et des prérequis du serveur.

L’analyse publique du correctif semble avoir accéléré l’exploitation

Patchstack a estimé que l’encodage utilisé dans les premières charges utiles correspondait étroitement à la modification de code introduite pour corriger la faille. Cela laisse penser que les attaquants ont étudié le correctif rendu public et l’ont rapidement transformé en trafic d’exploitation opérationnel.

Aucun acteur malveillant précis n’a été identifié. Les premières requêtes provenaient d’un petit groupe d’adresses IP, mais aucune adresse, aucun domaine, aucun hachage de fichier, aucun échantillon de charge utile ni aucun autre indicateur atomique n’a été rendu public.

L’activité initiale visait principalement à trouver des installations vulnérables. Le 23 septembre, Patchstack observait des compromissions actives, et non plus seulement des opérations de reconnaissance. Le trafic a ensuite dépassé de plus de dix fois le volume enregistré durant la première soirée et a atteint un ensemble de sites nettement plus vaste.

Des outils d’analyse publics sont également disponibles, ce qui réduit l’effort nécessaire pour identifier les installations présentant des configurations potentiellement vulnérables. Les défenseurs ne peuvent donc pas compter sur le nombre de prérequis pour maintenir le problème dans l’ombre.

WordPress 7.1.2 corrige le chemin vulnérable

WordPress a corrigé le problème dans la version 7.1.2 et a rétroporté la correction dans les branches prises en charge jusqu’à la version 4.7.x. Le numéro de version exact de chaque correctif rétroporté n’est pas disponible.

Les administrateurs doivent mettre à niveau WordPress vers la version 7.1.2 ou installer la version corrigée correspondant à leur branche actuelle. Des modifications de configuration peuvent réduire l’exposition, mais elles ne remplacent pas l’installation du correctif WordPress.

Les vérifications prioritaires doivent notamment porter sur les points suivants :

• Identifier les thèmes parents et enfants actifs dont le nom du répertoire de premier niveau commence par page-.
• Examiner les sites qui utilisent Twenty Twelve, Twenty Fourteen, Neve, Hestia ou Sydney.
• Vérifier si pearcmd.php existe et s’il est lisible par le compte utilisé par le serveur web.
• Vérifier si register_argc_argv est activé et le désactiver ou en restreindre l’usage lorsque cela est possible sur le plan opérationnel.
• Auditer les permissions des fichiers PHP locaux, y compris ceux qui se trouvent en dehors des répertoires des thèmes.
• Examiner les déploiements Docker officiels de PHP et les systèmes cPanel exécutant une version de PHP antérieure à 8.5.

La suppression de l’exposition de PEAR ou la modification de register_argc_argv peut interrompre la chaîne d’exploitation décrite. Ces mesures ne corrigent toutefois pas la traversée de chemins sous-jacente dans les modèles de pages.

Les journaux doivent distinguer le balayage de la compromission effective

Les journaux du serveur web et de WordPress doivent être examinés à la recherche de requêtes inhabituelles impliquant une traversée de chemins dans les modèles de pages, de tentatives de résolution de fichiers situés en dehors des répertoires des thèmes et de références à pearcmd.php.

Les défenseurs doivent également rechercher la séquence décrite dans la campagne observée : un premier test de vulnérabilité, une tentative d’inclusion de PEAR, puis une requête exécutant un fichier PHP nouvellement écrit. Tout fichier PHP inattendu doit faire l’objet d’une investigation immédiate, en particulier lorsque sa création fait suite à des requêtes suspectes de résolution de modèles.

Si les éléments disponibles indiquent que la chaîne a atteint sa dernière étape, les administrateurs doivent considérer l’hôte comme compromis. La réponse doit notamment inclure la conservation des journaux pertinents, l’isolement du système concerné lorsque cela est nécessaire et son examen à la recherche des éléments suivants :

• Fichiers PHP nouvellement écrits ou modifiés.
• Webshells ou autres mécanismes de persistance.
• Commandes exécutées avec les privilèges du compte utilisé par le serveur web.
• Accès à des secrets ou identifiants WordPress.
• Connexions à d’autres services internes.
• Signes de vol d’identifiants ou de déplacement latéral.

La réinstallation du seul cœur WordPress ne suffit pas nécessairement à supprimer les fichiers créés ailleurs sur l’hôte.

Le statut CISA KEV reste inconnu

Aucun statut confirmé dans le catalogue CISA Known Exploited Vulnerabilities ni aucune échéance fédérale de remédiation n’est disponible pour CVE-2026-87902. Aucun indicateur d’utilisation par des opérateurs de rançongiciels n’a non plus été signalé.

L’absence de ces informations dans le catalogue ne change rien aux éléments opérationnels disponibles : l’exploitation a été observée quelques heures après la divulgation et des compromissions actives ont été signalées dès le 23 septembre. Les administrateurs doivent prioriser l’application du correctif en fonction de cette activité, sans attendre une éventuelle inscription dans le catalogue KEV.