Faille WordPress 7.1.2 : la RCE est déjà exploitée

Une faille critique du cœur de WordPress, référencée CVE-2026-87902, est activement exploitée depuis le 22 septembre 2026 pour écrire des fichiers PHP sur les serveurs et y exécuter des commandes. Le correctif existe déjà : il s’agit de WordPress 7.1.2, publié la veille, et sa mise en place est l’action la plus rentable que vous puissiez mener aujourd’hui sur votre site vitrine ou votre boutique.

Ce que permet la faille CVE-2026-87902

Il s’agit d’une traversée de répertoire non authentifiée : aucun compte, aucun mot de passe, aucun plugin tiers n’est nécessaire pour la déclencher. La fonction interne get_page_template() de WordPress, chargée de résoudre le gabarit d’une page, peut être détournée pour inclure un fichier .php situé en dehors du thème actif. L’équipe de sécurité de WordPress lui attribue un score de 9,2 sur 10, et le correctif a été rétroporté jusqu’à la branche 4.7 — un effort exceptionnel qui dit assez la gravité du problème.

La bascule vers l’exécution de code n’est pas automatique : elle suppose que le fichier inclus soit lisible par le compte du serveur web. Le cas d’école documenté dans l’avis officiel est pearcmd.php, présent sur de nombreux hébergements, lorsque le réglage PHP register_argc_argv est actif. C’est exactement la configuration par défaut de l’image Docker officielle de PHP et de cPanel avec une version de PHP antérieure à 8.5.

Pourquoi votre site est probablement concerné

Deux conditions techniques suffisent. D’abord, le thème actif (parent ou enfant) doit contenir un répertoire de premier niveau dont le nom commence par page-, typiquement page-templates : c’est une convention très répandue, y compris dans les thèmes commerciaux les plus vendus. Ensuite, l’hébergement doit exposer un fichier PHP lisible exploitable, ce que la configuration cPanel par défaut fait sans que personne ne l’ait décidé.

Autrement dit, la vulnérabilité ne vise pas un plugin exotique installé par erreur : elle touche le cœur du CMS que font tourner la majorité des sites de PME françaises, et la chaîne d’exploitation repose sur des réglages d’hébergement mutualisé courants. Si votre site a été livré par une agence il y a deux ans et qu’il se met à jour tout seul, vérifiez quand même : les mises à jour automatiques du cœur ne couvrent pas toujours les versions majeures selon la configuration retenue à l’installation.

Les signes d’une tentative d’exploitation

L’éditeur de sécurité Patchstack a observé les premières requêtes malveillantes le 22 septembre à 17 h 44 UTC, moins de cinq heures après la publication du correctif. Le trafic a été d’abord de la reconnaissance — inclusion de fichiers WordPress banals pour identifier les sites vulnérables — avant d’être multiplié par dix et d’embarquer une phase d’écriture sur disque.

Trois indices concrets à chercher dans vos journaux et sur votre serveur :

• Des requêtes contenant des séquences de traversée doublement encodées dans le paramètre pagename, accompagnées d’un page_id valide.
• Des fichiers PHP inattendus dans /tmp et /var/tmp, aux noms du type wp-pear-rce-flag.php, poc87902.php, luci_<aléatoire>.php ou zeta_<aléatoire>.php.
• Du trafic depuis les adresses 169.58.48.193, 169.58.48.195 et 2001:df1:e8c0::106b, identifiées comme sources des premières vagues.

Certaines charges se contentent de déposer un marqueur signalant l’hôte comme exploitable — une cartographie préalable. D’autres écrivent déjà une balise courte qui exécute une commande shell au premier accès. La fenêtre entre le marquage et l’exploitation réelle se compte en jours, pas en mois.

Que faire maintenant

• Vérifiez la version affichée dans Tableau de bord → Mises à jour, et appliquez WordPress 7.1.2 (ou la version corrigée de votre branche) dans la journée.
• Recherchez les fichiers PHP créés récemment dans /tmp, /var/tmp et la racine du site, puis conservez-les avant suppression : ce sont vos preuves.
• Désactivez le réglage PHP register_argc_argv sur votre hébergement, ou passez en PHP 8.5, pour couper la chaîne menant à l’exécution de code.
• Bloquez au pare-feu applicatif les trois adresses sources connues et les requêtes contenant des séquences de traversée encodées.
• Relisez les journaux d’accès depuis le 22 septembre : une mise à jour ne supprime pas une porte dérobée déjà déposée.

Une tentative d’écriture de fichier sur un serveur web se voit dans les journaux à condition que quelqu’un les regarde en continu : c’est précisément le rôle de notre SOC managé 24/7 pour PME et ETI.

Si l’exercice vous rappelle la faille The Events Calendar de la semaine dernière, c’est normal : le schéma se répète. Et si vous soupçonnez qu’un fichier est déjà en place, notre article sur la manière de détecter et bloquer les portes dérobées WordPress décrit la marche à suivre.

Ce qu’il faut retenir

• CVE-2026-87902 touche le cœur de WordPress, sans authentification, avec un score de 9,2 sur 10.
• L’exploitation réelle a démarré le 22 septembre, moins de cinq heures après le correctif.
• Les hébergements cPanel en PHP antérieur à 8.5 et les images Docker PHP officielles sont en première ligne.
• La mise à jour en 7.1.2 est nécessaire mais insuffisante si un fichier a déjà été déposé.

Sources

• Avis de sécurité officiel WordPress (GHSA-7hp8-65ch-5whp)
• Notes de version WordPress 7.1.2
• Analyse Patchstack des vagues d’exploitation
• BleepingComputer — exploitation active de la faille