CVE-2026-87902 est la faille critique qui frappe cette semaine WordPress, le CMS qui fait tourner environ 40 % des sites web dans le monde. Notée 9.2 sur 10 selon l'échelle CVSS, elle touche le cœur même du logiciel et permet, sous certaines conditions, l'exécution de code à distance sans authentification. Le correctif est sorti le 22 septembre 2026, mais les premières tentatives d'exploitation ont été observées quelques heures plus tard seulement, ce qui en fait un cas d'école de la course entre publication d'un correctif et exploitation de masse.
Qu'est-ce que la faille CVE-2026-87902 ?
CVE-2026-87902 touche le mécanisme de résolution des modèles de page (« page templates ») de WordPress. En résumé, le logiciel construit un chemin de fichier à partir de paramètres fournis par le visiteur sans les neutraliser correctement lorsqu'ils contiennent des séquences de traversée de répertoire encodées. Un attaquant non authentifié peut ainsi forcer WordPress à inclure un fichier situé en dehors du thème actif, ce qui constitue une inclusion de fichier local (LFI).
Le passage de la simple lecture de fichier à l'exécution de code à distance (RCE) dépend de conditions précises sur le serveur, notamment la présence d'un thème dont l'arborescence commence par « page- » et l'accessibilité d'un interpréteur PHP tiers embarqué dans certaines distributions (le module PEAR pearcmd.php). Quand ces conditions sont réunies, l'attaquant peut écrire puis exécuter un fichier PHP arbitraire, prenant ainsi le contrôle du site.
À retenir : une faille non authentifiée notée 9.2/10 dans le cœur de WordPress, exploitable sans compte ni plugin vulnérable, uniquement selon la configuration du serveur.
Comment les attaquants exploitent la faille
Selon l'analyse technique publiée par Patchstack, la chronologie de l'exploitation a été particulièrement rapide :
| Étape | Horodatage (UTC) | Constat |
|---|---|---|
| Publication du correctif | 22 septembre, matin | Version 7.1.2 disponible |
| Premières sondes | 22 septembre, 11 h 49 | Requêtes de reconnaissance sur des fichiers inoffensifs |
| Tentatives d'écriture de fichiers | 22 septembre, 15 h 34 | Premières tentatives d'exploitation active |
| Diffusion d'un outil public | 23 septembre | Un modèle de détection automatisé circule largement |
| Pic de volume | 23 septembre, mi-journée | Vague massive de scans et de tentatives |
Cette rapidité illustre une tendance de fond : dès qu'un correctif est publié, des chercheurs comme ceux de Patchstack ou des attaquants opportunistes comparent l'ancien et le nouveau code pour reconstituer la faille en quelques heures. C'est pourquoi le délai entre la sortie d'un correctif et son application est aujourd'hui la fenêtre de risque la plus critique, bien plus que la période précédant la divulgation.
Versions WordPress concernées et correctifs
La faille touche une plage de versions très large, du fait de l'ancienneté du mécanisme concerné.
| Statut | Versions |
|---|---|
| Vulnérables | 4.7.0 à 7.1.1 |
| Corrigées | 7.1.2, 7.0.6, 6.9.9, 6.8.10 |
| Rétroportage de sécurité | jusqu'à la branche 4.7.x |
La mise à jour est disponible depuis les tableaux de bord d'administration ou en ligne de commande WP-CLI. Sur un site géré par un hébergeur mutualisé, il est recommandé de vérifier que la mise à jour automatique de sécurité a bien été appliquée, plutôt que de supposer qu'elle l'a été.
Indicateurs de compromission et détection
Sans détailler de méthode d'exploitation opérationnelle, voici les éléments objectifs à rechercher dans les journaux d'accès pour savoir si votre site a été ciblé :
- Présence simultanée des paramètres
pagenameetpage_idsur la page d'accueil ouindex.php. - Séquences de traversée de répertoire encodées (doubles encodages) dans le paramètre
pagename. - Requêtes visant le script
pearcmd.php, généralement absentes du trafic normal d'un site WordPress. - Chaînes d'agent utilisateur automatisées associées à des outils de scan publiés pour cette CVE.
- Fichiers
.phpinattendus apparus dans les répertoires temporaires du serveur (/tmp,/var/tmp).
À retenir : l'absence de plugin de sécurité alertant sur ces schémas ne signifie pas l'absence de tentative ; vérifiez vos journaux bruts si votre site est resté sous 7.1.1 après le 22 septembre.
Comment se protéger ?
- Mettre à jour immédiatement vers 7.1.2, 7.0.6, 6.9.9 ou 6.8.10 selon la branche suivie : c'est la seule correction complète.
- Vérifier la configuration PHP : désactiver
register_argc_argvlorsque ce n'est pas nécessaire réduit une exploitation en RCE à une simple divulgation d'information, en cassant la chaîne vers le module PEAR. - Auditer le thème actif : un thème dont un dossier commence par « page- » augmente l'exposition ; renommer ce dossier ou le restructurer limite la surface d'attaque en complément du correctif.
- Surveiller les journaux sur les indicateurs listés ci-dessus, en particulier dans les heures qui suivent une mise à jour tardive.
- Restreindre l'accès en écriture aux répertoires temporaires du serveur pour les comptes utilisés par le serveur web, quand l'architecture d'hébergement le permet.
Pour prioriser vos correctifs sur l'ensemble de votre parc, l'outil ForenShield de consultation de la base CVE permet de retrouver rapidement les avis liés à vos technologies, et notre guide pour comprendre le score CVSS aide à traduire un score comme 9.2 en priorité de traitement concrète. Le cas de wp2shell (CVE-2026-63030), déjà traité sur ce blog, montre que WordPress reste une cible récurrente d'exécution de code à distance.
Points clés
- CVE-2026-87902 est une faille critique (CVSS 9.2) du cœur de WordPress, exploitable sans authentification via une traversée de répertoire menant à une inclusion de fichier, potentiellement jusqu'à l'exécution de code.
- Le correctif (versions 7.1.2, 7.0.6, 6.9.9, 6.8.10) est sorti le 22 septembre 2026 ; les premières tentatives d'exploitation ont commencé le jour même, avant la diffusion d'outils publics le lendemain.
- L'exploitation en RCE dépend de la configuration du serveur (thème avec dossier « page- », module PEAR accessible) : tous les sites vulnérables ne sont pas exposés au même niveau.
- La mise à jour immédiate reste la seule mesure complète ; la surveillance des journaux permet de détecter une tentative même sur un site déjà corrigé tardivement.