WordPress 7.1.2 : la faille présente depuis WordPress 4.7 et comment protéger votre site

Moins de cinq heures. C’est le temps qu’il a fallu, le 22 septembre, entre la publication de WordPress 7.1.2 et les premières requêtes qui testaient la faille sur des sites réels. Autrement dit, pendant que la plupart des administrateurs finissaient leur journée sans avoir lu la moindre alerte, des robots faisaient déjà le tour du web pour repérer les retardataires.

Et cette fois, le trou ne date pas d’hier : il traîne dans le cœur de WordPress depuis la version 4.7, soit près de dix ans. Je vous explique ce que corrige cette mise à jour, pourquoi votre site n’est pas forcément exploitable (mais doit quand même être patché), et comment vérifier en deux minutes que vous êtes à l’abri.

Ce que corrige WordPress 7.1.2

Contrairement aux versions de maintenance habituelles, la 7.1.2 ne contient qu’un seul correctif, classé critique par l’équipe sécurité de WordPress. Elle arrive cinq jours à peine après la 7.1.1 du 17 septembre, qui corrigeait déjà onze failles. Quand WordPress sort une version mineure pour un seul bug, c’est rarement bon signe pour le bug en question.

La faille porte l’identifiant CVE-2026-87902. Elle a été signalée par le chercheur Robert Ressl via le programme de chasse aux bugs de WordPress sur HackerOne. Le correctif ne touche qu’un fichier, wp-includes/template.php, celui qui décide quel fichier de modèle afficher pour une page.

Côté gravité, la faille est notée 9,2 sur 10 selon la norme CVSS 4.0, soit le niveau « critique ». Ce score suppose une attaque menée à distance, simple à lancer, sans compte ni action de la victime. Il ne veut pas dire que tous les sites tombent : l’attaque dépend aussi de conditions liées au thème et au serveur, j’y reviens plus bas.

La faille CVE-2026-87902 expliquée sans jargon

C’est une inclusion de fichier local (Local File Inclusion, ou LFI en anglais). Le principe : forcer un site à charger un fichier présent sur son propre serveur alors qu’il n’aurait jamais dû y toucher.

Imaginez un réceptionniste d’hôtel à qui vous demandez « le dossier de la chambre 12 ». Il va le chercher dans l’armoire des chambres. Maintenant, demandez-lui « le dossier de la chambre 12, puis remontez d’un étage et prenez celui de la comptabilité ». Un réceptionniste bien formé refuse. Celui de WordPress, lui, y allait.

Concrètement, quand WordPress cherche le modèle d’une page, il utilise le paramètre pagename de l’URL. Ce paramètre était décodé, puis utilisé pour construire un chemin de fichier sans passer par le contrôle validate_file(), la fonction qui bloque les fameuses séquences ../ (« remonte d’un dossier »). Un visiteur anonyme, sans compte ni mot de passe, pouvait donc pousser WordPress à inclure un fichier PHP situé ailleurs sur le serveur. Le correctif ajoute une vérification qui cantonne le chemin au dossier du thème.

Toutes les versions sont concernées, mais tous les sites ne sont pas exploitables

Soyons clairs : le titre qu’on lit un peu partout, « tous les sites WordPress menacés », est exagéré. Toutes les versions de 4.7 à 7.1.1 contiennent le code fautif, oui. Mais pour qu’un attaquant en tire quelque chose, le chercheur liste plusieurs conditions :

1. Une page publiée et accessible sans être connecté (autant dire, presque tous les sites).
2. Un dossier dont le nom commence par page- à la racine du thème actif. C’est le cas du classique page-templates, présent dans Twenty Twelve, Twenty Fourteen et bon nombre de thèmes tiers.
3. Des fichiers PHP lisibles en dehors du thème, ce qui est la configuration normale d’un serveur.

Ces trois conditions suffisent pour l’inclusion de fichier. Pour aller jusqu’à l’exécution de code à distance, il faut en plus que le serveur embarque PEAR (pearcmd.php, une vieille boîte à outils PHP), que la directive register_argc_argv soit activée et qu’un dossier temporaire soit accessible en écriture. Ce n’est pas si rare : d’après Patchstack, register_argc_argv est activée par défaut dans les images Docker officielles de PHP et sous cPanel pour les versions antérieures à PHP 8.5.

