Les attaquants sont passés de l’analyse des sites WordPress affectés par la vulnérabilité critique CVE-2026-87902 à son exploitation effective pour écrire des fichiers sur le serveur et exécuter des commandes shell lorsqu’ils y accèdent. La société de sécurité Patchstack a observé une forte hausse de l’activité quelques heures après la publication par WordPress du correctif dans la version 7.1.2.
De la reconnaissance à l’exécution de la charge utile
La première activité d’attaque, qui semblait destinée à identifier les sites vulnérables, a commencé moins de cinq heures après la publication du correctif. Selon Patchstack, les premières requêtes malveillantes ont été enregistrées à 17 h 44 UTC le 22 septembre, depuis un petit groupe d’adresses IP ciblant plusieurs sites protégés.
Le lendemain, le trafic associé à la vulnérabilité a été multiplié par dix et comprenait une phase d’écriture de fichiers sur le disque. Certaines requêtes ont tenté d’inclure des fichiers ordinaires du cœur de WordPress, apparemment pour détecter les sites exploitables, avant de passer à l’envoi de charges utiles malveillantes.
Nature de la vulnérabilité et conditions d’exploitation
Le chercheur en sécurité Robert Ressl a découvert une faille non documentée liée au contournement de chemins, qui peut permettre l’exécution de commandes à distance dans certaines conditions. La vulnérabilité permet à un attaquant non authentifié de contraindre la fonction get_page_template() à inclure un fichier PHP local lisible situé en dehors des répertoires du thème actif. L’équipe de sécurité de WordPress lui a attribué une gravité de 9,2 sur 10.
L’accès à l’exécution de commandes nécessite la réunion de conditions précises, notamment la présence, dans le thème parent ou enfant actif, d’un répertoire de niveau supérieur dont le nom commence par page-, ainsi que la présence d’un fichier PHP local lisible par le compte du serveur web. L’alerte officielle cite le fichier pearcmd.php comme exemple lorsque le paramètre register_argc_argv est activé.
L’alerte a également confirmé que l’image PHP officielle utilisée avec Docker est affectée, tout comme la configuration par défaut de cPanel lors de l’utilisation d’une version de PHP antérieure à 8.5.
Que font les attaquants actuellement ?
Patchstack a observé des requêtes utilisant l’outil pearcmd pour passer de la fonction config-show à config-create, ce qui permet d’écrire un fichier à un emplacement choisi par l’attaquant et avec un contenu qu’il contrôle. Certains fichiers visaient uniquement à placer un marqueur confirmant que le serveur était exploitable, mais les chercheurs de la société ont également observé des fichiers contenant une courte balise qui exécute une commande shell à l’ouverture du fichier.
Les fichiers observés ont été placés dans les chemins /tmp et /var/tmp, et portaient des noms tels que wp-pear-rce-flag.php, poc87902.php, luci_<random>.php et zeta_<random>.php. La société n’a pas publié de requête pratique complète, mais elle a indiqué que les tentatives utilisent des séquences de contournement de chemin encodées deux fois dans pagename, avec une valeur page_id valide.
Que faut-il faire ?
WordPress a publié la version 7.1.2 pour corriger CVE-2026-87902, et le correctif a également été rétroporté vers les branches jusqu’à la version 4.7 en raison de la gravité de la vulnérabilité. Les versions antérieures à 4.6 ne bénéficieront pas de ce correctif.
Les administrateurs de sites doivent mettre à jour vers la version 7.1.2 dès que possible, puis examiner les journaux à la recherche de requêtes suspectes et de fichiers PHP inhabituels dans les chemins /tmp et /var/tmp. Patchstack a également mentionné des adresses pouvant être ajoutées aux listes de blocage : 169.58.48.193, 169.58.48.195 et 2001:df1:e8c0::106b.
L’importance de cette évolution tient au fait que le passage de la reconnaissance à l’exploitation effective n’a pris qu’environ une journée, ce qui rend insuffisante la seule surveillance pour les sites dont la mise à jour n’a pas été vérifiée. La possibilité d’exécuter des commandes reste liée aux conditions particulières concernant les thèmes, les fichiers PHP et les paramètres de l’environnement, mais l’activité observée prouve que la vulnérabilité n’est plus un risque théorique.