Le 22 septembre 2026, WordPress a publié la version 7.1.2 pour corriger une faille critique de son cœur, la CVE-2026-87902, notée 9,2 sur 10 et présente dans toutes les versions de 4.7.0 à 7.1.1 (annonce WordPress, Patchstack). Un visiteur anonyme peut s'en servir pour faire exécuter du code sur le serveur, sous certaines conditions. Les premières attaques ont été relevées le jour même, quelques heures après le correctif (BleepingComputer).
Réponse rapide
Si votre site tourne sous WordPress, vérifiez aujourd'hui qu'il affiche 7.1.2 (ou 7.0.6 pour la branche 7.0). Une mise à jour faite la semaine dernière ne suffit pas : la 7.1.1 du 17 septembre est encore vulnérable. Ensuite, demandez à votre hébergeur si des tentatives d'attaque apparaissent dans les journaux du site depuis le 22 septembre.
Que corrige WordPress 7.1.2 ?
Quand quelqu'un ouvre une page, WordPress cherche dans le thème le fichier de mise en page qui correspond. Dans les versions vulnérables, un attaquant peut détourner cette recherche pour faire charger un fichier PHP situé ailleurs sur le serveur. Si le bon fichier est présent, et c'est le cas sur une partie des hébergements, il obtient l'exécution de son propre code, autrement dit la main sur le site.
L'attaquant n'a besoin d'aucun compte, et vous n'avez rien à cliquer pour être touché. Le défaut est dans le cœur de WordPress, pas dans une extension : un site aux extensions impeccables est concerné comme les autres. Les attaquants sont partis du correctif lui-même. Patchstack a vu les premières sondes le 22 septembre, et des outils publics pour repérer les sites vulnérables circulaient dès le lendemain.
Comment savoir si mon site WordPress est exposé ?
Tout se joue sur le numéro de version affiché dans votre administration :
| Version affichée | État |
|---|---|
| 7.1.2, ou 7.0.6 si vous êtes resté en 7.0 | Corrigé |
| Une version plus ancienne mise à jour le 22 septembre 2026 ou après | Corrigé, le correctif a été reporté jusqu'à la branche 4.7 |
| 7.1.1 (sortie le 17 septembre) et toutes les versions depuis 4.7.0 | Exposé, à mettre à jour |
Pour que l'attaque aille jusqu'au bout, il faut en plus que le thème actif contienne un dossier dont le nom commence par « page- », et que le réglage PHP register_argc_argv soit actif sur le serveur. Beaucoup de sites ne réunissent pas ces conditions. Mais vous ne les voyez pas depuis l'administration, et votre prestataire ne les connaît pas toujours de tête. Mettre à jour prend moins de temps que de vérifier.
Mon avis
C'est la deuxième faille critique du cœur de WordPress en deux mois, après wp2shell en juillet. Ce qui me frappe cette fois, c'est la 7.1.1. Un patron qui a vu passer « mise à jour de sécurité » le 17 septembre et l'a faite a eu le bon réflexe, et il était de nouveau exposé cinq jours plus tard. La sécurité d'un WordPress ne se règle pas une fois par trimestre. Il faut quelqu'un qui lit les annonces la semaine où elles sortent.
Les 4 gestes à faire avant lundi
Si quelqu'un gère votre site pour vous, ce sont quatre questions à lui poser par e-mail aujourd'hui.
Lire le numéro de version, pas la date de la dernière mise à jour
Dans l'administration, le numéro s'affiche en bas à droite du tableau de bord et dans Outils, puis Santé du site. Le piège de cette semaine : un site mis à jour en 7.1.1 le 17 septembre a l'air à jour, et il est exposé. Seuls 7.1.2 (ou 7.0.6 pour la branche 7.0) et les versions de maintenance publiées le 22 septembre sont corrigées.
Mettre à jour après une sauvegarde
WordPress.org indique que les sites qui acceptent les mises à jour automatiques en arrière-plan la reçoivent d'eux-mêmes. Si les mises à jour automatiques sont coupées, par votre prestataire ou par votre hébergeur, personne ne l'a faite. Sauvegardez, mettez à jour, relisez le numéro.
Demander à l'hébergeur de regarder les journaux
Les attaques observées passent par un fichier PHP de l'outil PEAR, nommé pearcmd.php. Une recherche de ce mot dans les journaux d'accès du site depuis le 22 septembre dit si quelqu'un a tenté sa chance. Si des requêtes sont passées avant votre mise à jour, traitez le site comme possiblement compromis.
Si le correctif doit attendre, faire poser un pansement
Un site très personnalisé ne se met pas toujours à jour en une minute. Dans ce cas, votre hébergeur ou votre prestataire peut désactiver le réglage PHP register_argc_argv, qui est une des conditions de l'attaque. Ça fait gagner des heures, ça ne remplace pas la mise à jour.
Si le site a été touché, la mise à jour ne suffit pas : un accès déjà installé survit au correctif. La marche à suivre (comptes inconnus, fichiers modifiés, restauration d'une sauvegarde antérieure) est la même que pour wp2shell, on l'a détaillée dans comment savoir si votre site a déjà été piraté. Un site piraté peut aussi héberger des pages de spam que Google sanctionne, sujet de la mise à jour anti-spam de septembre 2026. Et si cette semaine vous fait vous demander si WordPress est le bon outil pour un site vitrine, notre comparatif WordPress ou site sur mesure pose le pour et le contre. Un site statique n'a pas de fichier de thème à détourner, c'est pour ça qu'on construit la plupart de nos sites vitrines ainsi.
Questions fréquentes sur la faille CVE-2026-87902
Quelles versions de WordPress sont touchées par la faille CVE-2026-87902 ?
J'ai mis à jour WordPress la semaine dernière, suis-je protégé ?
Mon site est-il forcément piratable s'il n'est pas à jour ?
Faut-il un compte sur le site pour exploiter la faille ?
Mon site n'est pas sous WordPress, suis-je concerné ?
Pas sûr de l'état de votre WordPress ?
On regarde la version, le correctif, les journaux et les traces d'intrusion, et on vous dit ce qui reste à faire.
Sources de cet article, consultées le 25 septembre 2026 :
Articles liés