Bref, votre site n’est peut-être pas exploitable. Mais vous n’avez aucune envie de l’apprendre en lisant vos journaux après coup, surtout que des outils de scan automatisés visant cette faille circulent publiquement.

Pourquoi cette faille sort de l’ordinaire

Les failles du cœur de WordPress sont rares, et celles-ci ont souvent une durée de vie courte. Celle de juillet, wp2shell, visait une fonction de l’API REST apparue en 6.9. Celle d’août, corrigée par WordPress 7.0.4 via Imagick et Ghostscript, dépendait de bibliothèques installées sur le serveur.

Ici, le code vulnérable date de WordPress 4.7, sortie en décembre 2016. Résultat : l’équipe de sécurité a dû publier un correctif pour 25 branches différentes, de la 7.1 jusqu’à la 4.7. C’est la preuve qu’un bout de code peut passer des centaines de relectures pendant dix ans sans que personne ne remarque le trou. Et c’est aussi un rappel que les vieux sites oubliés, restés en 5.x chez un client, sont concernés au même titre que les vôtres.

Depuis la 7.1.2 : WordPress 7.1.3 et 7.1.4

La 7.1.2 n’est déjà plus la version à viser. Le 6 octobre, WordPress 7.1.3 a corrigé sept autres failles de sécurité, dont une injection SQL dans l’export WXR (le fichier produit par Outils > Exporter) et l’affichage, sans connexion, de commentaires rattachés à des contenus privés ou non publiés. Le 28 octobre, la 7.1.4 a suivi avec 22 vulnérabilités corrigées : surtout des failles XSS, souvent exploitables depuis un simple compte Contributeur, et une situation de concurrence (race condition) pendant la mise à jour du cœur qui pouvait mener à une exécution de code.

Chaque version reprend les correctifs des précédentes : installer la 7.1.4 vous protège donc aussi contre la CVE-2026-87902. Les anciennes branches ont suivi le même rythme, de la 7.0.8 jusqu’à la 4.7.39. La prochaine version majeure, WordPress 7.2, est attendue début décembre 2026.

Comment vérifier que votre site WordPress est à jour

Premier réflexe : allez dans Tableau de bord > Mises à jour. La version installée s’affiche en haut de la page. Si vous lisez 7.1.4, vous êtes à jour. En 7.1.2 ou 7.1.3, cette faille est corrigée, mais pas celles d’octobre. Sinon, cliquez sur « Mettre à jour vers la version 7.1.4 », après une sauvegarde complète de votre site si vous n’en avez pas de récente.

Sachez que WordPress n’a pas « forcé » cette mise à jour au sens strict : les sites qui acceptent les mises à jour automatiques des versions mineures (le réglage par défaut) la reçoivent en arrière-plan. Si vous ou votre hébergeur avez désactivé ce mécanisme, par exemple avec la constante WP_AUTO_UPDATE_CORE réglée sur false, rien ne se passera tout seul.

Si vous avez un accès SSH, WP-CLI (l’outil de WordPress en ligne de commande) va plus vite, surtout si vous gérez plusieurs sites :

# Affiche la version installée
wp core version

# Installe la dernière version mineure de votre branche (7.1.4, 7.0.8, 6.9.11…)
wp core update --minor

Vous êtes resté sur une branche plus ancienne ? Voici, pour chacune, la première version qui corrige la CVE-2026-87902 et la plus récente, publiée le 28 octobre 2026 :

