WordPress : faille d’inclusion de fichier exploitée, au KEV

Le 22 septembre 2026, le projet WordPress publie la version 7.1.2, une mise à jour de sécurité qui ne corrige qu’une seule faille, la CVE (1) CVE-2026-87902. La même correction est rétroportée sur toutes les branches encore éligibles, jusqu’à la 4.7. Le défaut touche le cœur du logiciel, pas une extension ni un thème : toute version de 4.7.0 à 7.1.1 est concernée.

Le 25 septembre, l’agence américaine CISA (2) inscrit cette CVE à son catalogue Known Exploited Vulnerabilities, KEV (3), sur la foi d’une exploitation constatée. L’entrée porte une échéance de correction au 28 septembre 2026, soit trois jours, la mention d’un triage forensique obligatoire, et un champ « usage dans des campagnes de ransomware » renseigné « inconnu ». La CISA nomme la faille « WordPress Core Remote File Inclusion Vulnerability ».

La faille permet à un attaquant distant et sans authentification de détourner la résolution du modèle de page pour faire inclure un fichier PHP (4) local présent sur le serveur, hors des répertoires du thème actif. Selon la configuration du serveur et du thème, cette inclusion mène à l’exécution de code à distance, RCE (5). Le score CVSS (6) 4.0 publié par le déclarant est de 9,8 dans la presse et de 9,2 sur l’avis d’origine ; ce n’est pas un zero-day, le correctif était disponible le jour de la publication de la faille.

Pour afficher une page, WordPress choisit un fichier de modèle dans le thème au moyen d’une liste de candidats. La fonction get_page_template(), dans wp-includes/template.php, construit l’un de ces candidats à partir de la variable de requête publique pagename, sous la forme page-{pagename}.php. Le défaut tient à une seconde application de urldecode() sur cette valeur, alors que la requête a déjà été décodée une fois en amont. Une valeur doublement encodée traverse donc la première désinfection sous forme d’octets échappés, puis redevient une syntaxe de traversée de répertoire au moment précis de la résolution du modèle.

Le candidat est ensuite passé à locate_template(), qui, dans les versions vulnérables, vérifie seulement l’existence et la lisibilité du fichier, jamais que le chemin résolu reste à l’intérieur d’un répertoire de thème autorisé. Le classement de vulnérabilité retenu est le CWE (7) 98, contrôle incorrect du nom de fichier dans une instruction d’inclusion PHP. La primitive obtenue, à ce stade, est une inclusion de fichier local, LFI (8) : l’attaquant fait exécuter par WordPress n’importe quel fichier PHP lisible du serveur dont le chemin peut être atteint, à condition que ce chemin commence par un segment que le préfixe page- rend valide et se termine en .php, puisque le suffixe est ajouté par le code.

Inclure un fichier PHP local n’est pas, en soi, l’exécution du code de l’attaquant : c’est l’exécution de ce que fait ce fichier. Le passage à l’exécution de code arbitraire suppose la présence d’un fichier PHP lisible qui produise un effet utile une fois inclus. Le candidat public est pearcmd.php, un utilitaire de la bibliothèque PEAR (9), qui ne devient exploitable que lorsque l’option PHP register_argc_argv est active. Cette combinaison, l’inclusion locale suivie de la transition PEAR vers l’exécution de code, est la chaîne documentée par le chercheur ; elle n’est pas une dépendance de WordPress et n’est pas présente partout.

La faille a deux issues possibles, et la distinction commande la réponse. La traversée et l’inclusion de fichier local sont présentes sur tout site non corrigé. L’exécution de code, elle, exige deux conditions cumulatives, énoncées par l’avis d’origine.

• Le thème actif, parent ou enfant, contient un répertoire de premier niveau dont le nom commence par page-, par exemple page-templates. WordPress ajoute lui-même le préfixe page-, la traversée ne peut donc démarrer que si un tel répertoire existe. L’avis cite les thèmes historiques Twenty Twelve et Twenty Fourteen, ainsi que des thèmes tiers répandus, Neve, Hestia et Sydney.
• Un fichier PHP cible existe sur le serveur et reste lisible par le compte du serveur web. La transition connue par pearcmd.php vaut lorsque register_argc_argv est à On : l’image officielle PHP pour Docker est concernée, et la configuration cPanel par défaut l’est lorsqu’une version de PHP antérieure à 8.5 est en service.

