CVE-2026-87902 : Flaw critique dans le noyau de WordPress permet une RCE non authentifiée sous certaines conditions

WordPress a publié une mise à jour de sécurité d’urgence traitant d’une vulnérabilité critique dans son logiciel Core qui permet à un attaquant non authentifié de charger des fichiers PHP locaux arbitraires et, dans des conditions spécifiques de serveur et de thème, d’atteindre une exécution de code à distance. Suivi sous CVE-2026-87902, la vulnérabilité affecte les versions de WordPress allant de la 4.7.0 à la 7.1.1 et a un score CVSS 4.0 de 9.2.

La faille réside dans la résolution du template de page de WordPress. Un attaquant peut manipuler la valeur que WordPress utilise lors de la sélection d’un modèle de page et provoquer l’inclusion par get_page_template() d’un fichier PHP lisible en dehors des répertoires du thème actif. Aucun compte WordPress, cookie d’authentification, interaction d’administrateur ou plugin vulnérable n’est requis pour l’attaque sous-jacente d’inclusion de fichier.

L’exécution de code à distance est conditionnelle plutôt qu’universelle. Le thème actif doit contenir une structure de répertoires compatible et le serveur doit exposer un fichier PHP lisible approprié qui peut être abusé lorsqu’il est inclus. L’attaque démontrée publiquement a utilisé pearcmd.php de PEAR dans un environnement où le paramètre register_argc_argv de PHP était activé.

WordPress a publié la version 7.1.2 le 22 septembre 2026 spécifiquement pour traiter la vulnérabilité et a rétroporté les correctifs sur les branches de sécurité maintenues jusqu’à WordPress 4.7. Les administrateurs de site sont fortement conseillés de mettre à jour immédiatement.

Contacter les ventes

Analyse CVE-2026-87902

La vulnérabilité trouve son origine dans la façon dont le Core de WordPress résout les modèles pour les pages. Lorsqu’un visiteur demande une page, WordPress construit une liste de noms de fichiers de modèles potentiels et recherche le fichier correspondant dans le thème actif.

Dans les versions vulnérables, les données contrôlées par l’attaquant utilisées lors de ce processus ne sont pas suffisamment contraintes avant d’être intégrées dans le chemin du modèle de page. Une requête conçue peut donc introduire des séquences de traversée de répertoire et amener WordPress à résoudre un fichier PHP se trouvant en dehors des répertoires du thème actif attendu.

La clé détails pour CVE-2026-87902 sont que la primitive de base est l’inclusion de fichiers locaux et non l’exécution de code arbitraire inconditionnelle. WordPress décrit officiellement le problème comme permettant à un attaquant non authentifié de faire inclure par la résolution de modèles de page un fichier .php local lisible choisi en dehors des répertoires de thèmes. L’exécution de code à distance devient possible uniquement lorsque des prérequis environnementaux supplémentaires sont satisfaits.

Un thème vulnérable doit contenir un répertoire de niveau supérieur dont le nom commence par page-, tel que :

page-templates

L’avis de WordPress identifie les thèmes hérités Twenty Twelve et Twenty Fourteen parmi ceux répondant à cette exigence structurelle. Des thèmes tiers populaires tels que Neve, Hestia et Sydney peuvent également contenir des mises en page de répertoires compatibles.

Une seconde condition est que l’attaquant doit identifier un fichier PHP local lisible par le compte du serveur web qui produit un comportement utile lorsqu’il est inclus.

Le chercheur en sécurité Robert Ressl a démontré le chemin d’exécution de code à distance en utilisant un composant PEAR appelé pearcmd.php. Pour que cette technique fonctionne, l’option register_argc_argv de PHP doit également être activée. L’image Docker officielle de PHP peut répondre aux conditions pertinentes, tandis que les configurations traditionnelles de cPanel utilisant des versions de PHP avant la 8.5 peuvent également exposer l’environnement requis.

Cette distinction est importante car toutes les installations WordPress vulnérables ne peuvent pas être immédiatement exploitées pour l’exécution de code arbitraire. Un site peut contenir le code Core vulnérable tout en manquant de la structure de thème ou de l’environnement PHP requis par la chaîne d’attaque démontrée.

Néanmoins, la primitive d’inclusion de fichier local en elle-même franchit une barrière de sécurité importante et ne nécessite aucune authentification ou interaction utilisateur.

CVE-2026-87902 affecte WordPress Core de la version 4.7.0 à 7.1.1. L’avis officiel liste les branches vulnérables individuellement, y compris :

• WordPress 7.1.0–7.1.1
• WordPress 7.0.0–7.0.5
• WordPress 6.9.0–6.9.8
• WordPress 6.8.0–6.8.9
• WordPress 6.7.0–6.7.8
• WordPress 6.6.0–6.6.8
• Toutes les branches affectées correspondantes jusqu’à WordPress 4.7.36

