En clair, pour un propriétaire de site
Le 22 septembre 2026, WordPress a publié une version d’urgence, la 7.1.2, pour corriger une faille notée 9,2 sur 10. Elle permet à un visiteur anonyme — pas besoin de compte, pas besoin de mot de passe — de faire charger par votre site un fichier qui ne lui appartient pas. Sur certains serveurs, cela va jusqu’à l’exécution de code : l’attaquant fait faire à votre site ce qu’il veut.
- Si votre WordPress se met à jour automatiquement, vous êtes probablement déjà protégé. Les mises à jour de sécurité du cœur s’installent seules par défaut depuis des années.
- Si votre site n’a pas été mis à jour depuis l’été, il est exposé, et il l’est depuis un mois sur une faille que des attaquants utilisent réellement.
Détail technique
La vulnérabilité se situe dans la résolution des gabarits de page, du côté de get_page_template(). Une requête fabriquée exploite une traversée de chemin pour faire inclure par WordPress un fichier PHP lisible situé hors du thème actif. C’est une inclusion de fichier, classée CWE-98.
Le passage de l’inclusion à l’exécution de code n’est pas automatique : il dépend du thème actif et de la configuration du serveur. Une chaîne d’attaque publiquement démontrée s’appuie sur pearcmd.php de PEAR lorsque register_argc_argv est activé — une configuration encore courante sur l’hébergement mutualisé.
La faille a été signalée de façon responsable par le chercheur Robert Ressl via HackerOne.
Synthèse
| Composant | WordPress, cœur |
| Identifiant | CVE-2026-87902 |
| Type | Inclusion de fichier PHP par traversée de chemin (CWE-98) |
| Gravité | 9,2 / 10 (CVSS v4.0) — critique |
| Versions affectées | 4.7.0 à 7.1.1 incluse |
| Version corrigée | 7.1.2, avec rétroportage jusqu’à la branche 4.7 |
| Authentification requise | Non |
| Exploitation connue | Oui, dès le jour de la publication |
| Vérifié le | 22 octobre 2026 |
Est-elle réellement exploitée ?
Oui. Patchstack rapporte une première tentative d’exploitation à 11 h 49 UTC le jour même de la sortie du correctif, et un volume d’attaques multiplié par dix dès le lendemain. Plusieurs sources rapportent également une inscription au catalogue CISA KEV le 25 septembre 2026 — cette dernière information n’apparaît que dans une source secondaire, nous la citons sous réserve.
L’écart entre la publication d’un correctif et son installation est exactement la fenêtre que visent les attaques automatisées. Un correctif publié n’est pas un site protégé.
Comment corriger
- Mettre à jour WordPress en 7.1.2 au minimum. La version courante de la branche est plus récente encore : prenez la dernière proposée par votre tableau de bord.
- Si vous êtes restés sur une branche ancienne pour des raisons de compatibilité, le correctif a été rétroporté jusqu’à 4.7 : il existe une version corrigée pour votre branche.
- Vérifier que les mises à jour automatiques de sécurité sont actives. C’est le réglage qui vous protège des prochaines, pas de celle-ci.
- Certains hébergeurs ont déployé une protection au niveau de leur réseau. C’est une rustine côté hébergeur, pas un correctif : elle ne vous dispense pas de la mise à jour.
Comment vérifier votre version
Dans l’administration : Tableau de bord → Mises à jour. La version installée est affichée en haut.
Sans accès à l’administration, le numéro de version est souvent visible dans le code source de la page d’accueil, dans la balise meta name="generator" ou dans le paramètre ver= des fichiers chargés par le site.
Comment savoir si votre site a été touché
Une mise à jour corrige la faille ; elle ne répare pas un site déjà compromis. Si votre site est resté en version vulnérable entre fin septembre et aujourd’hui, les points à contrôler :
- des comptes administrateurs que vous ne reconnaissez pas ;
- des fichiers PHP récents dans
wp-content/uploads/, un dossier qui ne devrait contenir que des médias ; - des modifications de
wp-config.php,.htaccessouindex.phpà une date que vous ne vous expliquez pas ; - des tâches planifiées inconnues ;
- des redirections depuis les moteurs de recherche que vous ne voyez pas en navigation directe ;
- dans les journaux du serveur, des requêtes contenant des suites de
../ou mentionnantpearcmd.
Si l’un de ces signes apparaît, la mise à jour ne suffit plus : il faut un examen du site.