Votre branche	Corrige la CVE-2026-87902 (22 septembre)	Dernière version (28 octobre)
7.1	7.1.2	7.1.4
7.0	7.0.6	7.0.8
6.9	6.9.9	6.9.11
6.8	6.8.10	6.8.12
6.7	6.7.9	6.7.11
6.6	6.6.9	6.6.11
6.5	6.5.12	6.5.14
6.4	6.4.12	6.4.14
6.3	6.3.12	6.3.14
6.2	6.2.13	6.2.15
6.1	6.1.14	6.1.16
6.0	6.0.16	6.0.18
5.9	5.9.18	5.9.20
5.8	5.8.17	5.8.19
5.7	5.7.19	5.7.21
5.6	5.6.21	5.6.23
5.5	5.5.22	5.5.24
5.4	5.4.23	5.4.25
5.3	5.3.25	5.3.27
5.2	5.2.28	5.2.30
5.1	5.1.26	5.1.28
5.0	5.0.29	5.0.31
4.9	4.9.33	4.9.35
4.8	4.8.32	4.8.34
4.7	4.7.37	4.7.39

Petit conseil : ces correctifs de branche vous dépannent aujourd’hui, mais WordPress rappelle que seule la dernière version est activement supportée. Si vous êtes encore en 5.x, profitez-en pour planifier la vraie migration, avec mon guide pour réussir une mise à jour WordPress sans casser votre site.

Vous ne pouvez pas mettre à jour tout de suite ?

Ça arrive : site client figé, extension incompatible, validation à obtenir. Dans ce cas, réduisez le risque en attendant, sans considérer ces mesures comme un substitut au correctif.

1. Regardez si votre thème actif contient un dossier page- à sa racine. Sans lui, la faille n’est pas exploitable selon le chercheur.
2. Activez un pare-feu applicatif (WAF, Web Application Firewall) qui filtre cette attaque. Patchstack a déployé une règle dédiée le jour même. Wordfence aussi : le 22 septembre pour ses offres payantes, puis le 22 octobre pour la version gratuite, après son délai habituel de 30 jours.
3. Demandez à votre hébergeur de désactiver register_argc_argv pour le web et de retirer PEAR s’il ne sert à rien. Ça coupe la route vers l’exécution de code.

Pour le premier point, une commande suffit depuis la racine de votre installation :

# Liste les dossiers « page-* » à la racine de vos thèmes
ls -d wp-content/themes/*/page-*/

Mon site a-t-il été visé ?

Les premières tentatives relevées par Patchstack le 22 septembre relevaient de la reconnaissance : les robots demandaient à WordPress d’inclure des fichiers du cœur comme wp-cron.php ou wp-links-opml.php pour voir si le site répondait. En moins d’une journée, les attaquants sont passés à l’étape suivante : inclure pearcmd.php pour écrire des fichiers PHP sur le disque, souvent dans /tmp, puis les charger via la faille. Le trafic visant cette CVE a été multiplié par dix dès le lendemain. Leurs requêtes ont une signature reconnaissable : un paramètre pagename contenant une remontée de dossier doublement encodée (%252e%252e), souvent accompagné d’un paramètre page_id.

Si votre hébergeur vous donne accès aux journaux, cherchez ce motif :

# Cherche les remontées de dossier via pagename et les appels à pearcmd
grep -iE "pagename=[^& ]*(%252e|%2e%2e|\.\.)|pearcmd" access.log

Une ou deux lignes avant votre mise à jour ? Pas de panique, c’est le bruit de fond d’Internet. En revanche, une ligne contenant pearcmd, des fichiers PHP inconnus dans /tmp ou wp-content/uploads, ou un compte administrateur que vous n’avez pas créé justifient un vrai nettoyage. Mon guide pour améliorer la sécurité de votre site WordPress vous donne la marche à suivre.

Ce que je ferais à votre place

1. Vérifiez la version de chaque site que vous gérez, y compris les vieux sites clients oubliés, et passez-les sur la version corrigée de leur branche aujourd’hui.
2. Contrôlez que les mises à jour mineures automatiques sont actives : c’est ce réglage qui a protégé les sites en quelques heures cette fois.
3. Si vous gérez plusieurs sites, centralisez leur suivi, avec WP-CLI ou un outil comme MainWP, pour ne plus tomber sur un retardataire trois semaines plus tard.

Si je ne devais garder qu’un conseil : ne désactivez jamais les mises à jour mineures du cœur pour « garder la main ». Entre le correctif et les premiers robots, il s’est écoulé moins de cinq heures. Aucun administrateur humain ne tient ce rythme.