WordPress CVE-2026-87902 exploitée pour exécuter du code

Les attaquants ne se contentent plus de rechercher les sites WordPress vulnérables à la CVE-2026-87902. Ils exploitent désormais la faille pour déposer des fichiers qui exécutent des commandes shell dès qu'on y accède, selon Patchstack, société spécialisée dans la sécurité de WordPress.

La vulnérabilité a été corrigée dans WordPress 7.1.2. Les premiers scans ont commencé moins de cinq heures après la publication de cette version. Depuis, le trafic malveillant a été multiplié par dix, et les attaquants tentent maintenant de livrer des charges utiles.

Patchstack indique avoir observé les premières requêtes malveillantes le 22 septembre à 17 h 44 UTC. Elles provenaient d'un petit groupe d'adresses IP et visaient plusieurs sites protégés par l'entreprise.

Une faille de traversée de répertoires jugée critique

C'est le chercheur en sécurité Robert Ressl qui a découvert le problème. Il s'agit d'une faille de traversée de répertoires (path traversal) qui ne nécessite aucune authentification et peut, sous certaines conditions, mener à une exécution de code à distance (RCE). Ce type de faille permet à un attaquant d'atteindre des fichiers situés en dehors des répertoires qu'une application est censée utiliser.

L'équipe de sécurité de WordPress a classé la CVE-2026-87902 comme critique, avec un score de 9,2 sur 10.

D'après le bulletin officiel, un attaquant non authentifié peut forcer la résolution des modèles de page dans get_page_template() à inclure un fichier .php local lisible de son choix, même si ce fichier se trouve en dehors des répertoires du thème actif.

L'exécution de code n'est pas possible sur tous les sites. Plusieurs conditions doivent être réunies :

• Le thème parent ou enfant actif doit contenir, à sa racine, un répertoire dont le nom commence par page-, comme page-templates.
• L'attaquant doit cibler un fichier .php local qui existe.
• Le compte du serveur web doit pouvoir lire ce fichier.

Le bulletin cite pearcmd.php comme exemple de fichier exploitable lorsque le paramètre PHP register_argc_argv est activé. Il désigne aussi deux configurations courantes comme concernées : l'image PHP officielle pour Docker, et la configuration par défaut de cPanel avec une version de PHP antérieure à 8.5. cPanel est un panneau de contrôle d'hébergement web très répandu.

Le correctif a été livré avec WordPress 7.1.2. Vu la gravité de la faille, l'équipe WordPress l'a également rétroporté sur toutes les branches jusqu'à la 4.7. Selon le rapport, les versions antérieures à la 4.6 ne recevront pas de correctif.

De la reconnaissance à l'écriture de fichiers

Selon Patchstack, le trafic initial relevait de la reconnaissance. Les attaquants tentaient d'inclure des fichiers ordinaires du cœur de WordPress, très probablement pour repérer les sites vulnérables.

La situation a changé le 23 septembre. Les chercheurs ont vu le trafic lié à la faille décupler, avec désormais une étape qui écrit des fichiers sur le disque.

« La troisième étape remplace config-show par config-create, que pearcmd utilise sans broncher pour écrire un fichier là où on le lui demande, avec un contenu contrôlé par l'attaquant », explique Patchstack.

Toutes les charges utiles ne sont pas nuisibles. Certaines se contentent d'écrire une chaîne qui signale que l'hôte est exploitable. D'autres, en revanche, « écrivent une courte balise qui exécute une commande shell lorsqu'on y accède », ce que les chercheurs considèrent comme un signe d'intention malveillante.

Les fichiers déposés atterrissent dans /tmp et /var/tmp. Parmi les noms de fichiers observés :

• wp-pear-rce-flag.php
• poc87902.php
• luci_.php
• zeta_.php

Patchstack n'a pas publié de requête fonctionnelle. L'entreprise précise toutefois que les sondes utilisent des séquences de traversée doublement encodées dans le paramètre pagename, accompagnées d'un page_id valide.

Elle recommande de bloquer trois adresses sources : 169.58.48.193, 169.58.48.195 et 2001:df1:e8c0::106b.

Les administrateurs doivent passer à WordPress 7.1.2 au plus vite. Ils doivent aussi examiner leurs journaux à la recherche de signes d'exploitation, notamment des fichiers .php inattendus dans les répertoires temporaires mentionnés plus haut.

Notre analyse

Le principal avertissement, c'est le calendrier. Les sondages ont commencé quelques heures après le correctif, et la livraison de charges utiles environ un jour plus tard. Cela laisse penser que les attaquants lisent les bulletins de sécurité aussi attentivement que les défenseurs, sinon davantage. Cela s'inscrit dans une tendance que nous avons décrite à plusieurs reprises ce mois-ci. La faille RCE du VPN de Check Point et la faille d'injection SQL de Roundcube ont toutes deux été exploitées peu après la mise à disposition des correctifs.

Sur le papier, les conditions d'une RCE sont restreintes. Mais le fait que l'image PHP officielle pour Docker et les configurations cPanel par défaut soient concernées signifie que de nombreux environnements d'hébergement ordinaires pourraient remplir ces conditions. Les sites bloqués sur de très anciennes versions de WordPress, sans correctif rétroporté, sont les plus exposés.

Il faudra aussi surveiller si les fichiers « marqueurs » annoncent des campagnes de plus grande ampleur. Des listes d'hôtes dont la vulnérabilité est confirmée sont précieuses pour quiconque prépare une exploitation de masse. D'autres failles ont déjà suivi ce chemin, comme on l'a vu avec la faille TeamCity désormais utilisée par des gangs de rançongiciels. Appliquer rapidement le correctif et vérifier les répertoires temporaires apparaît aujourd'hui comme l'option la plus sûre.