Un site sur thème récent sans répertoire page-, ou dont le serveur n’a pas de PEAR joignable et register_argc_argv désactivé, n’est pas exploitable pour l’exécution de code dans sa configuration du moment. Ce constat ne vaut pas mesure de contournement durable : la primitive d’inclusion reste présente tant que le cœur n’est pas mis à jour, et un changement de thème, de paquet ou de réglage serveur peut réunir les conditions à tout moment. Le chercheur, comme les éditeurs de sécurité, souligne n’avoir pas mesuré la proportion de sites qui réunissent la chaîne complète ; le score de 9,2 n’est pas ce comptage.

Le correctif touche un seul fichier, wp-includes/template.php, et ajoute deux protections complémentaires. La première fait passer le nom de page décodé par validate_file() avant de l’ajouter à la liste des candidats, ce qui rejette la syntaxe de traversée sur le chemin vulnérable. La seconde introduit une fonction _wp_is_template_path_allowed() qui, pour tout candidat comportant une composante de traversée, résout le chemin canonique et vérifie qu’il reste dans un répertoire de thème ou de compatibilité autorisé avant l’inclusion. La première mesure ferme le chemin connu ; la seconde couvre les autres appelants du cœur, ce qui indique que l’équipe a traité la résolution de modèle comme une classe de défauts et non comme un cas isolé.

Les versions vulnérables et corrigées sont propres à chaque branche. Une formule du type « 7.1.1 et antérieures » serait fausse, car les rétroportages du 22 septembre corrigent des versions dont le numéro se classe sous 7.1.1. Le tableau donne, pour chaque branche, la version à installer.

Fig. 1 : versions vulnérables et versions corrigées par branche, relevées sur l’avis WordPress rendu et la page de documentation de la version 7.1.2. Les branches 4.6 et antérieures ne reçoivent plus de correctif de sécurité.

Seule la dernière version de la branche 7.1 est activement maintenue ; les autres corrections sont des rétroportages de courtoisie. Un site sur une branche ancienne applique la version corrigée disponible sans attendre, puis planifie une montée vers une branche maintenue.

La directive BOD (10) 26-04, publiée le 10 juin 2026, remplace la BOD 22-01 de 2021 et s’applique aux agences civiles fédérales américaines, dites FCEB (11). Elle abandonne le délai uniforme des entrées KEV au profit d’un tableau de seize combinaisons de quatre variables : exposition publique de l’actif, présence au catalogue KEV, automatisation possible de l’exploitation, impact technique total ou partiel. La tranche la plus courte, trois jours calendaires assortis d’un triage forensique, s’applique dès qu’une CVE est au KEV et donne un contrôle total de l’actif après exploitation, indépendamment de l’exposition et de l’automatisation. C’est cette combinaison qui produit l’échéance du 28 septembre pour la CVE-2026-87902, et l’obligation d’établir si le système a été compromis avant l’application du correctif.

Les notations méritent d’être lues côte à côte, car elles ne concordent pas. Le déclarant, via son autorité de numérotation, publie un score CVSS 4.0 de 9,2, critique, avec un vecteur réseau et une complexité d’attaque basse. La CISA, dans son programme d’enrichissement, publie un score CVSS 3.1 de 8,1, élevé, avec une complexité d’attaque haute. La NVD (12) reprend cette même valeur de 8,1. L’écart tient au cadre de notation retenu et à la lecture de la complexité : la version 4.0 isole la condition de déploiement dans une métrique dédiée, là où la version 3.1 la fait porter sur la complexité d’attaque.

L’éditeur Patchstack situe la première tentative sur son pare-feu le 22 septembre à 11 h 49 UTC, le jour même de la publication. Les requêtes reprennent l’encodage exact que le correctif traite, ce qui indique un travail à partir du différentiel de code plutôt qu’une découverte indépendante. Le chercheur à l’origine du signalement a publié le même jour un code de démonstration et un laboratoire reproductible ; un premier probing a été relevé moins de cinq heures après la mise à disposition de la version 7.1.2.

