CVE-2026-87902 : path traversal non authentifié dans le cœur de WordPress

Pourquoi CVE-2026-87902 mérite une action immédiate

Le 22 septembre 2026, l'équipe de sécurité de WordPress a publié la version 7.1.2, accompagnée de correctifs rétroportés sur toutes les branches jusqu'à la 4.7. Une seule faille est corrigée, mais elle est de premier plan : CVE-2026-87902, un path traversal non authentifié dans la résolution du gabarit de page, noté 9,2 sur 10 en CVSS v4.0 (critique). Sans le moindre compte, un attaquant peut faire inclure par WordPress un fichier PHP présent ailleurs sur le serveur, hors du thème actif. L'inclusion mène, sous certaines conditions, à l'exécution de code.

Le sujet n'est pas théorique. D'après Patchstack, des tentatives de sondage sont apparues dans les journaux moins de cinq heures après la publication du correctif. Comme pour wp2shell et xss2shell le mois précédent, le délai entre la divulgation et les premières exploitations se compte en heures. Cet article décrit le mécanisme de la faille, propose un test de détection non destructeur pour vérifier votre exposition, et détaille la remédiation.

Au cœur du bug : une résolution de gabarit qui sort de son dossier

Quand WordPress affiche une page, il choisit le fichier de thème qui va la rendre. Cette sélection passe par get_page_template(), une fonction du cœur qui construit un chemin de fichier à partir de la page demandée, puis l'inclut. Le problème : la valeur qui influence ce chemin n'est pas suffisamment contrainte. Un attaquant peut y glisser une traversée de répertoire, c'est-à-dire une suite de ../ qui remonte l'arborescence, et faire pointer la résolution vers un fichier .php situé hors du thème.

WordPress inclut alors ce fichier, et PHP exécute le code qu'il contient. C'est la définition même d'une inclusion de fichier local. La faille se déclenche sans authentification : elle ne demande ni compte, ni action d'un utilisateur légitime.

Le rôle du double encodage

Le détail qui rend la faille intéressante, et qui explique pourquoi elle a survécu aux nettoyages en amont, tient au double encodage. La charge est écrite dans le paramètre de page sous une forme percent-encodée deux fois (par exemple %252f pour un /). La couche de nettoyage de WordPress laisse passer cette valeur, qu'elle prend pour une chaîne inoffensive, puis la résolution de gabarit la décode une fois de trop et reconstitue la traversée. Deux étapes qui, isolément, semblaient sûres, se contredisent une fois enchaînées.

Autre subtilité utile à connaître pour lire ses journaux : les requêtes d'exploitation portent aussi un identifiant de page valide. Sans une page réelle vers laquelle se rattacher, la requête retombe en 404 et le code vulnérable ne s'exécute pas. La présence conjointe d'un page_id légitime et d'un paramètre de page bourré de séquences encodées est donc une signature nette.

De la LFI à l'exécution de code : une escalade conditionnelle

Il faut être honnête sur la portée. La partie certaine, c'est l'inclusion : sur une version affectée, un attaquant fait inclure un fichier local de son choix. La partie conditionnelle, c'est le passage de cette inclusion à un webshell. Pour exécuter du code arbitraire, l'attaquant a besoin qu'un fichier .php lisible et contenant du contenu qu'il maîtrise existe déjà sur le serveur, puis de le faire inclure par la faille.

Selon l'environnement, ce fichier peut venir de plusieurs sources : un fichier de log dans lequel du texte contrôlé a été injecté, un fichier de session, un envoi de fichier accepté ailleurs sur le site. Aucune de ces conditions n'est universelle, et un serveur durci en réunit rarement plusieurs. C'est ce qui explique l'écart entre la gravité brute (une LFI non authentifiée sur le cœur de WordPress, donc un score critique) et la probabilité réelle d'une RCE complète, qui dépend du terrain. Nous ne détaillons volontairement pas de chaîne prête à l'emploi : sur une cible de production, la reproduire revient à l'exploiter pour de bon.

Suis-je vulnérable ? Versions touchées et correctif

L'avis officiel est clair : la faille affecte WordPress 4.7.0 jusqu'à 7.1.1 incluse. Le correctif est sorti avec la 7.1.2 et a été rétroporté sur chaque branche encore maintenue, jusqu'à la 4.7.37, par courtoisie pour les sites restés sur une version majeure ancienne.

La faille a été signalée par le chercheur Robert Ressl, et suivie sous l'avis GHSA-7hp8-65ch-5whp. C'est la cinquième release de sécurité du cœur depuis juillet 2026 : la cadence, à elle seule, dit quelque chose de l'attention portée à WordPress cette année.

