Le 22 septembre 2026, WordPress a publié la version 7.1.2 pour corriger CVE-2026-87902, une faille critique d’inclusion de fichier local dans le moteur de résolution des modèles de page. Moins de douze heures plus tard, les premières tentatives d’exploitation étaient déjà enregistrées. Cinq jours après, un rapport de CrowdSec chiffre le balayage à plus de 30 000 adresses IP distinctes, un rythme qui confirme que le correctif seul ne suffit pas à mettre les sites à l’abri.
Une faille non authentifiée dans le cœur de WordPress
Classée CWE-98 (contrôle incorrect d’un nom de fichier utilisé dans un include) et notée 9.2 en CVSS 4.0 par WordPress.org, CVE-2026-87902 permet à un attaquant non authentifié de manipuler la résolution des modèles de page pour forcer l’inclusion d’un fichier PHP local situé hors du répertoire du thème actif. Selon la configuration du serveur, cette inclusion locale peut déboucher sur une exécution de code à distance. Toutes les versions de WordPress depuis la 4.7.0 jusqu’à la 7.1.1 sont concernées.
Chronologie d’une exploitation express
| Date | Évènement |
|---|---|
| 22 septembre, matin | Publication de WordPress 7.1.2 et des rétroportages jusqu’à la branche 4.7.37 |
| 22 septembre, 11h49 UTC | Première tentative d’exploitation observée par Patchstack, le jour même du correctif |
| 24 septembre | Exploitation active confirmée dans la nature |
| 23 au 27 septembre | 30 813 adresses IP uniques ayant envoyé des requêtes malveillantes, selon CrowdSec |
Le rapport de CrowdSec situe l’essentiel du volume de scan aux États-Unis (22 %) et en Iran (20 %), suivis de la Lituanie, des Pays-Bas et de la France. Ce classement par pays d’origine des requêtes ne présume pas de la nationalité des attaquants : la plupart de ces adresses appartiennent à des serveurs ou objets déjà compromis, utilisés comme relais.
Certains administrateurs désactivent volontairement les mises à jour automatiques de WordPress, ce qui les expose en première ligne pendant toute la fenêtre de correction.
Pourquoi la mise à jour automatique ne suffit pas toujours
WordPress corrige les failles critiques par mise à jour automatique mineure depuis des années, mais cette protection dépend d’un réglage que beaucoup d’hébergeurs et d’agences désactivent pour garder la main sur le déploiement. Les environnements de préproduction, les copies de staging et les instances en conteneur échappent souvent à ce mécanisme et restent vulnérables plus longtemps que le site de production qu’ils sont censés répliquer — un point sensible pour quiconque gère un auto-hébergement WordPress avec plusieurs copies actives.
Un correctif virtuel via un pare-feu applicatif (CrowdSec AppSec, ou équivalent chez l’hébergeur) ne remplace pas la mise à jour : il gagne du temps pendant qu’elle se déploie sur l’ensemble du parc, staging compris.
Durcir la configuration PHP en complément
Au-delà de la mise à jour vers 7.1.2 ou une branche corrigée, les recommandations portent aussi sur la configuration PHP du serveur, en particulier la directive register_argc_argv et la présence du script pearcmd.php, deux éléments qui facilitent l’exploitation de failles d’inclusion de fichier sur un socle mal durci.
; php.ini — réduire la surface d'attaque des inclusions de fichier
register_argc_argv = Off
disable_functions = exec,shell_exec,system,passthru,proc_open
allow_url_include = Off
Ce socle rejoint les principes déjà détaillés pour un hardening WordPress minimal : limiter ce que PHP peut exécuter, séparer les environnements et vérifier que la version corrigée est bien celle qui tourne réellement, y compris sur les copies utilisées pour les tests.
Ce qu’il faut retenir
CVE-2026-87902 touche le cœur de WordPress, ne demande aucune authentification et fait l’objet d’un balayage actif à grande échelle depuis sa divulgation. La mise à jour vers 7.1.2 ou une branche corrigée est la mesure prioritaire, à vérifier sur chaque environnement — production, staging, conteneurs — et pas seulement sur le site visible publiquement.
Ce type de faille rappelle pourquoi je recommande systématiquement de traiter les copies de staging comme des cibles à part entière : c’est souvent la préproduction, oubliée des mises à jour automatiques, qui sert de porte d’entrée vers l’infrastructure hébergeant le site public. — Simon Janvier
Pour aller plus loin : le rapport complet de CrowdSec sur l’exploitation de CVE-2026-87902 est consultable sur crowdsec.net.
