tc4dy/cve-2026-87902-toolkitBoîte à outils WordPress CVE-2026-87902 LFI-to-RCE avec une chaîne d'exploitation weaponisée (PEAR RCE, webshell, création d'admin, loot) et une version SafeChecker non intrusive ainsi qu'un auditeur de risques.
USAGE ÉTHIQUE UNIQUEMENT – TESTS DE SÉCURITÉ AUTORISÉS Ce dépôt fournit des outils destinés exclusivement aux professionnels de la sécurité autorisés, aux blue teams et aux testeurs d'intrusion. Tout accès non autorisé à des systèmes informatiques est illégal en vertu du CFAA (États-Unis), du Computer Misuse Act (Royaume-Uni), du TCK 243/244 (Turquie) et de lois similaires dans le monde entier.
CVE‑2026‑87902 est une vulnérabilité critique de traversée de chemin et d'inclusion locale de fichier (LFI) non authentifiée dans WordPress Core (versions 4.7.0 à 7.1.1) qui permet à un attaquant non authentifié d'inclure des fichiers .php locaux arbitraires via le paramètre de requête pagename, et, sous certaines conditions serveur spécifiques, d'escalader vers une exécution de code à distance (RCE) en enchaînant le fichier PEAR pearcmd.php. Score CVSS : 9.2 (Critique). Divulguée par Robert Ressl via le programme HackerOne de WordPress en juillet 2026. Corrigée dans la version 7.1.2 le 22 septembre 2026, avec des rétroportages jusqu'à la 4.7.
La faille affecte chaque version de WordPress depuis 2016 — une décennie de versions ayant passé la revue de code sans être détectée. La cause racine est un unique appel de validation manquant dans l'un des chemins de code les plus empruntés du CMS.
Résolution de template non assainie – get_page_template() dans wp-includes/template.php construit les candidats de template à partir de la variable de requête pagename. Un chemin de code voisin dans la même fonction applique validate_file() pour bloquer les séquences ../, mais la branche $pagename ne l'appelle pas. Toute traversée dans pagename passe sans contrôle.
Contournement de traversée doublement encodée – WordPress applique sanitize_title_for_query() à pagename, qui remplace les points littéraux (.) par des tirets pour empêcher la traversée. Mais la fonction opère sur une entrée déjà décodée et ne décode pas récursivement. Un attaquant envoie %252e%252e%252f ; le serveur web le décode une fois en %2e%2e%2f ; le sanitizer ne voit aucun point littéral et le laisse passer ; puis get_page_template() appelle urldecode() à nouveau à l'intérieur de la fonction, produisant ../.
Précondition du répertoire de thème – Le thème actif doit contenir un répertoire de premier niveau dont le nom commence par page- (par exemple page-templates/). Le nom de fichier construit page-{pagename}.php s'échappe alors de la racine du thème via la traversée. Les anciens thèmes par défaut (Twenty Twelve, Twenty Fourteen) et des thèmes tiers populaires (Neve, Hestia, Sydney) embarquent ce répertoire. Les thèmes enfants héritant de tels parents satisfont également la précondition.
Point de chute LFI dans locate_template() – Le chemin candidat est passé à locate_template(), qui recherche dans les répertoires de thèmes. Comme la traversée résout vers un fichier en dehors de ces répertoires, et que la fonction ne vérifie que file_exists(), tout fichier .php lisible est inclus avec les pleins privilèges du serveur web. Cela rend la LFI inconditionnelle sur tout site non corrigé remplissant la précondition de thème — y compris wp-config.php avec ses identifiants de base de données et ses sels d'authentification.
Escalade RCE via PEAR pearcmd.php – PEAR est livré avec de nombreuses installations PHP. Son pearcmd.php est normalement réservé à la CLI, mais lorsque register_argc_argv=On, PHP remplit $_SERVER['argv'] à partir de la chaîne de requête de l'URL. L'attaquant inclut pearcmd.php via la LFI, passe config-create comme argument, et fournit du code PHP plus un chemin de sortie (/tmp/shell.php). PEAR écrit le code de l'attaquant sur le disque ; une seconde inclusion l'exécute.
Seconde route d'exploitation – Une requête combinant name (slug de la page d'accueil), page_id (ID de la page des articles), preview=true et une charge utile pagename détourne WP_Query vers sa branche post_name, qui ne réécrit jamais pagename via sanitize_title_for_query(). Cela autorise des points littéraux dans la traversée. Nécessite un thème sans single.php.
Exigences de configuration serveur – La RCE dépend de deux conditions courantes dans les déploiements réels : pearcmd.php présent/lisible (fréquent sur l'hébergement mutualisé, cPanel, images Docker PHP officielles), et register_argc_argv=On (par défaut dans PHP inférieur à 8.5). PHP 8.5 a changé la valeur par défaut à Off. Sur un serveur PHP 8.5+ moderne sans PEAR, l'exploitation s'arrête à la LFI.
Le correctif – WordPress 7.1.2 ajoute deux couches de défense : (a) l'appel manquant à validate_file() dans la branche pagename, et (b) une nouvelle fonction _wp_is_template_path_allowed() appelée par locate_template() pour chaque template résolu. La fonction rejette les chemins contenant .., puis résout le chemin réel via realpath() et vérifie qu'il se trouve à l'intérieur de l'un des répertoires de thèmes autorisés. Cette défense en profondeur ferme le point de chute, pas seulement une route y menant.
Exploitation active dans la nature – Premières requêtes malveillantes observées 5 heures après la publication du correctif (17:44 UTC, 22 septembre 2026). Le trafic a augmenté de dix fois le jour suivant. Trois étapes observées : reconnaissance config-show → détection de fichiers core → armement config-create. Les noms de fichiers de charge utile incluaient wp-pear-rce-flag.php, poc87902.php, luci_*.php, zeta_*.php, écrits dans /tmp et /var/tmp. IP attaquantes : 169.58.48.193, 169.58.48.195, 2001:df1:e8c0::106b.
Impact – Exécution de code avec les privilèges du serveur web. Prise de contrôle complète du site, vol d'identifiants wp-config.php, exfiltration de données, installation de webshell, création d'utilisateur admin, reverse shell, attaques de chaîne d'approvisionnement via des plugins/thèmes modifiés, et mouvement latéral vers les services connectés. Le score CVSS 9.2 reflète un impact exploitable par le réseau, sans authentification, avec un impact élevé sur la confidentialité/intégrité/disponibilité. La complexité d'attaque élevée reflète les préconditions de thème et de serveur, mais sur un hébergement mutualisé typique, ces conditions sont fréquemment remplies.
