WordPress a publié la version 7.1.2 le 22 septembre 2026, et l'annonce la résume en une phrase : une version de sécurité qui corrige une vulnérabilité de gravité critique. L'avis GitHub correspondant est GHSA-7hp8-65ch-5whp, la faille porte le numéro CVE-2026-87902 et son score CVSS v4 est de 9,2. Trois jours plus tard, le 25 septembre, l'agence américaine CISA l'a ajoutée à son catalogue des vulnérabilités exploitées connues « sur la base de preuves d'exploitation active », en donnant aux agences fédérales jusqu'au 28 septembre pour la traiter.

Ce qu'est la faille, et quand elle mène à l'exécution de code

Selon la description officielle, un attaquant non authentifié peut, dans certaines conditions, amener la résolution des modèles de page à inclure un fichier PHP local lisible de son choix, situé hors des répertoires du thème actif ; si les conditions préalables sont réunies à la fois dans l'environnement serveur et dans le thème actif, cela peut conduire à l'exécution de code à distance. L'avis distingue deux types de conditions :

  • Le thème : le thème enfant ou parent actif contient un répertoire de premier niveau dont le nom commence par page- (par exemple page-templates). L'avis cite les anciens thèmes Twenty Twelve et Twenty Fourteen ainsi que des thèmes tiers populaires comme Neve, Hestia et Sydney.
  • Le serveur : un fichier PHP local exploitable existe et est lisible par le compte du serveur web. L'exemple donné est pearcmd.php, qui permet d'exécuter du code lorsque register_argc_argv vaut On. L'avis précise que l'image Docker officielle php est concernée, de même que la configuration cPanel par défaut avec une version de PHP antérieure à 8.5.

Versions concernées et versions corrigées

Toutes les branches de 4.7.0 à 7.1.1 sont concernées. Le correctif a été rétroporté dans toutes les branches qui reçoivent encore des correctifs de sécurité : 7.1.2, 7.0.6, 6.9.9 et ainsi de suite jusqu'à 4.7.37. Quelle que soit votre version majeure, il existe une version corrigée ; l'essentiel est de vérifier qu'elle est réellement installée.

Deux autres versions de sécurité, avant et après

Ce n'est pas un cas isolé. La 7.1.1 du 17 septembre contenait 11 correctifs de sécurité, et la 7.1.3 du 6 octobre a corrigé 7 autres problèmes de sécurité. Les trois annonces indiquent que les sites prenant en charge les mises à jour automatiques en arrière-plan lanceront la mise à jour automatiquement. Mais sur un serveur que vous gérez vous-même, ces mises à jour automatiques peuvent être désactivées par les droits sur les fichiers ou par la configuration : ne supposez pas que la vôtre a déjà eu lieu.

Comment vérifier sur un VPS

  • Vérifiez la version : Tableau de bord → Mises à jour, ou sur le serveur, wp core version avec WP-CLI. Si vous êtes en dessous de la version corrigée de votre branche (sur la branche 7.1, en dessous de 7.1.2), mettez à jour immédiatement ; la 7.1.3 étant déjà sortie, passer directement à 7.1.3 sur la branche 7.1 vous épargne une étape.
  • Vérifiez les répertoires du thème : sous wp-content/themes/, cherchez à la racine du thème actif (et de son thème parent) des répertoires dont le nom commence par page-.
  • Vérifiez PHP : contrôlez la valeur de register_argc_argv dans le PHP réellement utilisé par le site (FPM ou module Apache, pas la ligne de commande) et la présence éventuelle d'un pearcmd.php inutile sur le serveur. Si votre site tourne sur l'image Docker officielle php, vérifiez-le en priorité.
  • Si vous soupçonnez une exploitation : les sites mis à jour seulement après le 22 septembre devraient passer par la liste de contrôle après compromission, à la recherche de fichiers PHP inconnus, de tâches planifiées et de comptes administrateurs suspects.

Pour les bases de WordPress, voir créer un site WordPress sur un VPS ; faites d'abord une sauvegarde en suivant les stratégies de sauvegarde d'un VPS ; et profitez-en pour revoir votre pare-feu ufw et la connexion SSH par clé.