WordPress 7.1.1, publié cinq jours plus tôt seulement comme une mise à jour de sécurité, reste vulnérable à ce problème distinct.

La vulnérabilité a été découverte par le chercheur en sécurité Robert Ressl et signalée de manière privée via le programme HackerOne de WordPress le 20 juillet 2026. WordPress a accusé réception du rapport le 21 juillet et a informé le chercheur le 15 septembre qu’un correctif était prévu. Le patch et l’avis public ont été publiés le 22 septembre.

WordPress classe la vulnérabilité comme Critique avec un score CVSS 4.0 de 9.2. Son vecteur reflète une attaque accessible via le réseau avec une faible complexité, ne nécessitant aucun privilège et aucune interaction utilisateur, tout en enregistrant que des conditions d’attaque supplémentaires doivent être présentes avant que l’impact maximal démontré ne soit possible.

Un PoC public CVE-2026-87902 a été publié par le chercheur en même temps que la divulgation. La preuve de concept inclut un laboratoire local reproductible et démontre le chemin de la traversée de template non authentifiée à l’inclusion de PHP local et l’exécution de code à distance conditionnelle. Le chercheur a testé l’exploit contre WordPress 7.0.2 dans des environnements isolés et ne l’a pas testé sur des sites de production en direct.

L’exécution réussie dans l’environnement démontré s’est faite avec les privilèges du compte PHP/serveur web, identifié comme www-data, plutôt que de fournir automatiquement des privilèges root du système d’exploitation. L’impact pratique dépend donc en partie des permissions assignées au processus du serveur web.

Un attaquant qui parvient à exécuter du code PHP pourrait potentiellement déployer une web shell, modifier les fichiers du site web, voler les données de configuration et les identifiants de la base de données de WordPress, créer de la persistance, altérer le contenu, rediriger les visiteurs ou utiliser le site compromis comme un point d’ancrage initial pour d’autres attaques. Ce sont des conséquences potentielles post-exploitation plutôt que des activités actuellement attribuées à une campagne réelle CVE-2026-87902.

Au moment de la divulgation originale du 22 septembre, aucune exploitation dans la nature n’avait été signalée et le dossier d’enrichissement de la CISA répertoriait l’exploitation comme aucune.

Cependant, le paysage de la menace a commencé à changer dans les heures qui ont suivi la divulgation. Patchstack a signalé avoir détecté des tentatives de sondage vers 17h44 UTC le 22 septembre, moins de cinq heures après la disponibilité de WordPress 7.1.2. Les requêtes observées correspondaient au codage abordé par le correctif, suggérant une analyse rapide de la différence de sécurité.

Il est important de noter que Patchstack a caractérisé le trafic observé comme des sondages plutôt qu’une livraison réussie de charge utile. Les requêtes tentaient d’inclure des fichiers PHP Core WordPress ordinaires et ne démontraient pas une exécution de code contrôlé par l’attaquant. Au 23 septembre, les preuves disponibles publiquement soutiennent donc une reconnaissance active, mais pas une exploitation réussie confirmée dans des environnements de production.

Il n’y a actuellement aucune IoCs CVE-2026-87902 spécifiques à une campagne telles que des domaines malveillants, des hachages de fichiers, des familles de logiciels malveillants ou un ensemble d’infrastructures d’attaquants définitif. Les défenseurs devraient plutôt se concentrer sur les modèles de requêtes HTTP associés à une traversée anormale de modèle de page et une activité de système de fichiers ou PHP qui en résulte.

Les signes d’avertissement potentiels incluent :

• Requêtes contenant des séquences de traversée de répertoires encodées ou répétées
• Requêtes tentant de manipuler la sélection du modèle de page
• Modèles d’accès impliquant des noms de fichiers PHP locaux inattendus
• Nouveaux fichiers PHP apparaissant dans les répertoires WordPress inscriptibles
• Processus enfants inattendus lancés par le compte PHP ou serveur web
• Connexions sortantes inexpliquées provenant des travailleurs PHP
• Nouveaux comptes administrateur ou modifications non autorisées au contenu WordPress
• Modifications des thèmes, plugins ou fichiers Core après des requêtes HTTP suspectes

Étant donné que les informations sur les exploits publics sont désormais disponibles, les organisations devraient s’attendre à des analyses plus larges et au développement automatique d’exploits bien que les compromissions réussies dans le monde réel n’aient pas encore été publiquement confirmées.

Atténuation CVE-2026-87902

La principale mesure corrective consiste à installer immédiatement une version de WordPress corrigée. WordPress indique que la dernière branche, WordPress 7.1.2, contient le correctif de sécurité, et des versions corrigées ont également été créées pour les branches plus anciennes.

Les versions corrigées officielles incluent :