Proof of concept : tester son exposition sans rien casser

Bonne nouvelle : CVE-2026-87902 se teste sans exploit destructeur. On ne cherche pas à lire un secret ni à exécuter du code. On se contente de vérifier que la résolution de gabarit sort de son dossier, en la faisant inclure un fichier du cœur de WordPress, parfaitement inoffensif : wp-links-opml.php, qui n'émet qu'un petit document OPML public (la liste des liens du site). Si son marqueur ressort dans la réponse d'une page normale, l'inclusion hors thème est prouvée. C'est exactement la logique des templates de détection publics.

Le test manuel avec curl

On demande une page réelle (ici page_id=2, la page d'exemple d'une installation par défaut) dont le paramètre de gabarit porte une traversée double-encodée vers wp-links-opml.php, puis on cherche le marqueur OPML dans la réponse.

curl -s "https://VOTRE-SITE/?page_id=2&pagename=templates%2f..%252f..%252f..%252f..%252fwp-links-opml" \
  | grep -i '<opml\|generator="WordPress'

Lecture du résultat :

• La commande affiche une ligne <opml ...> ou un generator="WordPress/..." : le fichier du cœur a été inclus hors du thème, votre site est vulnérable. Mettez à jour sans attendre.
• La commande n'affiche rien : le marqueur n'est pas ressorti. C'est bon signe, mais pas une preuve de correctif à elle seule. La même absence peut venir d'un WAF, d'un thème atypique, d'un page_id inexistant ou d'une simple redirection. Pour conclure, recoupez avec la version (7.1.2 ou la dernière corrective de votre branche).

La profondeur exacte de la traversée (le nombre de ../) dépend de l'arborescence du thème installé. Si le marqueur ne sort pas alors que la version est ancienne, ajustez ce nombre, ou laissez le scanner s'en charger.

Le scan automatisé avec Nuclei

Pour vérifier un parc entier plutôt qu'une URL, la communauté a publié des templates Nuclei (voir les pull requests #17300 et #17302 du dépôt nuclei-templates). Ils procèdent de façon comportementale et non invasive : ils comparent la taille et le contenu de la réponse entre une page normale et la même page avec la traversée, sans lire aucune donnée sensible.

nuclei -u https://VOTRE-SITE -id CVE-2026-87902

Un site remonté par le template est vulnérable. Une absence de résultat signifie seulement que l'inclusion n'a pas été observée, pas que le site est corrigé. Seule la version (7.1.2 ou plus) tranche avec certitude.

Que faire maintenant : le plan de remédiation

Par ordre d'efficacité :

1. Mettez à jour vers WordPress 7.1.2, ou vers le dernier correctif de votre branche si vous êtes resté sur une version majeure antérieure. C'est la seule remédiation qui ferme réellement la faille. La mise à jour de sécurité s'installe sans saut de version majeure.
2. Réduisez la surface d'exécution en attendant : vérifiez que PHP ne s'exécute pas depuis vos répertoires d'envoi et de logs, et que les permissions du système de fichiers empêchent l'écriture là où le serveur peut inclure.
3. Journalisez et surveillez les requêtes suspectes (voir ci-dessous), pour repérer une tentative avant qu'elle n'aboutisse.

Repérer les tentatives dans vos journaux

Vous n'avez rien à envoyer pour repérer une exploitation en cours. La signature est assez parlante :

• une requête GET / portant à la fois un page_id= valide et un paramètre pagename (ou de gabarit) contenant des séquences de traversée double-encodées : %252f, ..%252f, éventuellement %252e%252e ;
• des variantes de profondeur du même motif, testées en rafale sur le même hôte, signe d'un scan qui cherche la bonne longueur de traversée.

Côté indicateurs de compromission, surveillez l'apparition de fichiers PHP inconnus dans les répertoires d'envoi, et les accès inhabituels à des fichiers de log ou de session juste après ces requêtes.

Trois failles WordPress en deux mois : la leçon

wp2shell passait par l'API REST, xss2shell par l'écran de connexion, CVE-2026-87902 par la résolution de gabarit. Trois vecteurs différents, un même constat : les failles critiques du cœur de WordPress se succèdent, elles frappent des installations par défaut, et elles s'exploitent en quelques heures une fois publiques.

Le pentest annuel ne voit aucune des trois : une faille divulguée le 22 septembre n'existe pas dans un rapport daté du printemps. Le scanner de version attrape la partie facile, le numéro dans la plage, mais se fait tromper dès que la version est masquée et rate le contexte du rétroportage. Et le périmètre incomplet reste le talon d'Achille de tout le monde : c'est le vieux WordPress oublié sur un sous-domaine qui tombe en premier. Pour le trouver, encore faut-il cartographier tout son système d'information et faire l'inventaire de sa surface d'attaque externe.