Le trafic a suivi trois étapes. La première pointe l’inclusion vers un fichier anodin du cœur pour établir si l’hôte est vulnérable. La deuxième vise pearcmd.php pour vérifier que PEAR est joignable et que l’astuce sur register_argc_argv fonctionne. La troisième écrit un fichier PHP sur le disque, dans /tmp ou /var/tmp, ce qui constitue l’exécution de code. Une part des écritures dépose un marqueur inoffensif, comportement d’un acteur constituant une liste d’hôtes vulnérables ; une autre dépose une balise qui exécute une commande à l’accès. Un fichier déposé dans /tmp n’est en général pas joignable depuis le web : c’est une preuve d’exécution, pas un backdoor persistant, mais la même primitive peut écrire ailleurs.

La commoditisation est allée vite : des agents connus dans le trafic et un modèle Nuclei nommé signalent une diffusion large de l’outillage dès le 23 septembre. Un réseau de honeypots tiers, Previdian, a relevé plusieurs dizaines de tentatives à partir du 23 septembre, depuis un petit nombre d’adresses situées aux États-Unis, en Indonésie, en Inde et en Chine, dont une chaîne qui inclut pearcmd.php, écrit dans /tmp, puis appelle un script d’envoi hébergé sur un dépôt public. À la date de rédaction, l’exploitation active et les écritures de fichiers sont attestées ; aucune source ne confirme un cas de RCE réussie sur un site de production, ni ne publie de décompte de compromissions.

Fig. 2 : repères d’exploitation relevés par Patchstack et Previdian entre le 22 et le 24 septembre 2026. Les adresses évoluent vite et se comptent désormais en centaines ; le blocage par adresse n’est pas une stratégie.

Les faits de publication, de versions et d’ajout au catalogue viennent de sources primaires. Les circonstances de l’exploitation viennent d’éditeurs de sécurité, recoupées entre elles.

Fig. 3 : statut de chaque élément repris dans l’article selon le nombre et la nature des sources qui l’établissent.

Sans attendre

• Relever la version de WordPress sur chaque site, et installer la version corrigée de sa branche d’après le tableau de la section 4 : 7.1.2, ou le rétroportage correspondant jusqu’à 4.7.37. Ne pas présumer qu’une mise à jour automatique en arrière-plan a réussi sur tous les sites, la vérifier.
• Migrer tout site en 4.6 ou antérieur vers une branche maintenue : ces versions ne recevront jamais de correctif pour cette CVE.
• À défaut de mise à jour immédiate, rejeter au pare-feu applicatif les séquences de traversée dans le paramètre pagename, y compris leur forme encodée qui subsiste après un premier décodage. Un slug de page réel n’en contient jamais. Ce blocage réduit l’exposition sans remplacer le correctif.

Réduire la surface d’exécution de code

• Vérifier si le thème actif, parent ou enfant, porte un répertoire de premier niveau commençant par page-. Le cas est avéré pour Twenty Twelve, Twenty Fourteen, Neve, Hestia et Sydney, mais il se contrôle sur le système de fichiers, pas au nom du thème.
• Passer register_argc_argv à Off pour les requêtes web quand l’option n’est pas nécessaire, et retirer des images de production les points d’entrée PEAR web-lisibles inutilisés, à commencer par pearcmd.php. Ces mesures cassent la chaîne documentée vers la RCE sans corriger l’inclusion.
• Restreindre les droits du compte du serveur web sur le système de fichiers : un confinement par open_basedir ou une politique de contrôle d’accès obligatoire peut bloquer une partie de la chaîne. Un montage noexec sur /tmp ne suffit pas, PHP lisant et interprétant le fichier.

Rechercher les traces

• Passer en revue les journaux du serveur web et du pare-feu à la recherche de requêtes portant une valeur de traversée dans pagename, sur la racine du site ou /index.php, en particulier à partir du 22 septembre 2026. Une réponse de type flux OPML ou RSS renvoyée depuis une URL de page ordinaire signale une inclusion qui a abouti.
• Sur l’hôte, vérifier /tmp et /var/tmp pour des fichiers PHP inattendus, dont wp-pear-rce-flag.php, poc87902.php, et les noms en luci_ ou zeta_. Leur présence signe une écriture réussie : l’hôte est à traiter comme compromis, non comme simplement scanné.
• Sur un IOC (14) positif, conduire une réponse à incident complète : revue des comptes d’administration, des extensions récemment installées ou modifiées, des tâches planifiées et des fichiers PHP inattendus, avant restauration depuis une sauvegarde saine.