• 7.1 → 7.1.2
• 7.0 → 7.0.6
• 6.9 → 6.9.9
• 6.8 → 6.8.10
• 6.7 → 6.7.9
• 6.6 → 6.6.9
• 6.5 → 6.5.12
• 6.4 → 6.4.12
• 6.3 → 6.3.12
• 6.2 → 6.2.13
• 6.1 → 6.1.14
• 6.0 → 6.0.16

Les rétroportages de sécurité se poursuivent avec WordPress 4.7.37. WordPress souligne cependant que seule la dernière version de WordPress est activement supportée, donc la mise à niveau vers la branche actuelle est préférable lorsque c’est faisable opérationnellement.

Les sites qui prennent en charge les mises à jour automatiques en arrière-plan devraient commencer à recevoir automatiquement la mise à jour de sécurité. Les administrateurs peuvent vérifier et installer manuellement la mise à jour via :

Tableau de bord WordPress → Mises à jour → Mettre à jour maintenant

WordPress ne fournit pas de solution de contournement complète qui remplace l’installation de la mise à jour de sécurité.

La détection CVE-2026-87902 devrait commencer par l’identification de toutes les installations WordPress exécutant des versions Core 7.1.1 ou antérieures et ensuite déterminer si leur thème parent ou enfant actif contient un répertoire de niveau supérieur commençant par page-.

Les administrateurs devraient également déterminer si PHP fonctionne avec :

register_argc_argv = On

et si des composants PEAR lisibles comme pearcmd.php ou d’autres points d’entrée PHP locaux potentiellement utiles existent sur le serveur. Ces vérifications aident à évaluer l’exposition aux techniques RCE connues mais ne déterminent pas si la faille WordPress sous-jacente existe.

To Pour détecter les tentatives d’exploitation ou de sondage CVE-2026-87902, les équipes de sécurité devraient inspecter les télémetries du serveur web, WAF, proxy inverse, PHP et WordPress pour :

• des modèles de traversée ../ ou équivalent codés dans les requêtes frontend
• Des requêtes qui tentent de manipuler la résolution des modèles de page de WordPress
• Références inhabituelles à des fichiers .php en dehors des répertoires de thème actifs
• Requêtes tentant d’atteindre des composants PHP liés à PEAR
• Explosions de requêtes de traversée similaires d’une seule source
• Travailleurs PHP lançant de manière inattendue des commandes shell ou des utilitaires système
• Nouveaux fichiers PHP ou web shells apparaissant après des requêtes suspectes
• Changements inattendus à wp-config.php, thèmes, plugins ou uploads
• Comptes administrateur WordPress nouvellement créés
• Trafic sortant suspect origine du serveur web

Les analyses observées par Patchstack montrent que les sites WordPress accessibles depuis Internet peuvent déjà recevoir des sondages spécifiques aux vulnérabilités, rendant les télémetries web et WAF particulièrement précieuses pour une enquête rétrospective.

Les administrateurs incapables de patcher immédiatement peuvent réduire l’exposition à la chaîne d’exécution démontrée basée sur PEAR en désactivant register_argc_argv pour les requêtes web lorsqu’il n’est pas nécessaire et en supprimant les composants PEAR lisibles par le web non utilisés. Robert Ressl insiste sur le fait qu’il s’agit de mesures de durcissement uniquement ; elles ne corrigent pas la vulnérabilité WordPress sous-jacente.

Les organisations peuvent également réduire l’impact potentiel post-exploitation en s’assurant que le compte PHP/serveur web suit les principes du moindre privilège. Il ne devrait pas avoir d’accès en écriture inutile aux répertoires système ou aux fichiers d’application sensibles.

Les sites qui étaient accessibles depuis Internet avant la mise à niveau devraient être examinés pour rechercher des requêtes suspectes débutant autour de la divulgation publique du 22 septembre, d’autant plus que du matériel de PoC public est devenu disponible au même moment et que le sondage a suivi dans les heures qui ont suivi.

Si une exploitation suspecte est identifiée, les administrateurs devraient conserver les journaux pertinents et effectuer un examen complet de l’intégrité de :

• fichiers Core de WordPress
• Thèmes actifs et inactifs
• Plugins
• Le répertoire des uploads
• wp-config.php
• Configuration du serveur web
• Tâches programmées et entrées cron
• Les comptes administrateur de WordPress
• Les processus PHP et les fichiers récemment créés

Les mots de passe de base de données potentiellement exposés, les clés API, les secrets d’application ou d’autres identifiants stockés dans des fichiers lisibles devraient être tournés si l’enquête indique qu’un attaquant a réussi une inclusion de fichier local ou une exécution de code.

La priorité immédiate reste de mettre à jour WordPress lui-même. Les modifications de thème, la désactivation de PEAR ou la modification des paramètres PHP peuvent réduire certains chemins d’exploitation mais ne doivent pas être considérées comme des substituts à la mise à jour de sécurité officielle.