Détecter CVE-2026-87902 en continu avec Flawfence

Chez Flawfence, la logique ne change pas d'une faille à l'autre. Le moteur cartographie le périmètre, identifie chaque instance WordPress exposée, y compris le Shadow IT oublié, situe sa version dans les plages vulnérables connues et vérifie l'exposition des vecteurs concernés, sans jamais envoyer de charge destructrice.

Face à CVE-2026-87902, concrètement, Flawfence :

• découvre vos WordPress exposés, sur tous vos domaines et sous-domaines ;
• situe la version sous la 7.1.2 et signale le cas des branches anciennes à recouper avec leur dernier correctif rétroporté ;
• sonde la résolution de gabarit avec un marqueur d'inclusion bénin, qui confirme la traversée quand une version affectée laisse ressortir le fichier du cœur ;
• surveille en continu, pour qu'un nouveau sous-domaine vulnérable ou un retour en arrière de version déclenche une alerte, sans attendre le prochain audit.

Questions fréquentes sur CVE-2026-87902

Qu'est-ce que CVE-2026-87902 ?

C'est une vulnérabilité critique du cœur de WordPress, un path traversal non authentifié dans la résolution du gabarit de page (get_page_template()). Elle permet de faire inclure un fichier PHP local choisi, hors du thème actif, ce qui constitue une inclusion de fichier local (LFI) et peut mener à l'exécution de code selon la configuration. Elle est notée 9,2 sur 10 en CVSS v4.0.

Quelles versions de WordPress sont concernées ?

Toutes les versions de 4.7.0 à 7.1.1 incluse. Le correctif est arrivé avec la 7.1.2 le 22 septembre 2026, et a été rétroporté sur chaque branche maintenue jusqu'à la 4.7.37. Tout site sous une version inférieure à la 7.1.2 doit être considéré comme concerné tant qu'il n'a pas pris la dernière corrective de son canal.

La faille est-elle activement exploitée ?

Oui, du sondage a été observé très vite. D'après Patchstack, les premières tentatives sont apparues dans les journaux moins de cinq heures après la publication du correctif. Une exploitation aboutie dépend en revanche de conditions serveur qui ne sont pas toujours réunies, ce qui n'est pas une raison pour attendre : le sondage, lui, est massif et immédiat.

Une LFI, est-ce vraiment aussi grave qu'une RCE ?

L'inclusion elle-même est certaine et non authentifiée, d'où le score critique. Le passage à l'exécution de code est conditionnel : il faut qu'un fichier PHP au contenu contrôlé soit déjà lisible sur le serveur. Sur beaucoup d'installations, cette condition finit par être réunie, directement ou en combinant la faille avec une autre. On traite donc CVE-2026-87902 comme une menace de premier plan, sans dramatiser à l'excès la probabilité d'une RCE immédiate sur un serveur bien durci.

Comment tester sans risquer de compromettre mon site ?

Avec le test de la section Proof of concept : on fait inclure un fichier public du cœur (wp-links-opml.php) et on regarde si son marqueur ressort. Aucun secret n'est lu, rien n'est écrit ni exécuté. Testez-le en curl ou avec le template Nuclei, uniquement sur vos propres actifs, ou laissez le scanner de Flawfence le faire sous attestation sur l'honneur.

Bloquer la faille avec un WAF suffit-il ?

C'est une mitigation utile qui réduit le bruit, mais elle reste contournable (l'encodage de la traversée peut varier) et ne corrige pas la cause. La seule remédiation complète est la mise à jour vers 7.1.2 ou le dernier correctif de votre branche.

En résumé

CVE-2026-87902 rappelle une règle simple : une fonction qui construit un chemin de fichier à partir d'une entrée utilisateur doit contraindre cette entrée, sinon elle finit par sortir de son dossier. Ici, la résolution du gabarit de page laissait passer une traversée double-encodée, et un site WordPress par défaut devenait une porte d'inclusion de fichier.

La bonne nouvelle est la même que pour les failles précédentes : détecter cette classe de problèmes ne demande ni exploit destructeur, ni pentest à 20 k€. Il faut un inventaire exhaustif de votre périmètre et une surveillance continue qui teste le comportement réel de vos actifs. C'est exactement ce que Flawfence fait, pour CVE-2026-87902 comme pour la prochaine faille qui n'a pas encore de numéro.

Vérifiez votre exposition dès maintenant, il ne vous faudra que 5 minutes.