Publié le 24 septembre 2026 · L'équipe mitza.es
WordPress a publié le 22 septembre 2026 la version 7.1.2, qui corrige CVE-2026-87902, une vulnérabilité critique notée 9,2 sur 10 sur l'échelle CVSS. Ce qui frappe n'est pas seulement la gravité : la faille touche toutes les versions de WordPress publiées entre la 4.7.0 et la 7.1.1, soit près d'une décennie d'installations, de fin 2016 jusqu'au correctif de ce mois-ci.
Où se situe la faille, et pourquoi aucun mot de passe n'est nécessaire
Le problème se trouve dans get_page_template(), la fonction que WordPress utilise pour déterminer quel fichier de modèle du thème charger pour une page. Une validation insuffisante des caractères de traversée de répertoire (../) dans des valeurs dérivées de l'URL permet à un attaquant de détourner cette recherche vers des fichiers .php situés en dehors du dossier du thème. Aucun compte, mot de passe, ni action d'un utilisateur déjà connecté n'est requis : l'attaque arrive directement via une requête HTTP classique.
Quelles versions sont protégées
- Branche 7.1.x : mettez à jour vers la 7.1.2.
- Branche 7.0.x : mettez à jour vers la 7.0.6.
- Branche 6.9.x : mettez à jour vers la 6.9.9.
- Branche 6.8.x : mettez à jour vers la 6.8.10.
- Branche 6.7.x : mettez à jour vers la 6.7.9.
- Branche 6.6.x et antérieures, jusqu'à la 4.7 : mettez à jour vers la 6.6.9 ou la version de maintenance équivalente, jusqu'à la 4.7.37.
L'exploitation a commencé en quelques heures, pas en quelques jours
La société de sécurité Patchstack a détecté les premières requêtes malveillantes contre des sites vulnérables à 17h44 UTC le 22 septembre lui-même, moins de cinq heures après la publication du correctif. En moins d'une journée, le volume de trafic d'attaque a été multiplié par dix, avec des attaquants qui ne se contentaient plus de sonder la faille mais écrivaient déjà des fichiers PHP malveillants sur le serveur pour exécuter des commandes. Le chercheur à l'origine de la découverte, Robert Ressl, a publié une preuve de concept le jour même du correctif, accélérant la course entre ceux qui mettent à jour et ceux qui attaquent.
Quand la faille se transforme en exécution de code à distance
Le chargement de fichiers en dehors du thème est déjà grave en soi, mais le transformer en exécution de code à distance nécessite trois conditions réunies : que le thème actif possède un dossier dont le nom commence par page- (par exemple page-templates), qu'il existe sur le serveur un fichier .php lisible par l'utilisateur du serveur web, et que ce fichier puisse exécuter du code à partir de paramètres externes, comme c'est le cas avec pearcmd.php de PEAR lorsque register_argc_argv est activé. Sans ces trois conditions, le risque immédiat est moindre, mais un attaquant peut tout de même lire des fichiers du serveur auxquels il ne devrait pas avoir accès : la mise à jour reste donc la priorité, quelle que soit la configuration précise de chaque site.
Que faire si vous gérez un site WordPress
Mettez à jour vers la version corrigée de votre branche dès que possible ; si votre installation n'a pas été touchée depuis longtemps et se situe en dessous de la 4.7.37, passez directement à la dernière version stable. Ce n'est pas la première fois cette année que le cœur de WordPress fait l'objet d'une alerte de cette ampleur : en juillet, nous avions déjà couvert la chaîne de failles wp2shell, et le schéma se répète : plus une PME met de temps à se mettre à jour, plus elle reste exposée à quelque chose qui dispose déjà d'un correctif publié. Notre service de maintenance informatique inclut la vérification et la mise à jour des installations WordPress, et si votre site traîne une installation devenue difficile à maintenir, nous pouvons aussi envisager un développement sur mesure plus maîtrisé, repensé depuis zéro.