WordPress : quand le patch devient le mode d’emploi des attaquants

Le vrai enseignement n’est pas seulement qu’une vulnérabilité WordPress critique existe. C’est la vitesse avec laquelle un correctif public peut être analysé, compris puis transformé en requêtes automatisées. Pour les services exposés, la fenêtre entre « patch disponible » et « exploitation probable » devient très courte.

Ce que corrige WordPress 7.1.2

WordPress 7.1.2 corrige une vulnérabilité critique dans la résolution des modèles de page. Sous certaines conditions liées au serveur et au thème actif, un attaquant non authentifié peut forcer l’inclusion d’un fichier PHP local lisible situé en dehors des répertoires autorisés du thème. Dans le pire cas, cela peut conduire à une exécution de code à distance.

La faille est référencée CVE-2026-87902. WordPress recommande une mise à jour immédiate et a publié des correctifs rétroportés sur les branches encore couvertes, jusqu’à la série 4.7.

Le plus important : la chronologie

22 septembre 2026 : publication de WordPress 7.1.2 et du correctif.
Quelques heures plus tard : Patchstack observe les premières tentatives automatisées.
17:44 UTC : première activité détectée, moins de cinq heures après la publication.
Les requêtes correspondent au changement du patch : elles utilisent précisément le type d’encodage que le correctif bloque.

Un patch public révèle aussi la forme du bug

Dès qu’un correctif est disponible, un attaquant peut comparer l’ancien et le nouveau code. Le diff réduit fortement le travail nécessaire pour comprendre la vulnérabilité et fabriquer un test automatisé.

Sonde ne veut pas encore dire compromission

Patchstack précise que les premières requêtes observées visaient des fichiers WordPress ordinaires déjà présents sur le serveur. Elles servaient surtout à vérifier si l’inclusion fonctionnait.

C’est une distinction importante : détecter une sonde ne prouve pas qu’un attaquant a exécuté son propre code. En revanche, une réponse inattendue montrant qu’un fichier interne a réellement été inclus confirme que le site se trouvait dans une fenêtre vulnérable.

Ce que cela change pour la priorité de correction

Un score CVSS élevé est utile, mais insuffisant à lui seul. Une vulnérabilité devient beaucoup plus urgente lorsqu’on combine plusieurs signaux :

service exposé directement sur Internet ;
attaque possible sans authentification ;
impact potentiel élevé ;
correctif public facilement analysable ;
activité de sondage ou d’exploitation déjà observée ;
technologie très largement déployée.

Dans ce contexte, attendre le prochain cycle mensuel de maintenance n’est plus adapté. La bonne question devient : combien de temps puis-je raisonnablement rester exposé après la publication du correctif ?

Ce que cela suggère pour InfraCheck

Pour un outil de posture comme InfraCheck, ce type d’incident montre l’intérêt de dépasser une lecture purement statique des vulnérabilités. Une technologie détectée, une version potentiellement vulnérable, l’exposition Internet et la présence d’une exploitation réelle ne devraient pas avoir le même poids qu’une vulnérabilité théorique sur un composant non exposé.

Le contexte peut donc devenir un multiplicateur de priorité : version + exposition + exploitabilité + activité réelle.

Que faire côté WordPress ?

Mettre à jour vers WordPress 7.1.2 ou la version corrigée de votre branche.
Vérifier que les mises à jour automatiques de sécurité fonctionnent réellement.
Contrôler les journaux si le site est resté exposé avant la mise à jour.
Rechercher les requêtes anormales liées au paramètre pagename et aux séquences de traversée encodées.
Examiner les fichiers inattendus ou modifiés si une inclusion semble avoir réussi.
Ne pas considérer un WAF comme un remplacement définitif du correctif.

La fenêtre de réaction se réduit

CVE-2026-87902 illustre une réalité devenue courante : publier un patch protège les utilisateurs qui l’installent, mais fournit également aux attaquants une information extrêmement précise sur la zone corrigée.

La conséquence n’est pas qu’il faut cacher les correctifs. Elle est plus simple : lorsqu’un service exposé reçoit un correctif critique, la vitesse de déploiement fait désormais partie de la défense.

Sources

Publié le 25 septembre 2026. Les observations d’activité proviennent du suivi public de Patchstack.