1. CVE (1) : Common Vulnerabilities and Exposures, identifiant public unique d’une vulnérabilité.
2. CISA (2) : Cybersecurity and Infrastructure Security Agency, agence américaine de cybersécurité et de sécurité des infrastructures.
3. KEV (3) : Known Exploited Vulnerabilities, catalogue tenu par la CISA des vulnérabilités pour lesquelles une exploitation a été constatée.
4. PHP (4) : PHP Hypertext Preprocessor, langage de script côté serveur sur lequel repose WordPress.
5. RCE (5) : Remote Code Execution, exécution de code à distance sur le système visé.
6. CVSS (6) : Common Vulnerability Scoring System, cadre de notation standardisé de la gravité d’une vulnérabilité.
7. CWE (7) : Common Weakness Enumeration, classification des types de faiblesses logicielles.
8. LFI (8) : Local File Inclusion, inclusion d’un fichier déjà présent sur le serveur, ici par traversée de répertoire.
9. PEAR (9) : PHP Extension and Application Repository, système historique de paquets PHP dont l’utilitaire pearcmd.php sert de relais vers l’exécution de code.
10. BOD (10) : Binding Operational Directive, directive contraignante de la CISA applicable aux agences civiles fédérales américaines.
11. FCEB (11) : Federal Civilian Executive Branch, agences civiles fédérales américaines soumises aux directives de la CISA.
12. NVD (12) : National Vulnerability Database, base américaine de vulnérabilités tenue par le NIST, qui publie sa propre notation.
13. SSVC (13) : Stakeholder-Specific Vulnerability Categorization, méthode de décision de la CISA dont les valeurs d’exploitation, d’automatisation et d’impact technique alimentent la BOD 26-04.
14. IOC (14) : Indicator of Compromise, indicateur technique d’une compromission, ici une adresse, un nom de fichier ou une empreinte de requête.

1. WordPress, avis GHSA-7hp8-65ch-5whp, Unauthenticated path traversal in page-template resolution leading to conditional RCE, 22 septembre 2026. github.com
2. WordPress, WordPress 7.1.2 Release, 22 septembre 2026. wordpress.org
3. WordPress, Version 7.1.2, documentation, 22 septembre 2026. wordpress.org
4. CISA, CISA Adds One Known Exploited Vulnerability to Catalog, 25 septembre 2026. cisa.gov
5. CISA, Known Exploited Vulnerabilities Catalog, fiche CVE-2026-87902, version 2026.09.25. cisa.gov
6. CISA, BOD 26-04 Prioritizing Security Updates Based on Risk, 10 juin 2026. cisa.gov
7. CVE Program, fiche CVE-2026-87902, notation du déclarant et enrichissement CISA ADP, consultée le 25 septembre 2026. cve.org
8. NVD, CVE-2026-87902, consultée le 25 septembre 2026. nvd.nist.gov
9. Patchstack, WordPress 7.1.2 Security Release: Unauthenticated LFI to RCE, 22 septembre 2026. patchstack.com
10. Patchstack, CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch, 22 et 23 septembre 2026. patchstack.com
11. Wordfence, PSA: Critical Unauthenticated Path Traversal Vulnerability Patched in WordPress Core, 22 septembre 2026. wordfence.com
12. Robert Ressl, CVE-2026-87902 write-up et dépôt de démonstration, 22 septembre 2026. ressl.ch
13. The Hacker News, Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure, 24 septembre 2026. thehackernews.com
14. SecurityWeek, Critical WordPress Vulnerability Exploited Immediately After Disclosure, 24 septembre 2026. securityweek.com
15. Help Net Security, WordPress 7.1.2 fixes critical unauthenticated path traversal vulnerability (CVE-2026-87902), 23 septembre 2026. helpnetsecurity.com
16. Previdian, CVE-2026-87902 Exploitation Observed, télémétrie honeypot, consultée le 25 septembre 2026. previdian.com
17. Tenable, CISA BOD 26-04: Frequently asked questions about the new risk-based patching directive, 11 juin 2026. tenable.com